Azure AD Conditional Access Policies Most Companies Get Wrong

Conditional Access is Microsoft Entra ID's zero-trust policy engine. When properly configured, it's one of the most effective security controls available in any cloud platform. When misconfigured — and it almost always is — it creates the illusion of security without the substance.

The most dangerous misconfigurations are the ones that appear correct. Policies that look like they enforce MFA or block risky sign-ins, but contain gaps that allow complete bypass. We find these in nearly every Entra ID environment we assess, from mid-market companies to Fortune 500 organizations.

1. Legacy Authentication Is Not Blocked

This is the single most impactful Conditional Access misconfiguration, and the one we find most frequently.

Legacy authentication protocols — POP3, IMAP4, SMTP AUTH, Exchange ActiveSync, Exchange Web Services, Outlook Anywhere (RPC over HTTP), MAPI over HTTP — do not support modern authentication. They cannot satisfy MFA requirements regardless of what Conditional Access policies are in place.

The numbers are damning: more than 99% of password spray attacks target legacy authentication endpoints. Between March and April 2025, Guardz Research tracked a coordinated campaign exploiting legacy protocols that included over 28,000 password authentication attempts, 27,000 basic authentication attempts, and 21,000 legacy Exchange attempts. Admin accounts in the targeted organizations received nearly 10,000 attempts from 432 IPs within 8 hours.

Research by Abnormal Security found that when an attacker is blocked via MFA on modern auth, a common next step is to immediately attempt legacy authentication — and frequently succeed.

How to fix it

First, identify who's still using legacy auth. Run this KQL query in Sentinel:

SigninLogs
| where TimeGenerated > ago(30d)
| where ClientAppUsed in ("Exchange ActiveSync", "IMAP4",
    "MAPI Over HTTP", "Offline Address Book", "Other clients",
    "Outlook Anywhere (RPC over HTTP)", "POP3",
    "Reporting Web Services", "SMTP",
    "Authenticated SMTP", "Exchange Web Services")
| summarize Count = count() by UserPrincipalName,
    ClientAppUsed, AppDisplayName
| sort by Count desc

Then create a Conditional Access policy that blocks all legacy authentication for all users. Deploy in report-only mode first, review the impact using the "What-if" tool, then enforce. Any users still on legacy protocols need to be migrated to modern auth clients — this is non-negotiable.

2. Policies Target Specific Apps Instead of "All Cloud Apps"

The most common architectural mistake: creating CA policies that target specific applications (Office 365, Azure Portal, etc.) rather than using "All cloud apps." This leaves every other registered enterprise application unprotected.

An attacker who can authenticate to an unprotected SaaS application registered in your tenant can establish a foothold and escalate from there. The policy looks comprehensive in the admin portal, but it has blind spots across every app not explicitly named.

How to fix it

Set the target to "All cloud apps" for your core MFA policy. Use exclusions sparingly and only for documented exceptions with compensating controls. Review the "Applications" scope on every CA policy quarterly.

3. Exclusion Lists Have Grown Unchecked

Break-glass accounts must be excluded from CA policies — that's by design. But over time, exclusion lists accumulate: service accounts added during a migration, test users from a pilot, a VIP who complained about MFA prompts, accounts for third-party integrations.

Every excluded account is a permanent CA bypass. Any excluded account that is compromised bypasses all Conditional Access controls — MFA, device compliance, location restrictions, everything.

How to fix it

• Audit all CA policy exclusion lists quarterly
• Document a business justification for every exclusion
• Set calendar reminders to review and prune exclusions
• For service accounts that must be excluded, require modern authentication methods (certificates, managed identities, workload identities) instead of passwords

4. Report-Only Policies Never Enforced

Report-only mode is essential for pre-deployment validation. You should never enforce a CA policy without testing it in report-only first. The problem is when policies stay in report-only indefinitely — often because no one wants to risk the disruption of enforcement, or because the team that created the policy moved on.

A report-only policy provides zero protection while creating a false sense that controls are in place. We regularly find environments with 15-20 CA policies where a third of them are still in report-only mode months or years after creation.

How to fix it

• Audit all CA policies and flag any in report-only mode that have been there for more than 30 days
• For each, use the "What-if" tool to assess impact, then schedule enforcement
• Establish a policy lifecycle: report-only for 7-14 days maximum, then enforce or delete

5. Break-Glass Accounts Are Misconfigured

Break-glass (emergency access) accounts are excluded from all CA policies by design — they're the recovery mechanism if all normal admin accounts are locked out. This makes them high-value attack targets: permanent CA exclusions with Global Admin rights.

The most common mistakes we see:

• Only one break-glass account exists. Create two, with geographic/timezone separation and different credential storage. If one is compromised during a recovery event, the other is available.
• Obvious naming. breakglass@domain.com or emergencyaccess@domain.com are obvious targets for password spray attacks. Use non-obvious naming.
• Password-only authentication. Use hardware FIDO2 security keys (YubiKey). Certificate-based authentication or passkeys satisfy Microsoft's mandatory MFA requirement while remaining outside Conditional Access scope.
• Password stored in one location. Split the password across two separate locations (e.g., two separate Azure Key Vaults, or a Key Vault plus a physical sealed envelope in a safe). Compromise of one location still requires the other half.
• No monitoring. Any sign-in to a break-glass account should trigger an immediate alert in Sentinel or Microsoft Defender. Also alert on any modification to CA policies — an attacker may try to add or remove exclusions.
• Never tested. Verify these accounts can actually sign in monthly. Verify credentials haven't expired. Verify Key Vault access still works.

