Conditional Access Review Checklist: 12 Things to Check in Your Tenant

Why review Conditional Access on a schedule

Conditional Access policies tend to accumulate. A policy is added for a project, another for an incident, a third to fix a sign-in problem, and a year later nobody is sure which ones still matter or whether they leave a gap. A Conditional Access review is a short, repeatable check that answers two questions: does any sign-in slip through with weaker controls than you intended, and could a mistake lock you out? This checklist has twelve items, ordered roughly from lockout prevention to day-to-day hygiene. It assumes you can read policies in the Microsoft Entra admin center and the sign-in logs, and that you will change nothing until you have tested it.

If you can export your policies as JSON, the Conditional Access policy reviewer will scan an export for common gaps such as missing MFA or broad exclusions. Use it to prepare questions, not to decide. Only you know why a policy exists.

The twelve checks

1. Emergency access accounts exist and are excluded. Microsoft recommends at least two emergency access, or break-glass, accounts: cloud-only, on the onmicrosoft.com domain, with the Global Administrator role. Check that each is excluded from any policy that blocks or restricts sign-in, ideally through a dedicated group. Report-only policies do not block access and do not need the exclusion. Check that sign-in alerts fire when these accounts are used.

2. Emergency access accounts have been tested recently. Microsoft's guidance is to validate them at least every 90 days, and whenever IT staff change. Confirm someone has signed in with each account under today's policies, and that the credentials still work and have not expired or been cleaned up for inactivity. Prefer a phishing-resistant method such as a passkey (FIDO2) that differs from your normal admin accounts.

3. Every policy is in a known state. List all policies with their state: on, off or report-only. A policy left off for months is clutter, and one left in report-only forever is protecting nobody. Note that the limit is 240 policies per tenant across all states, including off and report-only, so tidy-ups are not only cosmetic.

4. Changes go through report-only mode first. Before turning a new or modified policy on, run it in report-only mode and look at the Report-only tab of real sign-ins. Microsoft's deployment guidance suggests at least a week in report-only before enforcement. Check that your process actually follows this, rather than relying on memory.

5. Legacy authentication is blocked, or its use is understood. Legacy protocols cannot do multifactor authentication. In the sign-in logs, filter the client app column for the legacy protocols, on both the interactive and non-interactive tabs. If something still uses them, find the owner before blocking. If nothing does, a block policy for Exchange ActiveSync clients and other clients, with the emergency accounts excluded, closes an easy route for password attacks.

6. Administrators are required to use strong authentication. Look for a policy that targets directory roles, not a hand-maintained list of names, and requires multifactor authentication or, better, an authentication strength that demands phishing-resistant methods. Check that it covers every privileged role you use and that it applies to all cloud resources, not just one portal.

7. All users are covered by an MFA requirement. Find the policy that requires MFA for everyone and read its exclusions line by line. Exclusions for service accounts, shared mailboxes or an old test group are common. Each one needs an owner and a reason. Microsoft also advises that every application should be covered by at least one policy; a policy that targets all resources avoids having to update it for each new app.

8. Device compliance rules match reality. If a policy requires a compliant or hybrid-joined device, check which apps and users it covers, and what happens for personal devices, guests and platforms you do not manage. Device compliance depends on your device management configuration, so verify devices are actually reporting. A compliance requirement that quietly excludes a platform is not a requirement.

9. Guests and external users are considered. Check whether guests get an MFA requirement, and whether you trust MFA or device claims from partner organizations through cross-tenant access settings. Decide this deliberately.

10. Location rules and named locations are current. Trusted locations that include a former office, a VPN range you no longer use or a large address block are quietly weakening policies that skip MFA from trusted places. Review named locations and any country blocks, and make sure emergency accounts are excluded from location blocks.

11. Risk-based policies are present if you are licensed for them. Sign-in risk and user risk conditions need Microsoft Entra ID P2. If you have it, check that the policies exist and what they do. If you do not, note that as an accepted gap.

12. Ownership, naming and change control. Policies have no built-in owner field, so check that names follow a convention, that an owner register exists, and that changes are logged and reviewed. Consider protected actions, which can require fresh authentication before anyone creates, changes or deletes a policy.

How to run the review

Block out an hour and use a copy of the policy list, not the live portal, so you can annotate it. For each policy record the name, state, users included and excluded, resources, conditions and grant or block controls. Then walk the twelve checks and mark each as fine, a gap, or unknown.

For anything unknown, use the What If tool to simulate a sign-in for a given user, app and location and see which policies apply. Remember that a simulation is a good guide but does not replace testing with a real test user.

Making changes safely

Change one thing at a time. Put the proposed policy in report-only mode, wait for a representative period that includes month-end or any unusual business cycle, and review the results by user and by client app. Tell affected users in advance. Keep a rollback step ready: disabling the policy, or excluding a user, are the quick options, and exclusions should be rare and removed as soon as possible.

Do not combine a block policy with all resources and all users unless you have checked the exclusions twice, because that combination is the classic route to locking administrators out.

What this checklist does not do

It does not prove your tenant is secure. It does not cover application permissions, Privileged Identity Management or mail flow. It also cannot tell you whether a policy matches your risk appetite. It finds the obvious gaps and the ownerless leftovers. Repeat it every quarter, which fits neatly with the emergency account test, and record what you found so that the next review starts from facts.

For related reading, the error codes that Conditional Access produces, such as AADSTS53003, are covered in the guide to AADSTS error codes. Confirm specifics against current Microsoft Learn pages before you change a production policy.