Lesson 35 — Microsoft Entra Conditional Access Design
Microsoft Entra Security Defaults provide a Microsoft-managed baseline of identity protection for organisations that need strong security without designing a full Conditional Access framework.
Security Defaults help require users to register for multifactor authentication, protect administrator roles, challenge users when Microsoft considers it necessary and block legacy authentication protocols that cannot perform modern authentication.
This lesson explains what Security Defaults protect, where their limitations begin, how they differ from Conditional Access and how to avoid creating security gaps when migrating from the baseline to customised policies.
What you will learn
This lesson explains how Microsoft Entra Security Defaults protect identities, where the baseline is appropriate and how to migrate safely to Conditional Access.
Learning objectives
After completing this lesson, you should be able to explain, assess and safely manage Microsoft Entra Security Defaults.
- Explain why Security Defaults exist.
- Identify the protections included in the baseline.
- Understand MFA registration and sign-in behaviour.
- Explain how legacy authentication is blocked.
- Compare Security Defaults with Conditional Access.
- Recognise when an organisation has outgrown the baseline.
- Plan a safe migration to Conditional Access.
- Validate that equivalent protections remain active.
The problem this solves
Many small or newly created tenants need immediate identity protection but do not yet have the licensing, expertise or operational maturity required for a customised Conditional Access design.
Security Defaults provide a simple Microsoft-managed security baseline without requiring administrators to build every policy themselves.
Security Defaults protection flow
What Security Defaults are
Security Defaults are a predefined set of Microsoft-managed identity security controls intended to reduce common account-compromise risks.
They are configured at the tenant level rather than through separate administrator-created policies.
What Security Defaults are not
Security Defaults are not a full Zero Trust access design, a replacement for identity governance or a configurable policy engine.
They provide a broad baseline but do not offer the detailed targeting, exclusions, conditions and session controls available through Conditional Access.
Core protections
| Protection | Purpose | Operational effect |
|---|---|---|
| MFA registration | Prepare users for stronger authentication | Users register an authentication method when prompted |
| Administrator protection | Reduce privileged-account compromise | Privileged roles receive stronger MFA enforcement |
| User MFA challenge | Protect risky or sensitive sign-ins | Users may be challenged when Microsoft determines it is necessary |
| Legacy authentication blocking | Prevent sign-ins that cannot perform modern authentication | Older protocols and clients are denied |
| Microsoft-managed operation | Reduce configuration complexity | Microsoft determines and updates baseline behaviour |
Where to manage Security Defaults
In the Microsoft Entra admin centre, browse to Entra ID > Overview > Properties and select Manage security defaults.
An appropriately privileged role, such as Conditional Access Administrator, is required to change the setting.
Tenant-level behaviour
Security Defaults are enabled or disabled for the directory as a whole.
They are not designed for exceptions based on individual users, applications, locations, devices or business units.
Security Defaults versus no baseline
| Area | Security Defaults enabled | No equivalent control |
|---|---|---|
| MFA readiness | Users are driven toward registration | Users may remain password-only |
| Privileged access | Administrator accounts receive baseline MFA protection | Privileged accounts may rely on passwords |
| Legacy authentication | Blocked | Older protocols may remain available |
| Configuration effort | Low | Low, but with significant security exposure |
| Policy flexibility | Limited | None |
MFA registration
Security Defaults require users to register an authentication method so that multifactor authentication can be used when required.
Registration should be supported by clear user communication and help-desk readiness.
MFA is not always challenged identically
Security Defaults do not behave like a simple policy that visibly prompts every user at every sign-in.
Microsoft controls challenge behaviour while maintaining stronger, consistent protection for privileged roles.
User registration workflow
Administrator protection
Administrator accounts are attractive targets because compromise can affect the entire directory.
Security Defaults apply stronger MFA protection to privileged roles, reducing the risk of password-only administrative access.
Privileged account hygiene still matters
MFA does not replace separate administration accounts, least privilege, Privileged Identity Management, emergency access accounts or phishing-resistant authentication.
Security Defaults are the beginning of privileged security—not the end.
Privileged access comparison
| Control | Security Defaults | Mature privileged-access design |
|---|---|---|
| Administrator MFA | Baseline protection | Phishing-resistant and role-specific enforcement |
| Role activation | Not provided | Privileged Identity Management |
| Approval workflow | Not provided | Eligible roles and approval |
| Device requirement | Not configurable | Compliant or privileged access workstation |
| Session restrictions | Not configurable | Conditional Access session controls |
| Emergency access | Must be designed separately | Documented and monitored break-glass process |
Legacy authentication
Legacy authentication protocols cannot perform modern authentication controls such as MFA and are frequently targeted in password-spray and credential-reuse attacks.
Security Defaults block these older authentication paths.
Common legacy dependencies
- Older mail clients
- POP, IMAP or SMTP authentication workflows
- Old Office versions
- Printers and scanners sending email
- Scripts using username and password
- Line-of-business applications without modern authentication
Legacy authentication investigation
Who should use Security Defaults?
Security Defaults are well suited to organisations that need a secure baseline, have uncomplicated access requirements and do not require user, application, location or device-specific exceptions.
They are also useful where Conditional Access licensing is not available.
Who may have outgrown them?
Organisations may need Conditional Access when they require granular policy targeting, device compliance, named locations, authentication strengths, session controls, exclusions or application-specific decisions.
Complexity should be justified by business and security requirements.
Security Defaults versus Conditional Access
| Capability | Security Defaults | Conditional Access |
|---|---|---|
| Baseline MFA protection | Yes | Yes, through designed policies |
| Legacy authentication blocking | Yes | Yes, through a policy |
| User and group targeting | No | Yes |
| Application targeting | No | Yes |
| Named locations | No | Yes |
| Device compliance | No | Yes |
| Authentication strength | No granular configuration | Yes |
| Report-only testing | No | Yes |
| Licensing | No premium Conditional Access licence required | Requires eligible Microsoft Entra licensing |
They are not additive
Security Defaults and an organisation's Conditional Access policy framework should not be treated as two independent layers that can simply be stacked together.
When adopting Conditional Access, design the replacement controls first and then transition deliberately.
The migration risk
Disabling Security Defaults removes the Microsoft-managed baseline.
If replacement policies are incomplete, the tenant can lose administrator MFA, user MFA or legacy authentication protection immediately.
Safe migration sequence
Minimum replacement controls
- Require MFA for administrator roles
- Require MFA for users according to the organisation's risk model
- Block legacy authentication
- Protect security information registration
- Protect high-value applications
- Maintain emergency access
Do not copy blindly
The correct Conditional Access architecture depends on licensing, identity types, workloads, authentication methods, devices and operational requirements.
Use Microsoft guidance as a foundation and validate every policy against the tenant.
Migration control matrix
| Security Defaults protection | Conditional Access replacement | Validation evidence |
|---|---|---|
| Administrator MFA | Require MFA or phishing-resistant authentication for privileged roles | Administrator test sign-ins |
| User MFA readiness | Authentication method registration campaign and MFA policies | Registration reports and user tests |
| User MFA challenge | Policy based on applications, users or risk | Report-only and sign-in logs |
| Legacy authentication block | Block legacy authentication client apps | Legacy sign-in attempts denied |
| Tenant-wide baseline | Policy set covering all intended users and resources | Coverage review and exclusions register |
Emergency access accounts
Before changing authentication enforcement, maintain cloud-only emergency access accounts designed to recover the tenant if normal administrative access fails.
These accounts require strong monitoring, secure credentials and documented procedures.
Exclusions require scrutiny
Conditional Access exclusions can create intentional bypass paths that did not exist under the broad Security Defaults baseline.
Every exclusion should have ownership, justification, monitoring and an expiry or review date.
Agent Foskett investigation: “Everything was protected… until Conditional Access was created.”
Investigation evidence
- Security Defaults enabled or disabled state
- Conditional Access policy inventory
- Policy inclusions and exclusions
- Report-only results
- Microsoft Entra Sign-in Logs
- Authentication method registration
- Legacy authentication client activity
- Administrator-role assignments
Common operational indicators
- Security Defaults disabled without replacement policies
- Legacy authentication succeeds unexpectedly
- Administrator accounts are outside MFA scope
- Conditional Access policies remain in report-only indefinitely
- Large unmanaged exclusion groups
- No emergency access validation
Pre-disable validation checklist
| Area | Validation question | Evidence |
|---|---|---|
| Licensing | Are all targeted users correctly licensed? | Licence inventory |
| Privileged access | Are all administrator roles protected? | Role and policy scope review |
| User MFA | Will intended users receive the correct challenge? | Report-only results |
| Legacy authentication | Is every legacy client blocked or remediated? | Sign-in Logs |
| Emergency access | Can recovery accounts access the tenant safely? | Documented access test |
| Applications | Will critical workloads continue to authenticate? | Pilot testing |
| Rollback | Can the previous state be restored? | Approved rollback plan |
Common mistakes
- Assuming Security Defaults require MFA at every user sign-in.
- Expecting user or application exclusions.
- Disabling the baseline before Conditional Access is ready.
- Forgetting to block legacy authentication.
- Leaving administrator roles outside policy scope.
- Testing only with one user account.
- Failing to protect emergency access accounts operationally.
Best practices
- Keep Security Defaults enabled when the baseline meets requirements.
- Inventory legacy authentication before deployment.
- Use separate administrator accounts.
- Prepare users for MFA registration.
- Adopt Conditional Access only with clear requirements.
- Build and test equivalent policies before migration.
- Monitor exclusions and emergency access continuously.
Key takeaways
- Security Defaults provide a Microsoft-managed baseline of identity protection.
- The baseline includes MFA registration, administrator protection and legacy authentication blocking.
- Security Defaults operate at the tenant level and offer limited customisation.
- They are suitable for organisations with straightforward access requirements.
- Conditional Access is appropriate when granular targeting and conditions are required.
- Disabling Security Defaults removes the baseline immediately.
- Replacement Conditional Access policies must recreate every required protection.
- Legacy authentication dependencies should be remediated rather than permanently exempted.
- Emergency access and rollback planning are essential during migration.
- A migration is complete only after sign-in, MFA and legacy-authentication behaviour has been verified.
Related Agent Foskett resources
Continue learning
Microsoft Entra Security Defaults
Microsoft Entra Security Defaults provide baseline identity protection through multifactor authentication registration, stronger administrator protection and legacy authentication blocking. They are designed for tenants that need strong security without a customised Conditional Access framework.
Microsoft Entra Academy Lesson 35 — Microsoft Entra Conditional Access Design
This Agent Foskett lesson explains how Security Defaults work, how they compare with Conditional Access and how to replace the baseline safely without leaving gaps in MFA or legacy authentication protection.
