It was a Tuesday. 6:47am. My phone rings. It's the head of our Asia-Pacific operations. He can't sign in. Board presentation in 90 minutes. I'm sitting in Cologne in my kitchen, coffee still brewing, trying to remember which policy change we pushed the night before.
We found it. Fixed it. He made the presentation.
But I spent the next two hours documenting every single thing that could go wrong in a Conditional Access deployment. Not theoretically, but the things that had actually bitten us. That document became the foundation for this checklist.
I'm sharing it now because I keep seeing the same mistakes across every environment I review. Smart teams. Good intentions. Gaps that a threat actor would happily walk through.
Why Most CA Deployments Have Invisible Holes
Here's the honest truth about Conditional Access: it's not technically difficult. Microsoft's documentation is decent. The interface is reasonably intuitive. You can have basic policies running in a day.
The hard part is that the gaps are invisible until something breaks.
Your emergency access accounts look fine, until your global admin is locked out at 2am and the break-glass account is also catching your new MFA policy because someone added it to the wrong group. Your Named Locations look complete, until a VP connects from a new VPN egress IP and gets blocked from a board meeting. Your legacy authentication block looks airtight, until you realize SMTP AUTH is still open for one shared mailbox that feeds into your ERP.
The gaps don't announce themselves. They wait.
After seven years managing identity infrastructure for 8,500+ users across five timezones, I've learned to look for patterns. And the same ten categories of gaps show up, again and again, regardless of company size or technical maturity.
What This Checklist Actually Covers
I built this around ten categories that reflect how CA policies actually fail in production, not how they're structured in the Microsoft docs.
1. Foundations and Named Locations
This is where everything starts. If your Named Locations are wrong, your location-based policies are wrong. If your break-glass accounts aren't properly excluded, you're one misconfigured policy away from locking yourself out of your own tenant. These aren't advanced items. They're the floor.
2. User and Group Targeting
This is where I see the most creative mistakes. The most common: service accounts caught by user policies because nobody built an exclusion group. The second most common: Directory Sync accounts not excluded, which breaks silently in a way that's genuinely unpleasant to debug. The third: exclusion groups that nobody monitors, which are, by the way, one of the cleanest attack surfaces in a poorly governed environment.
3. Authentication Strength
This one has changed most in the last two years. "Require MFA" is no longer enough for privileged accounts. SMS OTP is not MFA for anything that matters. SIM-swap attacks are cheap, available-as-a-service, and increasingly common.
If your admins are still using SMS as their primary second factor, that's the one thing I'd fix before everything else on this list.
4. Device Compliance
This is where Zero Trust either becomes real or stays a slide deck concept. The uncomfortable question: do you have compliance policies for every platform your users actually use? Windows yes, probably. macOS, maybe. iOS and Android for BYOD, possibly. Linux? There's your gap.
5. Session Controls
Continuous Access Evaluation should be enabled everywhere it's supported. It's the difference between token revocation happening in near-real-time versus hours later. Sign-in frequency on sensitive apps matters. Persistent browser sessions on unmanaged devices are a gift to anyone who ever gets physical access to an unlocked laptop in a shared workspace.
6. Privileged Access
Privileged access deserves its own policies entirely, separate from your user policies. If your admins are going through the same Conditional Access as your end users, that's a governance problem.
And if Trusted Locations are bypassing MFA for admins, which I've seen more times than I'd like to admit, that's not a Trusted Location, that's a hole.
7. Application-Specific Policies
This is where the "All cloud apps" default creates false confidence. Yes, covering everything with one broad policy is better than nothing. But high-value apps, your Finance system, your HR platform, your ERP, should have their own policies with tighter controls. The blast radius of a compromised account is not the same across all applications.
8. Risk-Based Policies
Entra ID Protection's risk-based policies are the most underdeployed capability I see. Teams buy Entra ID P2, enable Identity Protection, and then leave the risk policies in reporting mode forever because they're afraid of the impact.
Risk policies without enforcement are just a dashboard. Test in report-only, yes. But then enforce. That's what you're paying for.
9. Operations and Governance
Nobody wants to write a naming convention. Nobody wants to document policy ownership. But six months from now, when you're staring at 47 policies with names like "New policy (3) - test" and "CA-Backup-DO NOT DELETE," you'll understand why this matters. Policies without owners become zombie policies. Zombie policies become security debt.
10. Multi-Region and Multi-Timezone
This is the one nobody thinks about until it's too late. Rollout windows that work for Germany block Asia-Pacific during business hours. Report-only observation periods of 24 hours miss an entire region's working day. Emergency procedures written for one timezone fail when the on-call is in a different one.
The Three Things That Actually Move the Needle
If you read this checklist and think "we can't do all of this right now," fine. Prioritize these three:
1. Block legacy authentication. It's the single highest-impact change you can make. Legacy protocols like IMAP, POP3, and SMTP AUTH don't support modern MFA. They're still in use in most environments. And they're still being actively exploited. Block them. Handle the exceptions individually. Don't let them stay open because someone needs to think about it.
2. Exclude your break-glass accounts properly. This sounds obvious. It's not obvious to everyone who's ever called me at 6am. Two accounts, different MFA methods, different administrators, explicitly excluded from every policy, with alerting on every sign-in. This isn't a nice-to-have. It's what keeps a misconfigured policy from becoming a disaster.
3. Move privileged accounts to phishing-resistant MFA. FIDO2 security keys or certificate-based authentication. This week, not next quarter. The threat model for admin accounts is qualitatively different from end user accounts. Your policies should reflect that.
A Word on the Human Side
Here's something the checklist can't fully capture: Conditional Access is as much a change management problem as a technical one.
Your most dangerous legacy authentication exceptions aren't from bad actors. They're from legitimate applications that nobody documented when they were built three years ago. Your biggest gap in device compliance isn't ignorance. It's that someone told IT "the compliance policy breaks my workflow" and IT created an exception and nobody wrote it down.
When I do a CA review, the technical configuration is usually fixable in a day. The organizational archaeology, understanding what's excluded and why, who approved it, whether the business reason still exists, takes weeks.
That's why governance isn't optional. Policy ownership, change tracking, regular reviews. Not because auditors ask for it. Because in two years, when you've changed jobs and someone else is managing this environment, there needs to be a record of intent, not just configuration.
How to Use the Checklist
I've structured it so you can use it two ways:
For a new deployment, work through it in order. The categories roughly follow a logical build sequence. You want Foundations solid before you worry about Application-Specific policies.
For an audit, start with the Must Have items in each section. These are the gaps that represent real, exploitable exposure. Then work through Recommended items based on your risk profile and operational maturity. Advanced items are for environments that have the first two tiers sorted and want to push further.
One practical note: never push more than one new policy into enforcement in the same change window. And always run in report-only for at least 48 hours, 72 if you have significant operations outside your primary timezone.
The CISO who reviews a CA environment and finds clean naming, documented owners, and quarterly review cycles will trust the rest of what you've built. The one who finds 47 unnamed policies and no change history won't, regardless of how technically correct the configuration is.
Download the Checklist
The full checklist is available as a structured document with priority labels, a checkbox column, and implementation notes for each item.
→ Download: Entra ID Conditional Access Checklist 2026 (PDF)
If you're working through a CA audit or deployment and want a second opinion on what you find, I write about exactly this kind of work at access-insights.com. The GitHub Identity Secure Hub also has policy templates and PowerShell tooling that complement the checklist.