Conditional Access: audit the exclusions, not just the policy names

Read the effective design

A tenant can have policies named “All users MFA” and still have a materially narrower effective scope. Export the policy settings and the objects referenced by included and excluded groups. Record enabled, report-only and disabled states separately. Review the authentication requirements and applicable resources, conditions and devices. The aim is to establish what the selected user population encounters under the relevant conditions, without disrupting live sign-ins.

Reconcile exception membership

An excluded group often outlives the migration or application issue that created it. Compare current membership with approved exceptions. For each exception, look for an accountable owner, a business dependency, an expiry or review date and compensating controls. Nested or dynamic relationships may need additional explanation. Do not assume an empty-looking list in one screen captures every route by which an identity receives an exclusion.

Treat emergency access as a separate design

Emergency accounts exist to support recovery when normal administrative access is unavailable. They need resilient authentication, carefully designed policy treatment, monitoring and periodic validation. They should not become ordinary day-to-day administrator accounts. Follow current Microsoft guidance and validate your recovery dependency chain; copying an old “exclude from everything” recipe can create a dangerous gap. Review the design with the owner before making changes that could lock out the tenant.

Distinguish administrator and workload access

Human administrators, automation accounts and service principals are different populations. Do not assume a user MFA policy governs application-only access. Identify privileged roles, their assignment method and the relationships between administrators and applications. Assess standing access, approval and review practices against agreed criteria. Findings should describe exactly which identity class and assignment were examined.

Recommend controls that the tenant can operate

Conditional Access depends on applicable Entra licensing; Microsoft documents P1 requirements and Business Premium support, with additional requirements for risk-based capabilities. Verify the actual assigned entitlement rather than inferring features from a broad E3 or E5 label. When a proposed feature is unavailable, separate an immediate feasible improvement from a licensed enhancement. Procurement, operational ownership and recovery testing belong in the remediation plan.

Plan the operational handover

During an MSP handover, explicitly transfer ownership of exception registers and recovery procedures. Confirm that departing administrators lose access only after the receiving team has validated its own approved administrative and emergency paths.

Related Atlant Security guidance: preparing identity evidence and preserving responsibilities during provider changes. Use these to connect the review with the evidence and responsibilities needed after it.

Prepare the review

Our Conditional Access review and Entra ID audit describe the evidence to discuss. Begin with approximate counts, identity source and known exceptions through the homepage planner. Policy exports, group membership and recovery account details should be shared only through the agreed confidential channel, after the access and handling arrangements are approved.