Conditional Access Gap Analyzer
Paste your exported Entra ID Conditional Access policies and get an instant gap analysis: an A-F grade against 18 Microsoft best practice checks, with remediation guidance for every gap.
Step 1: Export your policies
Open Graph Explorer, sign in with an account that can read policies (Global Reader is enough), run this query, and copy the full JSON response:
GET https://graph.microsoft.com/v1.0/identity/conditionalAccess/policiesThe 18 checks explained
Every check maps to a Microsoft-recommended Conditional Access practice. This is the same checklist we use in enterprise Entra ID reviews.
| Check | Severity | What good looks like |
|---|---|---|
| Require MFA for all users | critical | Create a policy targeting All users and All resources that requires multifactor authentication (or an authentication strength). Exclude your emergency access accounts. |
| Require MFA for administrator roles | critical | Create a dedicated policy that targets directory roles (Global Administrator, Security Administrator, and the other privileged roles) and requires MFA or, better, a phishing-resistant authentication strength. |
| Block legacy authentication | critical | Create a policy with client apps condition set to Exchange ActiveSync clients and Other clients, and set the grant control to Block. Legacy protocols cannot enforce MFA. |
| Phishing-resistant MFA for administrators | high | Upgrade the admin MFA policy to use the built-in Phishing-resistant MFA authentication strength (FIDO2 security keys, passkeys, or certificate-based authentication). |
| Require MFA for Azure management | high | Create a policy targeting the Windows Azure Service Management API (or Microsoft Admin Portals) cloud app and require MFA. This covers the Azure portal, Azure CLI, and Azure PowerShell. |
| Block device code authentication flow | high | Create a policy with the Authentication flows condition set to Device code flow and Block as the grant control. Scope exceptions to the few accounts that genuinely need it (conference room devices, CLI on headless systems). |
| Sign-in risk-based policy | medium | Create a policy that targets medium and high sign-in risk and requires MFA (or blocks). Requires Entra ID P2 / Microsoft Entra ID Protection. |
| User risk-based policy | medium | Create a policy that targets high user risk and requires a secure password change. Requires Entra ID P2 / Microsoft Entra ID Protection. |
| Secure security info registration | medium | Create a policy targeting the "Register security information" user action that requires a trusted location, compliant device, or MFA. This stops attackers from registering their own MFA method on a freshly compromised account. |
| Device compliance or hybrid join requirement | medium | Require a compliant device (Intune) or hybrid-joined device for access to sensitive resources. Device trust is the second pillar of Zero Trust after identity. |
| Guest and external user coverage | medium | Create a policy that targets guest and external users and requires MFA, or confirm your all-users MFA policy applies to guests. |
| MFA skipped on trusted locations | medium | Remove trusted location exclusions from MFA policies, or accept the risk consciously. Zero Trust assumes the corporate network is not a security boundary. |
| Sign-in frequency for administrators | low | Add a sign-in frequency session control (for example, 8 hours) to the admin policy so stolen admin sessions expire quickly. |
| Persistent browser session control | low | Add a persistent browser session control set to Never persistent for unmanaged devices, so closing the browser ends the session. |
| App protection for mobile access | low | Require an approved client app or an app protection policy for iOS and Android access, so corporate data on mobile lives inside managed apps. |
| Policies stuck in report-only mode | hygiene | Report-only is a rollout stage, not a destination. Review the sign-in log impact and switch these policies to On (or delete them). |
| Emergency access (break-glass) exclusions | hygiene | Exclude at least one emergency access account from every blocking and tenant-wide policy. If Conditional Access or your MFA provider fails, break-glass accounts are how you get back in. |
| Disabled policy clutter | hygiene | Review disabled policies. Delete the ones that are obsolete; a clean policy set is easier to audit and reason about. |
Why run a Conditional Access gap analysis?
Conditional Access is the policy engine at the heart of Zero Trust in Microsoft Entra ID. Every sign-in to every app flows through it. But policy sets grow organically: an MFA pilot here, an exception for a legacy app there, a report-only experiment someone forgot about. Within a year, most tenants have gaps that no one can see from the portal list view.
The classic failure modes are consistent across environments: legacy authentication left open (the number one MFA bypass), the device code flow unblocked (the phishing technique behind several high-profile 2025 and 2026 campaigns), security info registration unprotected (attackers enroll their own authenticator after a password spray), and tenant-wide policies with no break-glass exclusions (one bad policy locks out every admin).
This analyzer encodes those failure modes into 18 automated checks based on Microsoft's own Conditional Access deployment guidance and templates. It works from a plain JSON export, needs no tenant permissions, and runs entirely in your browser, so you can analyze production policies without a change ticket or a security review of the tool itself.
Treat the grade as a conversation starter, not a compliance verdict. Some warnings (like skipping MFA on trusted locations) are deliberate, documented decisions in some organizations. The value is seeing every deviation from baseline in one place, with the Microsoft Learn reference for each.