Conditional Access: policies a small business should actually deploy

What Conditional Access is for

Security Defaults are binary: MFA for everyone, all the time, no exceptions and no configuration. That is a good starting point and a bad ending point, because real businesses need nuance — a service account that cannot present a factor, a policy that is stricter for administrators than for warehouse staff, a requirement that finance data is only reachable from a managed laptop.

Conditional Access provides that nuance. Each policy is a set of conditions (users, applications, locations, device state, sign-in risk) and a set of controls (block, require MFA, require a compliant device, limit the session). Policies are additive and all matching policies apply, which means a single overly broad block policy overrides every allow condition you have written elsewhere.

Create the break-glass account first. Before anything else.

The characteristic Conditional Access disaster is self-inflicted: an administrator writes a policy requiring a compliant device, applies it to all users, and discovers that no device in the tenant is enrolled — including their own. Every administrator is now locked out of the portal that would let them fix the policy.

Prevent it with a break-glass account: a cloud-only Global Administrator, excluded from every Conditional Access policy, with a long random password stored physically offline, and no MFA dependency on a device that could be unavailable. Microsoft recommends two such accounts. Configure an alert on any sign-in to them, because in normal operation they should never be used.

This is not optional and it is not paranoia. It is the single precaution that separates a bad afternoon from a support case with Microsoft.

The five policies to deploy, in order

Start with blocking legacy authentication. Older protocols cannot present a second factor, so any tenant permitting them has an MFA bypass. This is the highest-value policy and usually the least disruptive, provided you have first identified any scanner, copier or application still using SMTP AUTH.

Then require MFA for all users. If you were previously on Security Defaults, this replaces that behaviour with something you control. Exclude only the break-glass accounts.

Third, require MFA for administrative roles under all conditions, with no trusted-location exemption. Administrative sessions are the ones worth attacking, and 'we are in the office' is not a security control now that offices are on the same internet as everyone else.

Fourth, block sign-ins from countries you never operate in. This is crude, easily bypassed by a determined attacker using a VPN, and still removes a large volume of opportunistic noise. Apply it as an allow-list of countries you do business in rather than a block-list of countries you do not.

Fifth, require a compliant or hybrid-joined device for access to sensitive applications. This is the policy that defeats stolen session cookies replayed from an attacker's machine, and it is the strongest of the five — but only deploy it once Intune enrolment is genuinely complete, because it is also the one most likely to lock people out.

• Block legacy authentication (highest value, lowest disruption)
• Require MFA for all users, excluding break-glass accounts only
• Require MFA for administrative roles with no location exemptions
• Restrict sign-in to countries you actually operate in
• Require a compliant device for sensitive applications, once Intune enrolment is complete

Use report-only mode, every time

Every Conditional Access policy can be created in report-only mode, where Microsoft evaluates it against real sign-ins and records what would have happened without enforcing anything. Run every new policy this way for at least a week and read the results in the sign-in logs.

This catches the things you will not predict: the director who works from a country you did not list, the mail-enabled application nobody documented, the contractor on an unmanaged device who genuinely needs access. Fixing those in report-only mode costs you nothing. Fixing them after enforcement costs you a morning of people unable to work.

Keep the policy set small

Conditional Access complexity compounds badly. Twelve overlapping policies written over two years by different people, with exclusion groups nobody can explain, is a configuration where nobody can predict the outcome of a given sign-in — which is functionally the same as having no policy.

Small businesses should aim for five to eight named policies with a clear naming convention that states the target and the control. Review the exclusions quarterly: exclusion groups accumulate members during troubleshooting and are almost never cleaned up, and an exclusion group with fifteen people in it is where your security posture quietly went.