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 - locking out legitimate users while still letting attackers slip through.
One thing to understand up front: Conditional Access never grants access. With no policies, a correct password is enough. Each policy only adds requirements (MFA, a compliant device) or blocks. So the gaps are almost always about what your policies don't cover.
Common Misconfigurations
- Policies that don't cover everyone - MFA required for "IT Staff" but not for the rest of the tenant, or only for a handful of apps. Anything a policy doesn't include is password-only.
- Excluding admin accounts - Many orgs exclude privileged users from MFA, thinking they're trusted or to avoid friction. Those are exactly the accounts attackers want.
- Broad exclusions nobody reviews - A "CA Exclusions" group that started with one service account and now has forty members.
- Trusted location exclusions - Skipping MFA on the corporate IP range means anyone on that network (or on a compromised VPN session) gets password-only access.
- Legacy authentication left open - Protocols like IMAP, POP and SMTP AUTH can't do MFA, so they're a straight path around it unless you block them.
- No break-glass accounts - The opposite failure: one bad policy and nobody can sign in to fix it.
Before Anything Else: Break-Glass Accounts
Create two cloud-only emergency access accounts with Global Administrator, long random credentials (ideally FIDO2 keys) stored securely offline, and exclude them from every Conditional Access policy. Alert on every sign-in to them. This is the safety net that lets you fix a mistake instead of opening a Microsoft support case while your whole tenant is locked out.
Every policy below excludes the break-glass accounts. Replace the placeholder object IDs with yours before you run anything.
Three Core Policies You Must Have
- Require MFA for all privileged roles
- Block legacy authentication
- Require a compliant device for admin portals
The examples use Microsoft Graph PowerShell and create every policy in report-only mode, so nothing is enforced until you've reviewed the impact.
Policy 1 - MFA for Privileged Roles
Target directory roles, not just an "Admins" group - role-based targeting follows the permission, so a newly assigned Global Admin is covered automatically. Once this is working, go further: require MFA for all users, and require phishing-resistant MFA (an authentication strength) for admins.
Policy 2 - Block Legacy Authentication
In Conditional Access, other covers the legacy protocols - IMAP, POP, SMTP AUTH, MAPI and older Office clients - and exchangeActiveSync covers basic-auth ActiveSync. These can't satisfy MFA, so blocking them closes a common bypass.
If something still depends on them - usually a scanner or line-of-business app sending mail - move it to OAuth or to an SMTP relay connector with its own restrictions. Don't reach for app passwords: they're a legacy per-user MFA feature, they don't work with Conditional Access MFA, and they're exactly the kind of long-lived secret you're trying to get rid of.
Policy 3 - Compliant Devices for Admin Portals
This forces admins managing Azure (portal, CLI, PowerShell) to be on a device that passes Intune compliance - encryption, supported OS, no jailbreak and so on. A stolen admin password used from an attacker's laptop fails here even if they also phish the MFA prompt. Consider adding the "Microsoft Admin Portals" app to the same policy to cover the Entra, Microsoft 365 and Exchange admin centers.
Testing Your Policies
Never roll out a new CA policy to "All users" without testing. Report-only mode evaluates the policy on every sign-in and records what it would have done, without enforcing it.
Give it a week, then check the sign-in logs (or the Conditional Access insights and reporting workbook) for results of Report-only: Failure. What you're looking for is legitimate sign-ins the policy would have blocked - the service account, the conference-room device, the one executive on an old mail client. Fix or deliberately exclude those, then turn the policy on:
Remediation Checklist
- Create and exclude two break-glass accounts, and alert on any sign-in to them.
- Audit existing policies for gaps: which users, apps and client types are covered by no MFA policy at all?
- Review every exclusion - groups, users and trusted locations - and remove what can't be justified.
- Ensure every privileged role is covered by an MFA policy, by role rather than by group.
- Block legacy authentication for everyone, with named, documented exceptions only.
- Require compliant devices for anyone who can change Azure resources.
- In Microsoft Sentinel, alert on changes to CA policies (
AuditLogsoperations on conditional access policies) and review sign-ins whereConditionalAccessStatus == "failure".
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 misconfigured, it gives you a false sense of security while attackers walk right through the back door.