Conditional access: policies that decide who gets in

Multi-factor authentication answers one question: can this person prove it is them? Conditional access asks a bigger one: given who is signing in, to what, from where, on which device and with what risk, what should we require? It is a rule engine that sits in front of your applications, and its value for a small organisation is mostly in a handful of well-chosen rules, not in elaborate ones.

Check licensing before planning. Conditional Access is part of Microsoft Entra ID’s paid tiers, and some business bundles include the level you need. The free baseline, security defaults, applies a fixed set of protections and cannot be combined with Conditional Access policies: enabling your own policies means turning security defaults off. Confirm your licences and current tenant mode before you start.

How a policy is built

Every policy has the same shape, and thinking in its parts makes policies easier to reason about and to debug.

Part	Question it answers	Examples
Assignments: users	Who does this apply to?	All users, a group, administrator roles; with exclusions
Assignments: target resources	What are they accessing?	All cloud apps, one application, a user action such as registering security information
Conditions	In what circumstances?	Location, device platform, client app type, sign-in risk (with the right licence)
Grant controls	What must be true to allow access?	Require MFA, require a compliant or managed device, require a particular authentication strength, or block
Session controls	What limits apply once in?	Sign-in frequency, whether the session persists, restrictions inside an application

Policies combine. Access is allowed only if every applicable policy’s requirements are satisfied, and a block from any policy wins. That makes broad block policies powerful and dangerous in equal measure.

Report-only mode is the safest tool you have

Every policy can be set to report-only. In that state it is evaluated against real sign-ins and the result is logged, but it does not enforce anything. The sign-in logs and the What If tool show what would have happened. This is how you discover that the finance system signs in with an old protocol, or that your scanner uses an account without MFA, before you break either.

The workflow for every new policy:

1. Create it in report-only mode.
2. Leave it for long enough to cover your normal cycles, including monthly and quarterly processes.
3. Read the results: who would have been blocked or challenged, and why.
4. Fix or exclude the legitimate cases, with an owner and an end date for each exclusion.
5. Switch to enforced. Keep reading the logs afterwards.

A small set of policies that covers most of the risk

For a small tenant, these are enough to start with, and each can be enabled in turn.

Policy	Targets	Requires	Why
Administrators must use strong MFA	Administrator roles	MFA, ideally a phishing-resistant strength	A takeover of an admin is a takeover of the tenant
Everyone must use MFA	All users, excluding emergency accounts	MFA	Stops most password-only takeovers
Block legacy authentication	All users	Block, for legacy client apps	Closes the MFA bypass
Protect security-info registration	All users, user action: register security information	MFA or a trusted location	Stops an attacker enrolling their own device on a stolen password
Require a managed device for sensitive apps	Specific sensitive applications	Compliant or managed device	A stolen session on an unknown machine is refused
Block high-risk sign-ins	All users	Block or force a password change, where your licence supports risk detection	Acts on suspicious sign-ins automatically

The fourth one is easy to overlook. Without it, an attacker who has a password but no MFA can still register their own MFA method the first time the account has none, and from then on they own the second factor.

Emergency access accounts

Any rule engine can be misconfigured into locking out everyone, including the people who could fix it. Prevent that with two emergency access (break-glass) accounts:

• Cloud-only accounts, not tied to any individual, with long unique credentials stored offline in two separate secure places.
• Excluded from the policies that could lock you out, which means they are protected another way: an alert on every sign-in, and very limited use.
• Tested periodically, so you know they work and that the alert fires.

An exclusion is a hole. The two emergency accounts are the one hole you deliberately keep, so keep it small and watched.

Stronger methods: authentication strength

Not all second factors are equal. Text messages and voice calls can be intercepted or socially engineered. App codes and simple approvals can be relayed by a proxy-style phishing page or approved by a tired user. Phishing-resistant methods, such as FIDO2 security keys, passkeys and certificate-based authentication, are bound to the genuine site and do not hand a usable credential to a fake one.

Conditional Access can require a specific authentication strength, not just “MFA”. A realistic plan for a small organisation:

1. Administrators and finance move to phishing-resistant methods first.
2. Everyone else uses the authenticator app with number matching, with SMS retired as a method wherever possible.
3. Over time, extend phishing-resistant sign-in to more roles as devices and training allow.

Plan for loss. A security key in a drawer is no use to someone locked out; decide in advance how a person without their key proves who they are and who is allowed to authorise a replacement.

Location, devices and the limits of “blocking countries”

A named-location policy can block sign-ins from places you never operate in, and requiring a managed device can keep stolen sessions out of unknown machines. Both are useful and both have limits. Attackers route traffic through addresses close to the victim, and staff travel and use phones on mobile networks. Use location as one signal among several, not as the only defence. Blocking a country is a speed bump; requiring a managed device and a strong method is a wall.

Tokens and session theft

Strong sign-in reduces the chance of a stolen password being useful. It does not eliminate theft of the session after sign-in. A phishing page that relays the sign-in captures the session token as well as the password, and the attacker then holds a valid session. Mitigations include:

• Requiring phishing-resistant methods, so there is no relayable credential.
• Requiring a compliant or managed device, so a token replayed from another machine is refused.
• Shorter sign-in frequency on sensitive applications.
• Revoking sessions at the first sign of compromise, which is part of the response in business email compromise.

What conditional access does not cover

It is worth being clear about the edges, because a tidy set of policies can create false confidence.

• It governs sign-in, not behaviour. A legitimate user who has passed every check can still be tricked into approving a malicious application or paying a fraudulent invoice.
• It does not see what is already stored. A forwarding rule or a consented application that exists before you enable the policy keeps working. Review them as described in mailbox security.
• It is not aimed at non-human identities by default. Service accounts and automated processes cannot answer an MFA prompt. They need their own treatment: modern authentication with a certificate or a managed identity where the application supports it, restricted by location and scope, and an owner who can say why each one exists.
• It does not replace DNS controls. Anyone can still send mail that claims to be from your domain unless you enforce DMARC.

A four-week introduction

Week	Do	Check
1	Create emergency accounts; confirm administrators all have MFA; create the three core policies in report-only	Sign-in logs: who would be blocked or challenged?
2	Fix findings; enforce the administrator policy	Administrators can still sign in from every device they use
3	Enforce the all-users MFA and legacy-blocking policies in stages by group	Help desk volume; scanners and service accounts
4	Add the security-info registration policy; review exclusions and their owners	Every exclusion has a reason and an end date

How this fails

• A broad block with a mistake in it. “All users, all apps, block” with the wrong exclusion locks you out. Use report-only and test with the What If tool before enforcement.
• No emergency account, or one nobody tested. The policy that locks you out also locks out the recovery path.
• Exclusions that never expire. A temporary exception for a scanner becomes permanent and becomes the attacker’s route.
• Service accounts forgotten. They cannot do MFA. They need a different mechanism or an alternative control, not a permanent exemption.
• Registration left open. An attacker with a stolen password registers their own second factor.
• Treating policy as a substitute for the rest. It does not stop impersonation, consented-app abuse or a clerk paying a fraudulent invoice.

What to do next

Create the two emergency accounts and the first report-only policies this week. Use the email security readiness assessment to see how your sign-in controls compare with the rest of your answers, and read Microsoft 365 security for the wider hardening order that these policies sit within.