Conditional Access is the policy engine at the heart of Microsoft Entra ID. Done well, it is the single most effective control you have for enforcing Zero Trust. Done poorly, it becomes a tangle of dozens of overlapping policies that nobody fully understands — and that quietly leaves gaps.
After running Conditional Access programs across large enterprises, I have settled on a structured framework that stays secure and maintainable as the organization grows.
Start with the principle, not the policy
Every Conditional Access decision answers one question: given this signal set, should this access be allowed, blocked, or granted with conditions? The signals are who (user/group), what (application), where (location/network), how (device, client app), and how risky (sign-in and user risk).
Before writing a single policy, write down your principles in plain English:
- All users must use phishing-resistant MFA for all cloud apps.
- Administrative roles require compliant or hybrid-joined devices.
- Legacy authentication is blocked everywhere, with no exceptions.
- High sign-in risk requires re-authentication; high user risk requires a secure password change.
These principles become your policy set. If a policy does not map to a stated principle, question why it exists.
Use a numbered, persona-based naming scheme
Policies should be self-documenting. A name like CA001-Global-BlockLegacyAuth-AllApps tells you the order, scope, intent, and target at a glance. Group policies by persona:
| Range | Persona |
|---|---|
| CA0xx | Global baseline (everyone) |
| CA1xx | Admin / privileged |
| CA2xx | Internal users |
| CA3xx | Guests / external |
| CA9xx | Pilot / emergency |
A new engineer should be able to read your policy list top to bottom and understand your security posture without opening a single policy.
Always exclude break-glass accounts
Two cloud-only, highly protected emergency-access accounts must be excluded from every Conditional Access policy. If a misconfigured policy ever locks everyone out — including admins — these accounts are how you recover.
Store break-glass credentials offline, monitor their use with alerting, and review them quarterly. They are your last line of defense, not a convenience.
Roll out in report-only mode first
Never flip a new policy straight to "on." Enable it in report-only mode, then use the Conditional Access Insights workbook to see exactly who would have been affected and what the result would have been. This catches the service account, the conference-room device, and the legacy app you forgot about — before they generate a 2 a.m. incident.
Report-only → monitor 1–2 weeks → remediate exceptions → enable
Block legacy authentication — really
Legacy authentication protocols (IMAP, POP, SMTP AUTH, older Office clients) cannot enforce MFA. They are the single most common path attackers use to bypass it. Audit your sign-in logs for legacy auth, migrate or retire what is using it, and then block it globally. This one policy eliminates a huge portion of credential-stuffing risk.
Keep it under control as you scale
- Review the full policy set quarterly and retire anything redundant.
- Export policies to source control (you can serialize them via Microsoft Graph) so changes are tracked and reviewable.
- Document every exclusion and the reason it exists, with an expiry date.
A Conditional Access framework is not "set and forget." But with clear principles, disciplined naming, report-only rollouts, and break-glass safety, it stays an asset rather than becoming a liability.
Need help designing or untangling Conditional Access? Schedule a discovery call — it is what we do.