Conditional Access policy review for Microsoft Entra ID
A Conditional Access policy review is an independent assessment of your organization’s Conditional Access policies in Microsoft Entra ID. These policies decide whether a sign-in is allowed and what it must satisfy, such as multifactor authentication or a compliant device. The review compares them with Microsoft’s guidance and reports exclusions, gaps, and lockout risks, with evidence for each.
What Microsoft recommends for Conditional Access
Microsoft’s public documentation sets out a baseline for Conditional Access. The review checks your tenant against each recommendation below that your licensing and the agreed scope include, quoted from its Microsoft Learn source.
Use the Secure foundation templates as the base, deployed together as a group
What the review checks: The tenant’s policies are compared with the eight Secure foundation templates, recording each match as On, Report-only, or Off. Template-created policies that still exclude only their creator, and leftover classic policies, are flagged.
“Microsoft recommends these policies as the base for all organizations. Deploy these policies as a group.”
Conditional Access policy templates, Microsoft Learn Licensing: Conditional Access needs Microsoft Entra ID P1 or Microsoft 365 Business Premium, and compliant-device templates also need licensed device management, such as Microsoft Intune.
Have a baseline MFA policy for all users and all resources, with no app exclusions
What the review checks: Whether a policy set to On covers All users and All resources with no resource exclusions, and requires multifactor authentication or the Multifactor authentication strength. User exclusions are compared with Microsoft’s guidance, and trusted-location exclusions are noted, because they remove MFA on those networks.
“Microsoft recommends all organizations create a baseline Conditional Access policy that targets: All users, all resources without any app exclusions, and requires multifactor authentication.”
Require multifactor authentication for all users, Microsoft Learn Licensing: Microsoft lists the all-users strong authentication policy as requiring Microsoft Entra ID P1.
Require phishing-resistant MFA with Conditional Access for at least the listed admin roles
What the review checks: Whether a policy set to On applies the Phishing-resistant MFA strength to at least the roles Microsoft lists, and whether admins registered those methods first. Admin access through administrative unit-scoped or custom roles is flagged, as role-targeted policies apply only to built-in roles.
“Microsoft recommends requiring phishing-resistant multifactor authentication for at least the following roles:”
Require phishing-resistant multifactor authentication for administrators, Microsoft Learn Licensing: Microsoft lists the phishing-resistant policy for privileged roles as requiring Microsoft Entra ID P1.
Block legacy authentication with Conditional Access, as those protocols can’t do MFA
What the review checks: Whether a policy set to On blocks Exchange ActiveSync clients and Other clients for All users and All resources, and which accounts are excluded. Where the agreed access includes sign-in logs, remaining legacy sign-ins are measured on the interactive and non-interactive tabs.
“Microsoft recommends that organizations block authentication requests using legacy protocols that don't support multifactor authentication.”
Block legacy authentication with Conditional Access, Microsoft Learn Licensing: Microsoft lists this policy under Microsoft Entra ID P1, and security defaults can block legacy authentication without it.
Exclude emergency access accounts from policies that block or restrict sign-in
What the review checks: Whether two or more cloud-only emergency access accounts hold Global Administrator as a permanent active assignment and sign in with a passkey (FIDO2) or certificate-based authentication. Each enforced policy that blocks or restricts sign-in is checked for their exclusion.
“Exclude emergency access accounts from Conditional Access policies that block or restrict sign-in.”
Manage emergency access accounts in Microsoft Entra ID, Microsoft Learn Test regularly that emergency access accounts can sign in under current policies
What the review checks: Evidence of validation within the last 90 days, in sign-in logs or exported logs, since built-in sign-in log retention is 30 days at most. Also checked: contingency policies for an outage and, where logging is in scope, an alert on every sign-in by these accounts.
“Regularly test (for example, every quarter) that emergency access accounts can sign in successfully with your current Conditional Access configuration.”
Manage emergency access accounts in Microsoft Entra ID, Microsoft Learn Use exclusions sparingly, only for trusted users, and add them back as soon as possible
What the review checks: Every user, group, role, and resource exclusion across all policies, and who sits in each exclusion group. Exclusions beyond emergency access and documented service or sync accounts are flagged, noting that other policies can still require MFA for excluded users.
“Use exclusions sparingly, only in situations where the user is trusted. Add users back to the policy or group as soon as possible.”
Plan a Conditional Access deployment, Microsoft Learn Require risk remediation when user risk is High
What the review checks: Whether a policy set to On, for All users and All resources, requires risk remediation at High user risk, separate from the sign-in risk policy. Legacy risk policies in Microsoft Entra ID Protection, which Microsoft’s documentation lists for retirement on October 1, 2026, are flagged.
“Organizations should select Require risk remediation when user risk level is High.”
Configure and enable risk policies, Microsoft Learn Licensing: Risk-based policies require Microsoft Entra ID Protection, a Microsoft Entra ID P2 feature.
Require multifactor authentication when sign-in risk is Medium or High
What the review checks: Whether a policy set to On, for All users and All resources, requires a multifactor authentication strength at Medium and High sign-in risk, with sign-in frequency set to Every time. MFA registration is checked, because unregistered users are blocked when remediation is required.
“Require Microsoft Entra multifactor authentication when sign-in risk level is Medium or High.”
Configure and enable risk policies, Microsoft Learn Licensing: Risk-based policies require Microsoft Entra ID Protection, a Microsoft Entra ID P2 feature.
Run each policy in report-only mode for at least one week before enforcing it
What the review checks: Each policy’s state and, for recently enforced policies, whether report-only results were reviewed first in the sign-in logs, policy impact view, or Insights and Reporting workbook. Policies in the User Actions scope are noted, because report-only can’t evaluate them.
“Enable each policy in report-only mode for at least one week before enforcement.”
Plan a Conditional Access deployment, Microsoft Learn Licensing: The Insights and Reporting workbook requires Microsoft Entra ID P1 and a Log Analytics workspace receiving sign-in logs.
What the review covers
Policies are reviewed together rather than one at a time, because every policy that applies to a sign-in must be satisfied, so what a user faces depends on the whole set. Coverage depends on your licensing and the agreed scope.
Part of the audit's identity and access area.
- Policy inventory against Microsoft’s baseline
- Every policy and its state (On, Report-only, or Off), including policies created by Microsoft, compared with Microsoft’s Secure foundation templates. Classic policies still in the tenant are noted, because Microsoft says they stopped enforcing controls after July 10, 2024.
- Multifactor coverage and authentication strength
- Which users, roles, and resources must complete multifactor authentication, which authentication strength applies to administrators, and where trusted locations or other conditions remove the requirement.
- Exclusions and coverage gaps
- Every user, group, role, and resource exclusion, who sits in each exclusion group, and which applications the Coverage tab shows without Conditional Access coverage.
- Legacy authentication
- Whether legacy protocols are blocked, which accounts may still use them and, where the agreed access includes sign-in logs, how much legacy sign-in activity remains.
- Emergency access accounts
- How the accounts are set up and protected, whether every policy that blocks or restricts sign-in excludes them, and whether there is evidence of recent validation.
- Guest access
- How guests are treated across your policies, including whether a guest-specific policy covers guests excluded from the all-users multifactor policy.
- Risk-based policies, where licensed
- User risk and sign-in risk policies, kept separate as Microsoft advises, and whether any legacy risk policies configured in Microsoft Entra ID Protection, which Microsoft’s documentation lists for retirement on October 1, 2026, have Conditional Access equivalents.
- Report-only testing and policy protection
- Whether report-only results were reviewed before enforcement and, where the agreed access allows, how What If results for representative users compare with the intended design. Protected actions are checked too, since they can require additional verification before anyone creates, modifies, or deletes a policy.
When teams ask for it
- Moving off security defaults
- Confirm that the Conditional Access policies replacing security defaults give at least the same protection, and that emergency access accounts are excluded where they should be.
- A policy set that has grown over time
- Exceptions for individual users, test policies left in Report-only, and template defaults can build up until it is unclear what the policies enforce together.
- Inheriting a tenant
- After a merger, an acquisition, or a change of IT provider, establish what the existing policies enforce and who is excluded from them.
- Before tightening sign-in requirements
- Before requiring phishing-resistant methods for administrators or blocking legacy authentication, understand who would be affected and which exclusions need to stay.
- Microsoft-managed policies in the tenant
- Microsoft creates some policies in Report-only and turns them on if they’re left that way. Understand what they will enforce, and whether emergency access accounts are excluded, before that happens.
What you receive
Each finding is reported with the configuration evidence behind it, its business context, and a recommended action. Findings are sequenced into a remediation roadmap, so your team knows what to change first.
Questions
What does a Conditional Access policy review cover?
It covers how your Conditional Access policies are designed and enforced: multifactor coverage and authentication strength, legacy authentication, exclusions and coverage gaps, emergency access accounts, guest access and, where licensed, risk-based policies.
The policies are compared with Microsoft’s published guidance and reviewed as a set. The review belongs to the identity and access area of the Microsoft 365 tenant audit, and what your engagement includes is agreed during scoping.
Do we need Microsoft Entra ID P1 for Conditional Access?
Microsoft states that using Conditional Access requires Microsoft Entra ID P1 licenses, and that customers with Microsoft 365 Business Premium licenses can also use Conditional Access features. Risk-based policies need Microsoft Entra ID Protection, a Microsoft Entra ID P2 feature, and products that work with Conditional Access, such as Microsoft Intune, require appropriate licensing of their own.
Security defaults give tenants without Microsoft Entra ID P1 or P2 a basic level of security, and Microsoft says they’re probably not right for organizations that have those licenses. The two aren’t meant to be combined, because creating Conditional Access policies prevents you from enabling security defaults.
No particular license is needed to request the review. Licensing determines which controls exist in your tenant, so Conditional Access policies are reviewed where your licensing includes them, and findings state where a recommendation depends on a license you may not have.
Should emergency access accounts be excluded from every Conditional Access policy?
Microsoft’s emergency access guidance says to exclude them from every policy that blocks or restricts sign-in, and notes that report-only policies don’t block access, so they don’t need the exclusion. Microsoft’s Conditional Access deployment planning guidance puts it more broadly: verify that emergency access accounts are excluded from all policies.
Excluded accounts still need strong protection. Microsoft recommends a passkey (FIDO2), or certificate-based authentication where a public key infrastructure (PKI) is already in place, and says these methods satisfy the mandatory multifactor authentication requirements. It also says to test regularly that the accounts can sign in under your current policies.
The review checks each enforced policy for these exclusions, including policies created by Microsoft.
What access does the review need, and will it change our policies?
It depends on the agreed scope and assessment method. The roles involved, who grants them, and how long access lasts are agreed before the engagement starts. Access follows least privilege and is time-bound, and read-oriented roles are preferred wherever the method allows.
The review examines and reports on your policies. It doesn’t change them without your agreement, and whether the engagement includes any remediation, and who carries it out, is agreed during scoping before work begins.
How much does a Conditional Access policy review cost?
Pricing follows scoping. The review is part of the Microsoft 365 tenant audit: scope comes first, and timing and pricing follow from it, depending on the size and complexity of your tenant, the control areas included, and the deliverables you need.
All three are confirmed in writing before the engagement starts.
How is this different from Secure Score or the built-in Conditional Access tools?
The review complements them. It adds an independent assessment of the whole policy set, with business context, evidence for each finding, and a sequenced remediation roadmap.
Microsoft Secure Score measures your security posture against Microsoft’s recommended actions, and Microsoft notes that it isn’t an absolute measurement of how likely your system or data could be breached. What If simulates sign-ins to show which policies apply, and policy impact, a preview feature, shows how policies affect interactive sign-ins. Where the agreed access allows, the review uses that evidence too, and Secure Score remains a useful way to track progress.
Get a clear view of your tenant’s configuration.
Tell us about your environment and the questions you need answered. We’ll help define an appropriate assessment scope.
Discuss your audit