Conditional Access (CA) in Entra ID is often called "the silver bullet" for identity security. In reality, it’s a set of knobs that can be turned the wrong way and lock out legitimate users while still letting attackers slip through.
Common Mis‑configurations
- All‑users, all‑apps blanket allow – The default policy that says "allow everything" defeats the purpose.
- Excluding admin accounts – Many orgs exclude privileged users from MFA, thinking they’re trusted.
- Location‑based exclusions – Trusting a corporate IP range without verification opens you to VPN hijack.
- Missing session controls – No sign‑in frequency limits, so a compromised token can be reused forever.
Three Core Policies You Must Have
- Require MFA for all privileged accounts
- Block legacy authentication (basic auth, IMAP/POP)
- Enforce device compliance for sensitive apps
Policy 1 – MFA for Privileged Users
Make sure the policy targets not only Azure AD roles but also any custom groups you use for admin delegation.
Policy 2 – Block Legacy Auth
This blocks IMAP, POP, and SMTP auth that bypasses MFA. If you need to keep legacy mail, use App Passwords with limited scope.
Policy 3 – Device Compliance for Sensitive Apps
This forces any admin accessing the Azure portal to be on a device that passes Intune compliance (full disk encryption, no jailbreak, etc.).
Testing Your Policies
Never roll out a new CA policy to "All users" without testing. Use the "Report‑Only" mode first, then review the sign‑in logs.
After a week, check the sign‑in logs for any failures that should have been blocked. Then flip the policy to "Enforced".
Remediation Checklist
- Audit all existing CA policies – look for "grantControls: allow" with no MFA.
- Ensure every privileged group is covered by the MFA policy.
- Verify that legacy auth is blocked for all apps except those explicitly allowed.
- Enable device compliance checks for any app that can change Azure resources.
- Set up alerts on "conditionalAccess:policyDenied" events in Azure Sentinel.
Final Thought
Conditional Access is a framework, not a single setting. Treat each policy as a rule in your security playbook: define the scope, enforce MFA or device compliance, test in report‑only mode, then enable.
When done right, CA reduces the attack surface dramatically. When mis‑configured, it gives you a false sense of security while attackers walk right through the back door.