Conditional Access Policies: The Ones You Actually Need (And How to Deploy Them)
Search for “Conditional Access best practices” and you’ll find Microsoft’s documentation listing every possible signal, condition, and grant control. It’s comprehensive. It’s also not helpful when you’re staring at an empty Conditional Access blade wondering which policies to create first.
The real problem isn’t understanding what Conditional Access can do. It’s that nobody gives you an opinionated list of which policies to deploy, in what order, without bricking your tenant. Meanwhile, your policy list grows organically — one policy per app, overlapping conditions, no naming convention — until you’ve got 40 policies and no idea which one is blocking your CFO’s iPad.
Here’s the guide I wish existed when I started deploying these.
What Conditional Access Actually Does
Conditional Access is an if-then engine. If a user matches certain conditions (who they are, where they are, what device they’re on, what app they’re accessing), then enforce certain controls (require MFA, require a compliant device, block access entirely).
It requires Entra ID P1 at minimum. If you’re on the free tier, you get Security Defaults — which forces MFA for everyone with zero granularity. That’s fine for a 5-person shop. The moment you need “MFA for admins always, MFA for users on untrusted networks, compliant devices for sensitive apps,” you need Conditional Access. You need P1 or P2.
Every Conditional Access policy has three parts: assignments (who and what), conditions (when and where), and access controls (what to enforce). Policies are additive — if multiple policies apply, all of their controls must be satisfied. There’s no “first match wins” logic. This matters more than people realize and is the source of most lockout incidents.
The 7 Policies Every Tenant Needs
These are the policies that should exist in every Microsoft 365 tenant running P1 or higher. Not 20 policies. Not “it depends.” Seven.
1. Block Legacy Authentication
Legacy authentication protocols (POP, IMAP, SMTP, ActiveSync with basic auth) don’t support MFA. Full stop. An attacker who obtains credentials via phishing or a credential dump can authenticate through a legacy protocol and bypass every MFA policy you’ve built.
Microsoft’s own data says blocking legacy auth stops over 97% of credential stuffing attacks. This is the single highest-impact policy you can deploy.
| Setting | Value |
|---|---|
| Users | All users |
| Cloud apps | All cloud apps |
| Conditions | Client apps → Exchange ActiveSync clients, Other clients |
| Grant | Block access |
| Exclude | Break-glass accounts |
The gotcha: Some organizations still have apps or devices using legacy protocols (old multifunction printers sending email via SMTP, legacy LOB apps). Check your sign-in logs for legacy auth activity before enforcing this policy. Report-only mode first. Always.
2. Require MFA for All Admins
Every privileged role — Global Admin, Exchange Admin, SharePoint Admin, Security Admin, all of them — should require MFA on every sign-in. No exceptions except break-glass accounts.
| Setting | Value |
|---|---|
| Users | Directory roles (select all admin roles) |
| Cloud apps | All cloud apps |
| Grant | Require multifactor authentication |
| Exclude | Break-glass accounts |
Phishing-resistant MFA (FIDO2 keys, Windows Hello for Business, certificate-based auth) is strongly preferred here. If an attacker phishes an admin’s password and their MFA is a push notification, they’re one “approve” tap from owning your tenant. Phishing-resistant methods don’t have that weakness.
3. Require MFA for All Users
After admins are covered, extend MFA to everyone. This is the universal baseline.
| Setting | Value |
|---|---|
| Users | All users |
| Cloud apps | All cloud apps |
| Grant | Require multifactor authentication |
| Exclude | Break-glass accounts, service accounts (if needed) |
The gotcha: Service accounts and shared mailboxes can’t perform interactive MFA. If you have service accounts that authenticate interactively (they shouldn’t, but they exist), you’ll need to either convert them to use app registrations with certificates or exclude them and apply compensating controls. Don’t just exclude them and forget about it.
4. Require MFA for Azure Management
This catches a gap that policies 2 and 3 might miss. The “Microsoft Azure Management” app in Conditional Access covers the Azure portal, Azure PowerShell, Azure CLI, and the Azure Resource Manager API. Even if a user isn’t an admin in Entra, they might have RBAC roles in Azure subscriptions.
| Setting | Value |
|---|---|
| Users | All users |
| Cloud apps | Microsoft Azure Management |
| Grant | Require multifactor authentication |
| Exclude | Break-glass accounts |
This is a belt-and-suspenders policy. If your all-users MFA policy is already enforcing on all cloud apps, this technically overlaps. But having it explicit means if someone later modifies the all-users policy (scoping it to specific apps, adding conditions), Azure management stays protected.
5. Require Compliant or Entra-Joined Device
Device trust is the next layer. This policy says: you can authenticate from anywhere, but you must be on a device that Intune manages and has marked as compliant with your device configuration policies.
| Setting | Value |
|---|---|
| Users | All users |
| Cloud apps | All cloud apps (or specific apps — see note) |
| Grant | Require device to be marked as compliant OR Require Microsoft Entra hybrid joined device |
| Exclude | Break-glass accounts, guest users |
The gotcha: This policy breaks BYOD access unless you have a MAM (Mobile Application Management) strategy. If your organization allows personal devices to access company data, you need to either scope this policy to specific apps or add “Require approved client app” / “Require app protection policy” as alternative grant controls. Don’t deploy this policy org-wide without understanding the BYOD impact first.
6. Block Access from Untrusted Countries
If nobody in your organization needs to sign in from outside the United States (or a small set of countries), block it. Every sign-in from an unexpected country is either a compromised account or an employee on vacation who didn’t tell you.
| Setting | Value |
|---|---|
| Users | All users |
| Cloud apps | All cloud apps |
| Conditions | Locations → Include: All locations, Exclude: Named locations (your trusted countries) |
| Grant | Block access |
| Exclude | Break-glass accounts |
You’ll need to create named locations first: Conditional Access → Named locations → Countries location. Define your trusted countries. Then reference that named location in the policy’s exclusion.
The gotcha: VPNs, travel, and remote employees. If you have people who legitimately work from other countries, you need to account for that. But for most defense contractors — where CUI access should be US-only anyway — this is straightforward.
7. Secure MFA Registration
This one’s subtle. Without it, an attacker who compromises a password for an account that hasn’t registered MFA yet can register their own MFA method and then satisfy all your MFA policies. You’ve effectively lost the account.
| Setting | Value |
|---|---|
| Users | All users |
| User actions | Register security information |
| Conditions | Locations → Include: All locations, Exclude: Named locations (trusted networks) |
| Grant | Require multifactor authentication |
| Exclude | Break-glass accounts |
This requires that MFA registration itself can only happen from trusted networks (your office, your VPN) or from a device that’s already compliant. An attacker operating from an unknown network can’t register MFA even if they have the password.
How to Deploy Without Locking Yourself Out
Deployment order matters. Get it wrong and you’re calling Microsoft support at 2 AM because every account in your tenant — including yours — is blocked.
Phase 1: Low Disruption (Week 1-2)
Deploy these first because they affect the fewest users and have the lowest lockout risk:
- Block legacy authentication — in report-only mode first. Review sign-in logs for 1-2 weeks. Identify any legitimate legacy auth usage. Fix or migrate those apps. Then enforce.
- Require MFA for all admins — admins should already have MFA configured. If they don’t, have them register MFA before you enable the policy. Then enforce. No report-only needed if you’ve confirmed registration.
Phase 2: High Disruption (Week 3-4)
These affect every user. Communicate before you enforce.
- Require MFA for all users — start in report-only mode. Give users a window to register MFA methods (the Authenticator app, phone number, FIDO2 key). Send an email. Set a deadline. Then enforce.
- Require MFA for Azure management — enforce alongside the all-users policy.
- Require compliant or Entra-joined device — this one needs the most planning. Devices must be enrolled in Intune and compliant before you enforce. Start in report-only, identify non-compliant devices, remediate, then enforce.
Phase 3: Tightening (Week 5+)
- Block untrusted countries — report-only first. Check for legitimate sign-ins from unexpected locations. Communicate with traveling employees. Then enforce.
- Secure MFA registration — enforce after you’ve defined your trusted network locations.
The pattern is always the same: report-only → review sign-in logs → communicate → enforce → monitor. Skip any step and you’ll learn about it from your CEO’s locked account.
Break-Glass Accounts
Every guide mentions break-glass accounts. Most don’t tell you how to do them properly. These are emergency-use accounts that bypass all Conditional Access policies so you can recover from a misconfigured policy that locks out every admin.
Create two. Not one. Two. If one is compromised, you have a backup.
Cloud-only. These accounts must be *.onmicrosoft.com accounts. No federated authentication, no hybrid identity. If your identity provider goes down, these accounts still work.
Exclude from ALL Conditional Access policies. Every single policy you create. If you forget to exclude a break-glass account from even one Block policy, you’ve defeated its purpose.
Don’t use obvious names. Not breakglass@, not emergency@, not BreakGlassAdmin. Use names that don’t advertise what they are. An attacker scanning your directory shouldn’t be able to identify your break-glass accounts by name.
Phishing-resistant authentication. These accounts should use FIDO2 security keys — not passwords and SMS. Store the security keys in physically separate secure locations (a safe, a locked drawer in a different building). Two accounts, two keys, two locations.
Alert on every sign-in. Nobody should be signing into these accounts during normal operations. Set up an alert that fires immediately on any authentication attempt.
You can monitor break-glass sign-ins with a KQL query in Log Analytics:
SigninLogs
| where UserPrincipalName in ("account1@yourdomain.onmicrosoft.com", "account2@yourdomain.onmicrosoft.com")
| project TimeGenerated, UserPrincipalName, ResultType, IPAddress, Location, AppDisplayName
| order by TimeGenerated descTest every 90 days. Sign in with each break-glass account quarterly. Verify it works. Verify it bypasses CA policies. Verify the alert fires. Document the test. If you discover your break-glass account is locked out during an actual emergency, you have a very bad day ahead of you.
Common Mistakes
These are the patterns I see most often — in client tenants, on Reddit, and in Microsoft support forums.
Creating per-app policies. “Require MFA for Exchange. Require MFA for SharePoint. Require MFA for Teams.” You now have three policies that do the same thing. When you need to change the MFA requirement, you change it in three places — or forget one. You’ll hit the 195-policy limit faster than you think. Group by requirement, not by app.
No naming convention. Your policy list shouldn’t look like “MFA Policy,” “Block Users,” “New Policy (2).” Adopt a convention like CA001-AllApps-RequireMFA-AllUsers-AnyNetwork. The format is: number, target apps, control, target users, conditions. When you have 15 policies, you’ll thank yourself.
Forgetting to exclude break-glass accounts. This is the number one cause of total tenant lockout. Every policy. Every time. No exceptions.
Skipping report-only mode. “I’ll just enable it, what could go wrong.” Everything. Everything could go wrong. Report-only mode costs you nothing except a few days of patience. Use it.
Not accounting for service accounts. That automation runbook authenticating with a service account? It just failed because you required MFA for all users and service accounts can’t do interactive MFA. Identify your service accounts before deploying MFA policies and either exclude them with compensating controls or migrate them to certificate-based app registrations.
Applying Block + All Cloud Apps without exclusions. This is the instant-lockout scenario. If you create a policy that blocks access to all cloud apps for all users with no exclusions, congratulations — you’ve locked out your own admin account. The only way back is a break-glass account or Microsoft support.
If You’re in GCC High
Everything above works in GCC High. The concepts are identical. The implementation has differences that will cost you hours if you don’t know about them.
The portal is different. Conditional Access lives at entra.microsoft.us, not entra.microsoft.com. If you’re following a tutorial or blog post (including this one, for the screenshots you won’t find here), make sure you’re in the government portal. The commercial portal won’t show your GCC High tenant.
Feature lag is real. Conditional Access conditions and grant controls ship to Commercial first. GCC High gets them weeks to months later. Occasionally, specific conditions (custom security attributes as a condition, for example) take 6-12 months to arrive. If a CA condition works in your commercial test tenant but fails in GCC High, check the Microsoft 365 roadmap for government availability before assuming you misconfigured it.
Named locations use government-specific endpoints. The IP ranges and service endpoints for Microsoft services are different in GCC High. If you’re building named locations based on Microsoft’s published IP ranges, make sure you’re referencing the government cloud IP ranges — not the commercial ones.
Device compliance has different enrollment URLs. If policy 5 (require compliant device) is in your plan, your Intune enrollment and compliance check endpoints are GCC High-specific. Users enrolling devices need the government Company Portal app, and your Intune configuration profiles push to government endpoints. This matters for your documentation and user training materials.
PowerShell management uses different flags. To manage Conditional Access policies via Microsoft Graph PowerShell, you need:
Connect-MgGraph -Environment USGov -Scopes "Policy.ReadWrite.ConditionalAccess"Without -Environment USGov, you’re authenticating against the commercial endpoint. Your commands will either fail silently or manage the wrong tenant.
Break-glass accounts are even more critical. GCC High support escalation is slower — Microsoft’s GCC High support staff are US citizens with security clearances, and there are fewer of them. If you lock yourself out of a GCC High tenant, recovery takes longer than in commercial. Your break-glass accounts are your lifeline. Don’t skip them. Don’t forget to exclude them.
For CMMC and NIST 800-171
If you’re pursuing CMMC Level 2, Conditional Access policies are foundational to your access control posture. They directly support multiple NIST 800-171 access control and authentication requirements — limiting system access to authorized users, controlling remote access, enforcing session controls, and verifying device trust.
You don’t need to enumerate every control mapping to get the point: an environment without Conditional Access has no enforceable access control policy. Security Defaults aren’t sufficient because they’re all-or-nothing. Assessors want to see granular, documented, enforced policies — and they want to see the sign-in logs that prove those policies are working.
What a C3PAO assessor will ask for:
- Documented policies — your CA policy list with a naming convention, descriptions, and justification for each
- Evidence of enforcement — sign-in logs showing policies being applied (not just configured in report-only mode)
- Exception management — documentation of any excluded accounts (break-glass, service accounts) and the compensating controls around them
- Regular review — evidence that you review CA policies periodically and update them when conditions change
Conditional Access gives you the enforcement. Your SSP gives you the documentation. The sign-in logs give you the evidence. All three together satisfy the assessor.
ITAR Considerations
If your organization handles ITAR or export-controlled data, Conditional Access policies help enforce the access boundary that ITAR requires.
Location-based restrictions are critical. ITAR requires that access to controlled technical data be limited to US persons. Policy 6 (block untrusted countries) isn’t just a security best practice — it’s a regulatory control. Block access from outside the United States and you’ve eliminated the most obvious vector for unauthorized foreign access.
Device compliance closes the device gap. ITAR data should only be accessed from managed, compliant devices. Policy 5 ensures that only Intune-managed devices that meet your compliance policies can reach your apps and data. An unmanaged personal device in a foreign internet cafe shouldn’t be able to pull up controlled technical drawings.
Conditional Access + GCC High is the combination. GCC High provides the data residency and sovereignty — your data lives in US datacenters operated by screened US persons. Conditional Access provides the access enforcement — only the right people, on the right devices, from the right locations, can reach that data. You need both. One without the other leaves a gap.
Bottom Line
P1 minimum for Conditional Access. P2 if you need risk-based policies (sign-in risk and user risk as conditions).
Start with the 7 core policies. They cover legacy auth, MFA, device trust, location restrictions, and registration security. Add complexity only when you have a specific requirement that justifies a new policy. Most tenants don’t need more than 10-15 policies total.
GCC High: same concepts, different endpoints. Verify feature availability before assuming a condition or grant control exists in your environment. Use the government portal. Use the government PowerShell flags.
Break-glass accounts aren’t optional. Two accounts, excluded from everything, tested quarterly. This is the one thing you cannot skip.
Need help deploying Conditional Access in a GCC High environment, mapping CA policies to CMMC Level 2 requirements, or ensuring your ITAR compliance posture holds up to scrutiny? Let’s talk. We’ll review your current policies — or build them from scratch — and give you a deployment plan that doesn’t end with a lockout call at 2 AM.