Key takeaways

  • Conditional Access needs Microsoft Entra ID P1 or higher. Tenants without it can use security defaults, but Microsoft notes that creating Conditional Access policies prevents you from enabling security defaults.
  • Report-only mode evaluates a policy at every sign-in and logs what would have happened, without enforcing it. Run every new policy there first and read the sign-in logs before you switch it on.
  • Microsoft recommends blocking legacy authentication, which cannot do multifactor authentication. Its analysis found that more than 97 percent of credential stuffing attacks and more than 99 percent of password spray attacks use legacy protocols.
  • Administrators should be held to a stricter standard than staff. Microsoft publishes a policy that requires phishing-resistant multifactor authentication for a list of administrator roles, and authentication strengths let you say exactly which methods count.
  • Keep at least two emergency access accounts, cloud-only and excluded from policies that block or restrict sign-in. Test them every quarter. A policy mistake without them can lock everyone out of the tenant.
  • A device compliance policy only works after an Intune compliance policy exists and at least one device is compliant. Build that first, then require it.

Why a baseline, and why in this order

Passwords alone no longer hold up. Attackers buy stolen passwords, try them against thousands of accounts and wait for one that has no second factor. Conditional Access is the set of if-then rules in Microsoft Entra that sits in front of every sign-in. If a user is in a certain group, using a certain app, on a certain kind of device, then allow, require a stronger sign-in, or block.

The risk is in the rollout, not the idea. A block rule written wrongly can stop every employee, including the administrators who would fix it. So the order matters: look first, then enforce, and keep a way back in.

Before you start: licenses and security defaults

Microsoft Learn states that Conditional Access needs a Microsoft Entra ID P1, P2 or trial license. Including sign-in risk from Entra ID Protection needs P2. Tenants without those licenses are not left bare: security defaults give a basic level of protection, including a multifactor authentication prompt and blocking of legacy authentication. Microsoft's planning guidance says the two are not meant to be combined, and that creating Conditional Access policies prevents you from turning security defaults on. In practice, you replace security defaults with your own policies, so make sure those policies cover what the defaults did.

Admins who build policies need the Conditional Access Administrator role, or Security Reader for read-only access. Use Privileged Identity Management to activate such roles just in time where you can, as the planning guide suggests. Create a test user who is not an administrator, and a test group, so you can see a policy work before it touches real people.

Step 1: use report-only mode for every new policy

Report-only is a policy state that lets you test most Conditional Access policies before enabling them. During sign-in the system evaluates the policy but does not enforce it, and the result is logged on the Conditional Access and Report-only tabs of the sign-in log details. The results are Success, Failure, User action required and Not applied. A Failure in report-only mode means that, had the policy been on, the sign-in would have been blocked or the control would not have been met. That is exactly what you want to find out before it happens to a person.

Two cautions from Microsoft Learn. Items in the User Actions scope cannot be tested this way. And a report-only policy that requires a compliant device can make people on macOS, iOS and Android pick a device certificate during sign-in even though nothing is enforced. Exclude those platforms from report-only device-compliance policies to avoid confusing prompts. If you pay for Azure Monitor, the Conditional Access insights workbook shows the impact in one place.

A reasonable rhythm for a small tenant is a week or two in report-only per policy, a look at the Failure rows for real users, fixes or exclusions, then On.

Step 2: block legacy authentication

Legacy authentication means older protocols, such as basic authentication over IMAP, POP and SMTP, and older Exchange ActiveSync clients, that cannot prompt for a second factor. Microsoft recommends blocking them. Its analysis found that more than 97 percent of credential stuffing attacks and more than 99 percent of password spray attacks use legacy authentication, and that those attacks would stop with it blocked.

Microsoft's template policy is simple. Include all users. Target all resources. Under Conditions, set Client apps to Yes and tick only Exchange ActiveSync clients and Other clients. Grant control: Block access. Save it in report-only mode, watch the logs for anything still using old protocols, such as a scanner that emails scans or a line-of-business app, move those to modern authentication, and then turn the policy On.

