Entra ID Conditional Access: Deploy Without Locking Anyone Out
The most common Conditional Access deployment failure is going from zero policies to enforcement mode in one step. The result: a VP gets locked out on a Friday afternoon, IT spends the weekend on emergency calls, and the security team loses credibility. The safe path is a phased rollout using report-only mode to observe before you enforce, exclusion groups that are audited not abandoned, and break-glass accounts that exist before day one. This guide walks the exact sequence.
Before You Start: Two Break-Glass Accounts and One Exclusion Group
Create these before touching any CA policy.
Break-glass account setup:
1. Create two cloud-only accounts:
- emergency-access-01@yourtenant.onmicrosoft.com
- emergency-access-02@yourtenant.onmicrosoft.com
2. Generate 40-character random passwords for each.
Store passwords in a physical safe or sealed envelope.
Do NOT store in a password manager (that's what you're protecting against).
3. Assign Global Administrator permanently (not via PIM).
4. Exclude both accounts from ALL Conditional Access policies.
Create a group: sg-ca-emergency-exclusion
Add both break-glass accounts.
5. Create an alert:
Entra ID > Monitoring > Diagnostic settings >
Sign-in logs > Alert on any sign-in from these accounts.
Page your whole security team when it fires.
Exclusion group governance:
Create one exclusion group per policy, not one master exclusion group. Name them sg-ca-exclude-[policy-name]. Document every member with: account purpose, justification for exclusion, ticket number, review date. Review quarterly -- unused exclusions become backdoors.
Phase 1: Block Legacy Authentication (Week 1–2, Report-Only)
Legacy auth is responsible for the majority of password spray and credential stuffing attacks. It cannot prompt for MFA, so blocking it is the single highest-ROI CA policy.
Policy settings:
Name: CA001 - Block Legacy Authentication
State: Report-only (NOT On)
Assignments:
Users: All users
Exclude: sg-ca-emergency-exclusion
Cloud apps: All cloud apps
Conditions:
Client apps: Select
✓ Exchange ActiveSync clients
✓ Other clients
(Do NOT check Browser or Mobile apps/desktop clients)
Access controls:
Grant: Block access
How to read report-only results: Entra ID > Sign-in logs > Add filter: Conditional Access = Report-only: Failure
For each result, check:
- User: Is this a real person or a service account?
- Client app: What protocol? (IMAP, SMTP, POP3, legacy ExchangeActiveSync)
- Application: Which app is connecting?
If you find legitimate use (e.g., a printer using SMTP to send scans), migrate it to modern auth or add to the exclusion group with a documented justification. After 2 weeks with no unexplained failures, flip to On.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Phase 2: Require MFA for All Users (Week 3–5, Report-Only Then Enforce)
Policy settings:
Name: CA002 - Require MFA for All Users
State: Report-only initially
Assignments:
Users: All users
Exclude:
- sg-ca-emergency-exclusion
- sg-ca-exclude-mfa-legacy-services (for any service accounts
that cannot use modern auth and aren't yet migrated)
Cloud apps: All cloud apps
Conditions: None (applies to all sign-ins)
Access controls:
Grant: Require multifactor authentication
MFA registration campaign (run before enforcement): Entra ID > Protection > Authentication methods > Registration campaign
- Enable: Yes
- Days allowed to snooze: 7 (gives users a week to register before enforcement)
- Target: All users
Run the registration campaign for 2 weeks in parallel with report-only mode. Check registration status:
Entra ID > Users > Per-user MFA
Filter by: MFA Status = Disabled
Any user still unregistered after 2 weeks needs direct outreach before enforcement. Do NOT enforce while significant users are unregistered.
Enforcement day process:
- Email all users 48 hours before: "MFA will be required starting [DATE]"
- Have IT helpdesk on elevated staffing for 2 days post-enforcement
- Flip policy from Report-only to On during low-traffic hours (early morning, not Friday)
- Monitor sign-in logs for the next 4 hours; be ready to disable if unexpected widespread failure
Phase 3: Require Compliant Device for Sensitive Apps (Week 6–8)
Apply this only after MFA is fully enforced. Scoping to specific apps reduces blast radius if Intune enrollment is incomplete.
Identify target apps first: High-sensitivity applications to protect with device compliance:
- Azure portal / Entra admin center
- Microsoft 365 admin center
- Your ERP or financial system (if federated)
- Source code repositories (GitHub Enterprise via SAML, Azure DevOps)
- HR systems
Policy settings:
Name: CA003 - Require Compliant Device for Sensitive Apps
State: Report-only initially
Assignments:
Users: All users (or start with pilot group of 20)
Exclude: sg-ca-emergency-exclusion
Cloud apps: Select specific apps (Azure Management, M365 Admin)
Conditions: None
Access controls:
Grant: Require device to be marked as compliant
(Do NOT use 'Require Hybrid Azure AD joined device' unless
you have on-premises AD DS -- that's a different, harder path)
Intune enrollment prerequisite check: Before enforcing, confirm:
Intune > Devices > Enrollment > Windows enrollment
- Auto-enrollment is configured for your tenant
- Compliance policies exist and are assigned
- Corporate devices are showing as 'Compliant'
Report-only this policy for 3 weeks. Look for any corporate-owned devices showing as non-compliant in the sign-in logs. Fix compliance policy gaps before enforcing.
Phase 4: Sign-In Risk Policy (Week 9–10)
This requires Entra ID P2 (included in Microsoft 365 E5 or as an add-on).
Policy settings:
Name: CA004 - Respond to Risky Sign-ins
State: Report-only initially
Assignments:
Users: All users
Exclude: sg-ca-emergency-exclusion
Cloud apps: All cloud apps
Conditions:
Sign-in risk: High, Medium
(Start with just High; add Medium after a week of observation)
Access controls:
Grant: Require multifactor authentication
(For High risk only: consider Block access instead of MFA --
a compromised account may be able to complete MFA if the attacker
has the phone. Discuss with your team.)
What 'High risk' means: Entra ID's machine learning has high confidence the sign-in is from a threat actor -- impossible travel, leaked credentials found on darkweb, known malicious IP.
What 'Medium risk' means: Anomalous sign-in patterns, unfamiliar location, sign-in from anonymizing proxy.
For most orgs: block High risk, require MFA for Medium risk. Review flagged sign-ins weekly in Entra ID > Protection > Risky sign-ins to calibrate.
Phase 5: Privileged Administrator MFA (Enforce Immediately)
This should actually be your first enforced policy, not your last. Admin accounts are the highest-value target. Unlike regular user MFA, this cannot wait.
Policy settings:
Name: CA000 - Require MFA for Administrators
State: On (enforce immediately, no report-only phase)
Assignments:
Users > Directory roles: Select all privileged roles:
- Global Administrator
- Privileged Role Administrator
- Security Administrator
- Exchange Administrator
- SharePoint Administrator
- Conditional Access Administrator
- Helpdesk Administrator
- User Administrator
- Application Administrator
- Cloud Application Administrator
Exclude: sg-ca-emergency-exclusion
Cloud apps: All cloud apps
Access controls:
Grant: Require multifactor authentication
Session: Sign-in frequency: 1 hour (for admins, re-auth frequently)
Notify all admins before enabling. Admins who haven't registered for MFA will be locked out immediately. Run an MFA registration check for all admin-role holders first:
Entra ID > Roles and administrators > Global Administrator
> [list all members] > Check each account's MFA status
Managing Exclusions Without Creating Backdoors
Exclusion groups are the most commonly abused CA control. A well-intentioned exception for a service account becomes a permanent backdoor when the account is repurposed or the developer leaves.
Exclusion governance rules:
| Rule | Why |
|---|---|
| One exclusion group per policy | Limits blast radius; easy to audit who's excluded from what |
| Every member requires a ticket number | Creates accountability and searchable history |
| Quarterly review mandatory | Calendar reminder to check every member is still needed |
| No self-service additions | Only security team can add; devs submit a request |
| Managed identity first | Before adding a service account to an exclusion, ask: can this use a managed identity instead? |
Quarterly exclusion audit query (Microsoft Graph):
# List all members of all CA exclusion groups
Get-MgGroup -Filter "displayName startsWith 'sg-ca-exclude'" |
ForEach-Object {
$group = $_
Get-MgGroupMember -GroupId $group.Id |
Select-Object @{N='Group';E={$group.DisplayName}},
@{N='Member';E={$_.AdditionalProperties.displayName}},
@{N='Type';E={$_.AdditionalProperties.'@odata.type'}}
} | Export-Csv ca-exclusions-audit.csv
Review this CSV with each member's ticket and justification. Remove any member whose justification no longer applies.
Go-Live Checklist
Before flipping any policy from report-only to On:
- Break-glass accounts exist, passwords stored offline, excluded from all CA policies
- Alerts configured for break-glass account sign-in
- Report-only mode has run for the full observation window (2 weeks minimum)
- All report-only failures reviewed and categorized: legitimate vs. will-block-on-enforce
- All legitimate use cases added to exclusion groups with documented justification
- MFA registration rate is above 95% for affected users
- IT helpdesk notified and on elevated staffing for go-live + 48 hours
- User communication sent 48 hours before enforcement
- Enforcement scheduled during low-traffic window (not Friday, not month-end)
- Rollback plan documented: who approves disabling the policy if widespread failure occurs
- Sign-in log monitoring active for 4 hours post-enforcement
Rollback procedure: If enforcement causes unexpected widespread lockout:
Entra ID > Security > Conditional Access > Policies
> [policy name] > State: Report-only
This immediately stops enforcement. Do NOT delete the policy -- you'll lose the configuration.
The bottom line
Conditional Access is the most impactful identity control available in Entra ID -- but it locks people out when deployed carelessly. The playbook is simple: break-glass accounts first, report-only always, exclusions documented and audited. Follow the phase order (block legacy auth, then MFA all users, then device compliance, then risk policies) and you'll get to full enforcement in 10 weeks without a single emergency call.
Frequently asked questions
What is the first Conditional Access policy I should deploy?
Block legacy authentication protocols first. Legacy auth (SMTP AUTH, IMAP, POP3, basic auth) cannot prompt for MFA and is the attack vector in over 99% of password spray attacks according to Microsoft's data. Create a CA policy with condition: Client apps = 'Exchange ActiveSync clients' and 'Other clients', grant: Block access. Put it in report-only for 2 weeks, verify no legitimate use appears in the sign-in logs, then enforce.
How do I safely test Conditional Access policies before enforcing them?
Use report-only mode: set the policy state to 'Report-only' instead of 'On'. The policy evaluates every sign-in and logs what would have happened -- but takes no action. Review results in Entra ID > Sign-in logs, filter by 'Conditional Access' column = 'Report-only: Failure' to see who would have been blocked. Run for 2-3 weeks covering a full business cycle (including month-end, travel periods) before switching to enforcement.
How do I prevent getting locked out of my own tenant when deploying Conditional Access?
Create two break-glass emergency access accounts before enabling any CA policy. These accounts should: be cloud-only (not synced from on-premises AD), not be assigned to any real person, have long randomly generated passwords stored in a physical safe, be excluded from ALL CA policies, and have Global Administrator role permanently assigned. Monitor their sign-in logs with an alert -- any sign-in from these accounts should trigger an immediate incident response.
Should I exclude service accounts from Conditional Access policies?
Yes, but use workload identities (managed identities or service principals) instead of user accounts for automation. If you have legacy service accounts using user credentials, exclude them from CA policies via a dedicated exclusion group, document each exclusion with a justification and review date, and set a quarterly reminder to evaluate whether the account can be migrated to a managed identity. Never use a blanket exclusion group that developers can add themselves to.
What is the difference between requiring MFA and requiring a compliant device?
MFA verifies the person (something you know + something you have). A compliant device requirement verifies the device is enrolled in Intune, has disk encryption enabled, has an approved OS version, and has no high-risk security findings. Compliant device is a stronger control but blocks BYOD and requires Intune enrollment. Start with MFA for all users, then add compliant device for high-sensitivity apps (admin portals, financial systems, source code) in a second phase.
How do I handle Conditional Access for external guests and partners?
Create a separate CA policy scoped to guest users. At minimum, require MFA for guests accessing your SharePoint and Teams. Use the 'Guest or external users' condition in the policy. For high-sensitivity collaboration, combine MFA with terms-of-use acceptance and session controls (no download, no print). Avoid including guests in your main MFA policy if their home tenant is not Entra ID -- they may not be able to complete MFA registration.
What Conditional Access policies does Microsoft recommend as a baseline?
Microsoft's Entra ID security defaults (the free tier equivalent) cover: require MFA for admins, require MFA for all users when risk is detected, block legacy auth. The recommended paid-tier baseline adds: require MFA for all users always, require compliant device for admin portal access, session controls for persistent browser sessions on unmanaged devices, and sign-in risk policy (block high risk, require MFA for medium risk).
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.