Protection coverage
Inventory MFA registration, administrator MFA, user MFA, legacy authentication, device code flow, Azure management access, authentication methods, guests, and synchronization identities.
Microsoft Entra access-control architecture
Security Defaults vs Conditional Access Decision Guide
Choose the Microsoft Entra identity protection model that your organization can license, operate, test, monitor, and recover—then prove that every Security Defaults protection is preserved before a Conditional Access cutover.
Decision principle
Choose the simplest model that meets the real requirements—and can be operated safely
Security Defaults and Conditional Access address the same identity threat landscape at different levels of maturity. Security Defaults is an on-or-off baseline available without premium Entra licensing. Conditional Access is a policy engine that requires at least Microsoft Entra ID P1 for users in scope and P2 for risk-based conditions. Microsoft does not design the models to be combined; a Conditional Access transition must reproduce the baseline before adding exceptions or advanced controls.
Business requirements
Document app-specific rules, remote and BYOD use, device compliance, locations, sign-in risk, administrator protection, guest trust, workload identities, sessions, exceptions, and resilience.
Operating capability
Confirm licensing, named owners, emergency accounts, report-only analysis, pilot users, help-desk readiness, monitoring, change control, policy limits, evidence retention, and rollback drills.
Non-negotiable: do not disable Security Defaults and leave the tenant between protection models. Prepare, test, approve, and schedule the equivalent Conditional Access foundation so enforcement begins immediately after the Security Defaults setting is turned off.
Side-by-side decision
Understand what the organization gains—and must now govern
| Decision area | Security Defaults | Conditional Access | Evidence required |
|---|---|---|---|
| Licensing | Available without extra Microsoft Entra ID P1/P2 cost. | At least Entra ID P1 for Conditional Access; P2 for user-risk and sign-in-risk conditions through Identity Protection. | Subscribed SKUs, service-plan state, benefit eligibility, user population, guest treatment, trial status, renewal owner, and license-assignment proof. |
| Customization | One tenant-wide setting. No custom users, apps, locations, devices, grant controls, sessions, or exclusions. | Granular assignments, target resources, conditions, grant controls, authentication strengths, session controls, report-only, and workload identity policies. | Approved requirements, architecture, policy register, inclusion/exclusion owners, data sources, naming standard, review cadence, and residual risk. |
| MFA behavior | All users register; administrators perform MFA every sign-in; users perform MFA when Microsoft determines it is necessary. | Administrators choose who, which resource, which condition, which authentication strength, and which session behavior triggers enforcement. | Registration readiness, method usability, authentication strength, admin roles, guests, real sign-ins, failures, and support results. |
| Legacy authentication | Blocks older protocols tenant-wide, including Exchange ActiveSync basic authentication. | Dedicated policy can block legacy clients with explicit scope and logging, while approved technical remediation is tracked. | Sign-in logs by client app, application/device owner, SMTP/POP/IMAP dependencies, modern-auth remediation, exception expiry, and test evidence. |
| Device code flow | Blocked as part of Security Defaults for new tenants beginning July 1, 2026; no exception path. | Can be blocked or narrowly controlled through policy after application and device dependencies are understood. | Device-code sign-ins, affected applications, business justification, alternative flow, owner, scope, pilot, and monitoring. |
| Azure management | Requires MFA for all users accessing Azure Resource Manager surfaces such as the portal, CLI, or PowerShell. | Dedicated policy can require a selected authentication strength and additional conditions for Azure management. | Target-resource scope, roles and users, emergency exclusions, test clients, authentication method, sign-in results, and privileged workstation strategy. |
| Exceptions | No user-configurable exclusions. Synchronization accounts in the Directory Synchronization Accounts role receive documented product handling. | Exclusions are possible but become a governed bypass that must have an owner, justification, compensating controls, expiry, monitoring, and review. | Exception register, object IDs, approval, reason, control gap, expiration, alerting, usage, renewal decision, and closure evidence. |
| Testing and rollback | No report-only mode or pilot scope; the setting is enabled or disabled for the tenant. | Report-only, policy impact, What If, pilot groups, sign-in logs, templates, soft-delete recovery, and per-policy disable/exclusion support safer change. | Before exports, report-only results, pilot acceptance, cutover plan, disable order, emergency access proof, rollback steps, and post-change evidence. |
Model fit
Use requirements—not company size alone—to make the decision
Security Defaults is usually appropriate when
- The tenant does not have Microsoft Entra ID P1 or P2 for the population that would need Conditional Access.
- The organization needs a reliable baseline quickly and accepts tenant-wide behavior without custom exceptions.
- Users can register supported MFA methods and legacy authentication or device-code dependencies can be removed.
- There is no requirement for app, device, location, risk, authentication-strength, session, or workload-identity policy.
- The organization can communicate registration, support users, monitor sign-ins, and maintain emergency recovery.
- Turning on a simple control now is safer than waiting for an advanced design the team cannot yet operate.
Conditional Access is usually required when
- Licensed users need different controls by role, group, resource, device, network, client, risk, or authentication context.
- Privileged access must require phishing-resistant authentication or privileged workstations.
- Managed/compliant device, hybrid join, app protection, terms of use, sign-in frequency, token protection, or download restrictions are required.
- Guests, partner trust, cross-tenant access, service principals, or workload identities need deliberate treatment.
- Exceptions must be narrow, documented, monitored, time-bound, and separated from the baseline.
- The team can govern report-only testing, policy interactions, sign-in telemetry, change control, lifecycle review, and rollback.
Security Defaults baseline
Know exactly what must be replaced before cutover
The replacement is complete only when each built-in protection has an enforcing Conditional Access or operational control with tested scope. A policy name or template alone is not proof. Validate the actual users, target resources, client types, authentication methods, exclusions, and sign-in results.
MFA registration
All users must register. Security Defaults currently removes the former 14-day user registration grace period. Prepare users, registration methods, support, and token revocation decisions.
Administrator MFA
Covered administrator roles perform MFA every sign-in. A Conditional Access replacement should address all privileged roles and consider phishing-resistant methods, PIM, and dedicated admin accounts.
User MFA
Security Defaults prompts users when Microsoft determines MFA is necessary. Conditional Access must deliberately define the target population, resources, grant control or strength, and session behavior.
Legacy authentication block
Older clients and protocols that cannot perform MFA are blocked. Confirm no replacement policy leaves POP, IMAP, SMTP AUTH, ActiveSync basic authentication, or old Office clients exposed.
Device code flow block
Security Defaults blocks device code flow for new tenants from July 1, 2026. If the tenant needs an exception, inventory exact apps and use narrow Conditional Access scope with monitoring.
Azure management MFA
All users accessing Azure Resource Manager services perform MFA. The replacement must cover portal, PowerShell, CLI, and API audiences without excluding critical resource paths.
Method warning: Microsoft cautions against disabling organization methods while Security Defaults is in use because it can cause lockout. Preserve supported Authenticator notification and OATH TOTP registration behavior until the method architecture and recovery paths are deliberately migrated.
Ten-stage transition runbook
Build equivalent coverage before adding advanced policy
Authorize the decision
Record business requirements, license position, decision owner, Conditional Access Administrator access, change window, acceptance thresholds, monitoring, help-desk lead, emergency authority, evidence retention, and rollback approval.
Capture the immutable baseline
Export Security Defaults state, users, roles, licenses, authentication methods, MFA registration, sign-in logs, legacy clients, device-code activity, Azure management usage, guests, sync accounts, service accounts, and current Conditional Access objects.
Validate emergency access
Maintain at least two cloud-only emergency Global Administrator accounts using resilient phishing-resistant methods. Test access, monitoring, authorized custody, network independence, and recovery before any policy changes.
Prove license coverage
Map every member, guest, and administrator in scope to the required Entra service plan. Separate P1 controls from P2 risk features, document trial or bundled entitlement, and assign renewal ownership.
Design the replacement foundation
Create a minimal policy set for legacy authentication, security-information registration, privileged access, user/guest MFA, Azure management, and device code flow. Name, document, and assign an owner to every policy and exclusion.
Run report-only observation
Use templates or custom policies in report-only, review real sign-ins, What If, policy impact, audiences, authentication methods, clients, locations, devices, failures, and exclusions. Microsoft’s current planning guidance recommends at least one week of report-only observation per policy.
Pilot real enforcement
Start with owned test groups, not all users. Test standard, privileged, guest, remote, mobile, unmanaged, managed, legacy client, device code, Azure CLI/PowerShell, new-device, registration, recovery, and emergency scenarios.
Execute coordinated cutover
Capture a last baseline, confirm the support bridge, disable Security Defaults, and immediately enable the approved equivalent Conditional Access foundation in the documented order. Watch sign-ins, registration, help-desk volume, and emergency alerts.
Expand and optimize
Advance cohorts only after acceptance gates pass. Add device, app protection, authentication strength, location, risk, token, session, guest, and workload-identity controls as separate governed improvements—not as untested cutover scope.
Close with proof
Preserve final policies, states, object IDs, exclusions, licenses, reports, sign-ins, audit events, incidents, rollback tests, exception register, residual risk, owners, review schedule, and executive acceptance.
Common decision and deployment failures
Prevent the gap between “more granular” and actually secure
Conditional Access flexibility increases both control and configuration risk. Treat these patterns as blocking defects before enforcement.
Security Defaults disabled too early
The tenant loses baseline coverage while replacement policies remain report-only, disabled, incomplete, or incorrectly scoped.
License assumptions
Policies are designed around P1 or P2 features without proving entitlement for every user who benefits from or is subject to the control.
One giant policy
Combining unrelated conditions and controls creates opaque outcomes, difficult troubleshooting, broad blast radius, and unsafe rollback.
All users, all resources, block
An overbroad block can lock out the organization. Microsoft specifically warns against dangerous “all” combinations without tested exclusions and impact analysis.
Emergency accounts untested
Excluded accounts that depend on federation, personal phones, expired credentials, one network, or unmonitored custody do not provide reliable recovery.
Excluded means safe
Every exclusion is a bypass. Without owner, business need, compensating control, alert, expiration, and review, exceptions become permanent attack paths.
Per-user MFA confusion
Users may correctly show Disabled in the legacy per-user MFA page while Security Defaults or Conditional Access enforces MFA. Validate sign-ins, not that legacy status alone.
Service principal blind spot
User-scoped Conditional Access does not control service-principal calls. Replace embedded credentials and use workload-identity controls where licensed and appropriate.
No policy lifecycle
Unnamed owners, duplicate rules, stale exceptions, uncontrolled templates, and no review cadence consume the 240-policy tenant limit and create conflict.
Evidence and operating measures
Measure effective coverage, not the number of policies
A mature report connects requirements to policy objects and real sign-in outcomes. Define the population, timeframe, data latency, denominator, exclusions, and expected result for every metric.
Minimum closeout: decision record, license proof, before/after exports and hashes, Security Defaults equivalence matrix, policy registry, object IDs, states, assignments, exclusions, report-only and pilot results, sign-in/audit evidence, emergency test, communications, incidents, rollback proof, residual risk, owners, and next review date.
Related ecosystem guides
Connect the decision to methods, policy, monitoring, devices, and recovery
Conditional Access policy reviewAudit assignments, resources, conditions, controls, exclusions, testing, and evidence.
Authentication methods migrationReconcile MFA, SSPR, registration, modern methods, strengths, and rollback.
Sign-in log operationsProve policy applicability, authentication, audience, device, risk, and failure outcomes.
Emergency access securityBuild, monitor, test, and govern resilient cloud-only recovery accounts.
MFA deploymentPlan registration, authentication methods, rollout, support, and validation.
Device registration reviewVerify join, management, compliance, owner, activity, and access claims.
Microsoft 365 admin toolsetUse related planning, assessment, and evidence-building resources.
Microsoft 365 managed servicesGet ongoing identity, endpoint, email, collaboration, and tenant support.
Authoritative Microsoft references
Validate the design against current product behavior
Frequently asked questions
Security Defaults vs Conditional Access FAQ
Can Security Defaults and Conditional Access be enabled together?
Microsoft does not intend the two models to be combined. Conditional Access policies provide a customizable replacement for the baseline. Prepare equivalent policies, test them, and coordinate the cutover so the tenant is never left without enforcement.
Does Conditional Access require Microsoft Entra ID P1 or P2?
Conditional Access requires at least Microsoft Entra ID P1 for users in scope. P2 is required for Identity Protection user-risk and sign-in-risk conditions. Verify actual service-plan entitlement for all users who benefit from or are subject to a policy.
Is Security Defaults only for very small businesses?
No. The better question is whether the organization accepts a universal, noncustomizable baseline and lacks requirements for app, device, location, risk, session, exception, or workload-identity controls. Requirements and operating capability matter more than headcount alone.
Should Security Defaults be disabled while replacement policies are still report-only?
No. Report-only policies do not enforce access. Complete coverage analysis and pilot testing first, then use a coordinated cutover that disables Security Defaults and immediately enables the approved equivalent Conditional Access foundation.
Why do users show Disabled on the per-user MFA page?
Disabled is the expected per-user MFA state when MFA is enforced through Security Defaults or Conditional Access. Use effective policy, registration data, and sign-in details to prove enforcement rather than relying on the legacy per-user status.
What is the safest rollback if a Conditional Access policy causes lockout?
Use a validated emergency access account to disable the affected policy or apply a narrowly approved temporary exclusion, then confirm sign-in recovery and preserve the incident evidence. Maintain exact before-state exports, policy IDs, operator authority, communications, and re-enablement criteria.
IT Perfection Microsoft 365 identity support
Choose and implement the access model with no protection gap
IT Perfection helps organizations in Irvine, Orange County, Los Angeles County, and Southern California assess licensing, map Security Defaults coverage, design Conditional Access, validate emergency recovery, test in report-only and pilot scope, execute coordinated cutover, and establish ongoing identity-control governance.
Created by Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, and infrastructure experience.
This guide is for initial planning and operational guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, or legal/compliance review. Validate current licensing, tenant behavior, Microsoft documentation, user requirements, and tested rollback procedures before implementation.
