Conditional Access policy gaps IT admins commonly miss

Having Conditional Access policies is not the same as having coverage. A tenant can have fifteen CA policies and still leave guest accounts, legacy email clients, or entire application categories completely unprotected. The gap is invisible until something goes wrong.

This is one of the most consistent findings we see across M365Clarity scans: organisations that believe they have CA configured well, but whose policies have structural gaps that leave real attack surface exposed.

The four most common CA gaps

1. No enforced MFA-for-all-users policy

This is the most critical gap and the most common. Many tenants have MFA required for admins, or for specific applications, but no policy that covers all users across all cloud apps. An attacker who compromises a non-admin account with a weak password has open access.

The fix is a single CA policy: Users — All users, Cloud apps — All cloud apps, Grant — Require multifactor authentication. Exclude your emergency access accounts from this policy.

2. Legacy authentication not blocked

Legacy authentication protocols — Exchange ActiveSync, IMAP, POP3, SMTP AUTH, and older Office clients — do not support modern authentication and therefore cannot be challenged for MFA. A CA policy that requires MFA will not apply to a connection made via legacy auth. Attackers know this and target it specifically.

Block it with a CA policy: Users — All users, Client apps — Exchange ActiveSync clients, Other clients, Grant — Block access. This is one of the highest-impact, lowest-risk changes you can make.

3. Policies targeting specific apps but not all apps

A common pattern is to have CA policies for Exchange Online and SharePoint, but nothing covering other cloud apps in your tenant — including third-party SaaS apps that are integrated via Entra ID SSO. If an attacker authenticates to one of these unprotected apps using stolen credentials, they are in without MFA.

The target state is a baseline "All cloud apps" policy covering all users, with more specific policies layering additional requirements on top of it.

4. Policies in report-only mode

Report-only policies log what would have happened if the policy were enforced, but they do not enforce anything. They are a useful testing mechanism, but a policy sitting in report-only mode for months is providing no protection. We consistently see tenants with two to five report-only policies that were never promoted to enforcement.

The coverage map problem

The difficulty with CA coverage is that there is no built-in view in Entra that shows you "which users and apps are protected by at least one enforced policy." You can look at each policy individually, but mentally combining fifteen policies to identify gaps is not something a human can do reliably.

This is why a structured coverage analysis — looking at each policy's conditions and grant controls together — produces findings that a policy-by-policy review misses.

Practical steps to audit your CA coverage

1. Export your CA policies from Entra ID: Identity Protection → Conditional Access → Policies
2. For each policy, note: state (enabled/report-only/disabled), users covered, apps covered, grant controls
3. Check: is there at least one enforced policy covering All Users + All cloud apps + Require MFA?
4. Check: is there at least one enforced policy targeting Other clients (legacy auth) with a Block grant?
5. Identify any policies in report-only that have been there more than 30 days