Step 3: require multifactor authentication for everyone

Microsoft's guidance for an all-users policy uses authentication strengths. An authentication strength is a Conditional Access control that lists which combinations of sign-in methods are acceptable. There are three built-in ones: Multifactor authentication strength, Passwordless MFA strength and Phishing-resistant MFA strength. Microsoft recommends the first, the least restrictive, for the all-users policy, which keeps the rollout practical while still moving beyond a password. You can also build a custom strength.

Many small offices start here and tighten later, for example by steering staff toward passkeys and the Authenticator app instead of text messages. Do not exclude apps from this policy to make a problem go away; find out why the app fails.

Step 4: hold administrators to a higher standard

Administrator accounts are the prize. Microsoft publishes a policy that requires phishing-resistant multifactor authentication for administrator roles and recommends it for at least these: Global Administrator, Application Administrator, Authentication Administrator, Billing Administrator, Cloud Application Administrator, Conditional Access Administrator, Exchange Administrator, Helpdesk Administrator, Password Administrator, Privileged Authentication Administrator, Privileged Role Administrator, Security Administrator, SharePoint Administrator and User Administrator. Phishing-resistant methods are passkeys on a security key, Windows Hello for Business and certificate-based authentication.

The caution on that page matters: make sure every administrator has registered a suitable method first. A Temporary Access Pass can help them register one. Turning the policy on before that risks locking yourself out of your own tenant.

Step 5: protect emergency access accounts

Microsoft Learn recommends at least two emergency access, or break-glass, accounts. They should be cloud-only accounts on the onmicrosoft.com domain, not tied to one person, not federated, and using a passwordless method such as a passkey (FIDO2) or certificate-based authentication that differs from your normal administrators' method. The Global Administrator role should be permanently active, not eligible, and the credentials kept in a secure place available to more than one trusted person.

For Conditional Access, Microsoft's advice is to put these accounts in a dedicated security group, exclude that group from policies that block or restrict sign-in, and test every quarter that they can still sign in. The reason is plain: if the account is subject to a policy that needs a compliant device and the device is the thing that failed, nobody can recover the tenant. Report-only policies do not block, so they need no exclusion. Monitor sign-ins and audit logs for any use of these accounts, because they should almost never be used.

Service accounts and service principals are a separate case. Microsoft notes that policies scoped to users do not block calls made by service principals, and recommends managed identities in place of shared service accounts where you can.

Step 6: add device compliance when you are ready

Device compliance connects Conditional Access to Microsoft Intune: a device must meet your compliance policy, for example disk encryption, a screen lock and a supported operating system, before it can reach company data. Microsoft's article warns that without a compliance policy created in Intune the Conditional Access policy will not work as intended, so create that policy first and confirm at least one device is compliant before enforcement.

If you are not ready to require compliance for everyone, Microsoft suggests a staged path: require a compliant or hybrid-joined device for administrators, then require a compliant device or multifactor authentication for all users, and add a rule that blocks unknown or unsupported device platforms.

Keep it small, named and owned

  • Use a naming standard so anyone can read the list: who it applies to, what it does, and the mode.
  • Keep a short note of why each policy exists and who owns it.
  • Review the policy list and the report-only results every quarter, and after any new app or location change.
  • Export the policy definitions regularly, so a deleted or edited policy can be compared with a known good state.

We build and review Conditional Access baselines for small and mid-size tenants as part of Microsoft 365 hardening work, run in report-only mode first and handed over with the emergency-access test written down.

Sources

This article is general information, not legal or technical advice for your environment. Product menus, license names and provider rules change; check the vendor's current documentation before you act. Last reviewed .

Next article

Related reading

Need help with this?

We find out whether everything you run is safe from attackers, then we fix it.

Cybersecurity