Microsoft's mandatory admin MFA enforcement applies even to break-glass accounts unless you use FIDO2 or certificates, which satisfy the MFA requirement without relying on Conditional Access policies.

6. Named Location IP Ranges Are Wrong

Trusted locations configured with incorrect IP ranges — especially in hybrid environments where traffic originates from proxies or VPN gateways with different public IPs than expected — cause two problems:

• Users at the office get MFA prompts they shouldn't, creating helpdesk overload and user frustration
• Users outside the office bypass MFA because stale IP lists don't reflect current network architecture

The inverse is equally dangerous: NAT addresses that cover both corporate and external traffic marked as trusted. Corporate IP ranges change during office moves, ISP changes, and VPN infrastructure upgrades. CA policies don't update themselves.

How to fix it

• Verify all named location IP ranges quarterly — test from actual office locations and VPN endpoints
• When blocking high-risk countries, set IncludeUnknownCountriesAndRegions to true. IP geolocation databases have gaps; an unknown country that falls through the filter is often more suspicious than a known risky one.
• Document all trusted IP ranges with the business justification and the network path they represent

7. The "Remember MFA" Setting Overrides Conditional Access

The legacy MFA portal contains a setting that allows users to skip MFA for a specified number of days on a trusted device. This is separate from Conditional Access. What most administrators don't realize: this setting overrides MFA requirements from Conditional Access policies.

An attacker who compromises a device where "Remember MFA" is active can bypass MFA for the specified number of days — regardless of what your CA policies require.

How to fix it

Disable "Remember MFA on trusted device" in the legacy MFA portal. Let Conditional Access handle all MFA decisions. While you're there, disable per-user MFA (the legacy per-user setting) entirely — it can conflict with CA policies and creates unpredictable behavior.

8. Security Defaults When You Have P1 Licenses

Security Defaults are Microsoft's baseline protection for tenants that don't use Conditional Access. They block legacy authentication and require MFA "when necessary." For organizations without Entra P1 licenses, they're better than nothing.

But Security Defaults have significant limitations: no break-glass exclusions, no named locations, no device compliance, no granularity. Most critically, "when necessary" often means only risky sign-ins get MFA prompts — not all sign-ins. Admin accounts always get MFA; regular users may not.

Many organizations are licensed for Entra P1 but still have Security Defaults enabled. Microsoft considers this a misconfiguration and recommends migrating to custom CA policies if the license supports it.

How to fix it

If you have Entra ID P1 or P2 licenses, disable Security Defaults and implement custom Conditional Access policies. This gives you full control over MFA requirements, device compliance, location-based access, and break-glass exclusions.

Documented Conditional Access Bypass Techniques

Beyond misconfigurations, there are documented techniques for bypassing Conditional Access entirely — some confirmed by Microsoft as "by design." Security teams should be aware of these limitations:

• Resource exclusion bypass: Excluding any single resource from a CA policy causes certain default scopes (like User.Read, email, openid, profile) to escape enforcement across all resources. This provides access to basic tenant and user data without triggering CA controls.
• Device Registration Service bypass: The Device Registration Service cannot be protected by a "Trusted Location" CA control — only MFA can be enforced on it. Devices can be registered from untrusted locations regardless of location-based policies. Microsoft MSRC confirmed this is expected behavior.
• Resources excluded from CA enforcement: Several Microsoft resources — including Microsoft Intune Checkin, Windows Notification Service, Microsoft Mobile Application Management, and the Authenticator App — cannot be protected by Conditional Access at all. They can be used to verify username/password combinations without generating strong authentication required log entries.
• User-agent spoofing: Platform conditions in CA policies are determined by the user agent string, which is trivially falsified. Attackers cycle through user agents until finding one with more permissive policies.

The Entra ID Security Hardening Checklist

Based on our assessment findings, here's the prioritized checklist we recommend for every Entra ID environment:

1. Block legacy authentication via CA policy (highest-impact single action)
2. Require MFA for all users, not just admins
3. Configure break-glass accounts with FIDO2 keys, excluded from all CA policies, with sign-in alerting
4. Enable sign-in risk and user risk policies (requires Entra P2 + Identity Protection)
5. Audit and clean exclusion lists quarterly
6. Enforce compliant or hybrid-joined device requirement for sensitive applications
7. Verify named location IP ranges are accurate (test quarterly)
8. Disable "Remember MFA on trusted device" in the legacy MFA portal
9. Migrate from Security Defaults to custom CA policies if licensed for Entra P1+
10. Run new CA policies in report-only first; use "What-if" tool before enforcement
11. Monitor for CA policy changes — any modification should trigger an alert
12. Disable per-user MFA (legacy setting) and let CA handle MFA requirements
13. Block access from high-risk countries using Named Locations with IncludeUnknownCountriesAndRegions = true
14. Require phishing-resistant MFA (FIDO2/passkeys) for all admin roles

The Bottom Line

Conditional Access is not a set-and-forget control. It requires ongoing validation, quarterly audits of exclusions and named locations, testing of break-glass accounts, and awareness of documented bypass techniques. The policies you deployed 18 months ago may no longer reflect your network architecture, your user population, or the threat landscape.

The gap between "we have Conditional Access policies" and "our Conditional Access policies are actually effective" is where attackers live. Close that gap.