Find the Gaps in Your
Conditional Access Policies

Conditional Access Policies: The Gaps That Get Small Businesses Breached

Conditional Access is the single most important security control in your Microsoft 365 environment. It's Microsoft's Zero Trust policy engine — the gatekeeper that decides who gets in, from where, on what device, and under what conditions. Without it, your M365 tenant is essentially a front door with no lock.

The problem isn't that businesses haven't heard of Conditional Access. It's that most implementations are incomplete. Policies get created reactively, one at a time, without a framework. Critical scenarios get missed. Exclusions accumulate. And the result is a false sense of security — the admin panel shows green checkmarks while attackers walk through the gaps.

The assessment tool above evaluates your Conditional Access setup against the eight most common attack scenarios we see exploited in real-world breaches. Below, we explain what Conditional Access actually does, where most businesses get it wrong, and how to build a policy framework that holds up under pressure.

What Is Conditional Access in Microsoft 365?

Conditional Access is a feature of Microsoft Entra ID (formerly Azure Active Directory) that enforces access decisions based on real-time signals. At its simplest, it works as a series of if-then statements: if a user wants to access a resource, then they must meet certain conditions before access is granted.

Those conditions can evaluate a wide range of signals — who the user is, what device they're using, where they're connecting from, which application they're trying to access, what their risk level is, and whether their device meets compliance standards. Based on those signals, Conditional Access can grant full access, require MFA, limit what the user can do, or block access entirely.

This is fundamentally different from just "having MFA turned on." Security Defaults give you a binary switch — MFA for everyone, with no exceptions and no granularity. Conditional Access gives you a policy engine that can differentiate between an admin accessing the Azure portal from an unrecognized IP address (block or require phishing-resistant MFA) and a standard user checking email from a compliant company laptop on your corporate network (allow with standard MFA).

The 8 Attack Scenarios Conditional Access Should Block

Every Conditional Access gap maps to a specific attack technique. Understanding these scenarios is the difference between checking boxes and actually stopping breaches.

1. Password Spray from Foreign IPs

Password spray is one of the most common attacks against M365 tenants. Attackers use automated tools to try a small number of common passwords (like "Company2024!" or "Winter2025") against every account in your directory. They rotate through accounts slowly to avoid lockout thresholds. When legacy authentication protocols are still open, these attacks bypass MFA entirely because legacy protocols cannot perform multi-factor authentication.

The fix is a combination of three Conditional Access policies: enforce MFA for all users on all cloud apps, block legacy authentication completely, and block or restrict sign-ins from countries where your organization doesn't operate. Together, these three policies eliminate the majority of automated credential attacks.

2. Session Token Theft from Unmanaged Devices

When a user signs into M365 from a personal laptop, the browser stores a session token. If that device is compromised — through malware, a phishing attack, or simply being lost — the attacker can extract that token and replay it. The token grants full access to the user's M365 resources without triggering MFA, because authentication has already occurred.

Conditional Access addresses this by requiring device compliance through Intune. Only managed devices that meet your security baselines (encryption enabled, OS updated, antivirus active) can access M365. For organizations that can't fully manage every device, session controls can restrict unmanaged devices to browser-only access with no download capability, and sign-in frequency policies can limit how long session tokens remain valid.

3. MFA Fatigue and Push Notification Bombing

An attacker who has stolen credentials sends repeated MFA push notifications to the user's phone, hoping they'll approve one out of frustration or confusion. This technique has been used in high-profile breaches. Standard push-based MFA is vulnerable to this attack.

The mitigation is phishing-resistant MFA for privileged accounts — FIDO2 security keys, Windows Hello for Business, or certificate-based authentication. These methods cannot be phished, replayed, or approved accidentally. At minimum, Conditional Access should require authentication strength policies that enforce phishing-resistant methods for anyone in an admin role.

4. Impossible Travel Credential Compromise

An attacker signs in from a foreign country minutes after the user's legitimate sign-in from their home location. Without risk-based Conditional Access policies, this anomaly goes unchallenged. Microsoft Entra ID Protection detects these patterns and assigns a risk score, but the detection is useless without a Conditional Access policy that acts on it.

5. Lateral Movement Through Standing Admin Privileges

When admin roles are permanently assigned, a compromised admin account gives the attacker immediate, persistent access to the entire tenant. Privileged Identity Management makes those roles just-in-time — admins activate their role when needed, provide justification, and the role expires automatically. Conditional Access should require additional authentication strength for any role activation.

