Conditional Access baseline
05 Aug 2026
The Conditional Access policies every tenant should have
Five policies cover the access decisions almost every tenant needs: MFA for admins, blocked legacy authentication, MFA for everyone else, MFA for Azure management, and a trusted location for security-info registration. Most tenants I look at have two of them, both created years ago by someone who has since left. This is the order to deploy them in, and the condition that tells you each one is safe to enforce.
One prerequisite before anything else: Conditional Access requires Microsoft Entra ID P1. Microsoft 365 Business Premium includes it. Risk-based policies need P2. If the tenant is on the free tier, the honest answer is security defaults, not this list.
97%
Credential stuffing via legacy auth
99%
Password spray via legacy auth
2
Break-glass accounts, minimum
90d
Break-glass validation interval
Those first two numbers are Microsoft's own analysis: more than 97 percent of credential stuffing attacks and more than 99 percent of password spray attacks use legacy authentication protocols. They are the reason policy two is not optional.
Step zero: the account that gets you back in
Do not create a single policy until the emergency access accounts exist. Microsoft's guidance is two or more emergency access accounts, cloud-only on the *.onmicrosoft.com domain, not federated, not synchronised, and not associated with any individual person. Give them a phishing-resistant method that differs from what your normal admin accounts use — if your admins use the Authenticator app, the break-glass accounts get FIDO2 keys.
Put them in a dedicated security group — Microsoft suggests naming it something like EmergencyAccess — and exclude that group from every policy that blocks or restricts sign-in. One useful detail: report-only policies do not block access and do not need the exclusion. The exclusion is what stops a policy misconfiguration from locking every administrator out of the tenant simultaneously.
The done-condition
A break-glass account is not finished when it is created. It is finished when someone has signed in with it, performed an administrative task, and written down where the credential lives. Microsoft says to repeat that drill at least every 90 days.
If security defaults are currently enabled, you also have a switch-over to plan. Security defaults and Conditional Access are mutually exclusive: organisations implementing policies that replace them must disable security defaults first. Do not disable them on a Friday and enable policies on Monday — that is a weekend with no MFA requirement at all.
The five policies, in deployment order
Smallest population, highest value, and the group most likely to already be registered. Scope it to the privileged directory roles rather than a hand-maintained group — a group goes stale the first time someone is granted a role directly. Done when the report-only results show every admin sign-in already satisfying MFA, so enforcing it changes nothing except the guarantee.
All users, all resources, client apps condition set to Exchange ActiveSync clients and Other clients only, grant control set to block. This is the policy that makes policy 1 and 3 real — legacy protocols do not support MFA, so an attacker who reaches them bypasses the requirement entirely. Done when you can name every remaining legacy sign-in and have replaced or excluded it. Our piece on who is still using POP3, IMAP and SMTP covers how to build that list.
The big one, and the reason the first two go first: by now the admins are proven and the protocol bypass is closed. Exclude service accounts explicitly and replace them with managed identities where you can — Conditional Access policies scoped to users do not block calls made by service principals anyway. Done when MFA registration coverage is high enough that enforcement is a formality rather than a helpdesk event; registration gaps are what turn this policy into a bad afternoon.
Azure Resource Manager changes subscription billing and tenant-wide service settings, and it is reached from the Azure portal, the Entra admin center, Azure PowerShell and the Azure CLI alike. This policy applies to everyone touching those APIs, administrator or not. Done when your automation runners have been moved off interactive user credentials, because this is the policy that finds them.
The one most tenants skip. Without it, an attacker holding a first-factor password can register their own authentication method and satisfy your MFA policy legitimately. Constraining registration to trusted locations closes the door that policies 1, 3 and 4 all depend on. Done when onboarding has a documented path for remote starters, because otherwise this policy quietly becomes the reason a new hire cannot begin.
Every policy ships in report-only first
A Conditional Access policy has three states, visible in the Graph conditionalAccessPolicy resource as disabled, enabledForReportingButNotEnforced and enabled. That middle value is report-only mode, and it is the whole safety mechanism: policies are evaluated during sign-in but not enforced, with results logged to the Conditional Access and Report-only tabs of the sign-in log detail.
Diagram · the state each policy moves through before it enforces anything
Read the results honestly. Report-only: Failure means the conditions matched and a control was not satisfied — that is a sign-in the policy would have blocked. Report-only: User action required means the user would have been prompted; in report-only they are not. Report-only: Not applied means the conditions did not match, which is as often a scoping mistake as a deliberate exclusion.
Two limits worth knowing before you trust the mode. Policies using the User Actions scope cannot be evaluated in report-only, which is exactly the scope policy 5 uses. And report-only policies that require a compliant device can still prompt users on macOS, iOS and Android to select a device certificate — exclude those platforms from report-only device-compliance policies unless you enjoy tickets about a certificate dialog that repeats.
What each policy breaks, and what that costs you
| Policy | What usually breaks | Where you see it first |
|---|---|---|
| MFA for admins | Shared admin accounts nobody owns | Report-only failures on one UPN |
| Block legacy auth | Scanners, MFPs, old line-of-business apps | Non-interactive sign-in log |
| MFA for all users | Unregistered users, shared-device staff | Registration coverage report |
| MFA for Azure management | Scripts running as a person | Pipeline failures, not user reports |
| Trusted location for registration | Remote onboarding, travelling staff | Helpdesk, on day one of a new hire |
The baseline is not a project, it is a diff
The five policies are the easy part. What decays is everything around them: an exclusion added for one contractor in March and never removed, a policy quietly switched back to report-only during an incident, a licence lapse. That last one is worth reading twice — when the licences required for Conditional Access expire, policies are not automatically disabled or deleted. You can view and delete them, but not update them. Enforcement continues while your ability to change it does not.
So the operational question is not "do we have Conditional Access?" but "what is different from last quarter?" That means periodically reading policy state, assignments and exclusions across every tenant you manage, and treating a change nobody remembers making as an incident. GraphPaaS collects that governance surface per tenant on a schedule, so a policy that moved from enabled back to report-only shows up in a report rather than in a breach summary.
Sources
- Conditional Access overview — P1 licence requirement, commonly applied policies, and what happens to policies when licences expire.
- Block legacy authentication — the 97% and 99% attack figures, the client apps condition, and service-account exclusions.
- Manage emergency access accounts — two cloud-only accounts, the exclusion rule, and the 90-day validation drill.
- Conditional Access policy insights — report-only evaluation results, the User Actions limit, and the device-certificate prompt warning.
- conditionalAccessPolicy resource type — the three state values and the conditions, grantControls and sessionControls properties.
- Security defaults — what the free tier covers, and why security defaults must be disabled before policies replace them.
GraphPaaS
See which Conditional Access policies exist in every tenant you manage — and which ones quietly changed.
Review tenant metrics →