6. Persistent Unauthorized Access via Long-Lived Sessions

Default M365 sessions can persist for up to 90 days. That means a single successful breach can give an attacker months of access before anyone notices. Sign-in frequency controls in Conditional Access force re-authentication at intervals you define — daily for sensitive applications, a few hours for high-risk scenarios.

7. Credential Stuffing from Breached Databases

When credentials appear in public breach databases, Microsoft's user risk engine detects it. But without a Conditional Access policy that forces a password change when user risk is elevated, the compromised credentials remain active and usable.

8. Administrative Lockout from Misconfiguration

This is the self-inflicted wound. A Conditional Access misconfiguration, a federation failure, or an MFA outage locks every administrator out of the tenant. Without cloud-only break-glass emergency accounts excluded from all CA policies, recovery requires a Microsoft support case and can take days. Every organization using Conditional Access needs at least two of these accounts, and they need to be monitored for unauthorized use.

The 7 Most Common Conditional Access Mistakes

After reviewing Conditional Access configurations across dozens of organizations, the same mistakes appear repeatedly. These aren't edge cases — they're the norm.

Relying on Security Defaults instead of Conditional Access. Security Defaults are a one-size-fits-all baseline. They can't differentiate between users, devices, apps, or risk levels. You can't exclude break-glass accounts, and you can't require device compliance. For any organization beyond a handful of users, Security Defaults are insufficient.

Blocking legacy auth for some users but not all. Partial implementation is a partial solution. If even one user or one app can authenticate via legacy protocols, attackers will find it. The policy needs to apply globally, with only carefully scoped exceptions for documented business needs.

Using trusted locations to bypass MFA. Exempting your corporate IP range from MFA requirements violates the core principle of Zero Trust. If an attacker gains access to your network — through VPN compromise, a malicious insider, or physical access — they bypass your most important control. MFA should be required everywhere, regardless of network location.

No risk-based policies. Many organizations have Conditional Access but only use static conditions. They're missing sign-in risk and user risk policies entirely. These dynamic signals from Entra ID Protection detect compromised credentials, impossible travel, and anomalous behavior in real time — but only if you build Conditional Access policies that act on them.

Policy sprawl without a framework. Policies get added reactively — one for this app, one for that user group, one after an audit finding. Eventually, nobody can tell which policies overlap, which have gaps, and whether every scenario is covered. Microsoft recommends a persona-based framework with consistent naming conventions.

Exclusions that never get reviewed. A user gets excluded from a policy "temporarily" during onboarding or troubleshooting. That exclusion stays forever. Over time, the exclusion list grows and your actual enforcement drifts further from your intended policy. Exclusions should be time-bound through PIM or reviewed on a regular schedule.

No break-glass accounts. This is still surprisingly common. Organizations deploy comprehensive Conditional Access policies without creating emergency access accounts. One misconfiguration or provider outage, and every admin is locked out.

How to Build a Conditional Access Framework That Works

A solid framework doesn't require dozens of policies. For most small and mid-sized businesses, six to ten well-designed policies cover the critical scenarios. Here's the priority order:

1. Block legacy authentication for all users, all cloud apps. This is policy number one. No exceptions outside of documented, time-limited business needs. Deploy in report-only mode first, verify no legitimate traffic, then enforce.
2. Require MFA for all users on all cloud apps. Use authentication strength to require phishing-resistant methods for admin roles and standard MFA for everyone else. Exclude only your break-glass emergency accounts.
3. Block sign-ins from countries where you don't operate. Define Named Locations for countries where your staff works. Block everything else. This eliminates a massive volume of automated attacks.
4. Require device compliance for access to sensitive apps. Start with your most sensitive applications — email, SharePoint, financial systems — and expand. Use Intune compliance policies as the enforcement mechanism.
5. Enforce sign-in risk policies. Require MFA for medium-risk sign-ins. Block high-risk sign-ins entirely. This catches impossible travel, TOR access, and malware-linked IPs in real time.
6. Enforce user risk policies. Require a secure password change for medium-risk users. Block high-risk users until an admin investigates. This catches breached credentials automatically.
7. Control session lifetime. Set sign-in frequency for sensitive apps (daily or every few hours). Disable persistent browser sessions for unmanaged devices. This limits the damage from token theft.

Frequently Asked Questions