A Conditional Access Baseline That Won't Lock You Out

Conditional Access is where identity security actually gets enforced in Microsoft 365. It decides, per sign-in, whether to allow, block, or require something more based on who is signing in, from where, on what, to what.

Most organisations with the licensing for it run a fraction of what it offers, usually because the first attempt locked somebody out and the appetite never returned.

This is a baseline that is safe to deploy, in an order that makes lockout very unlikely.

Before anything else: break-glass accounts

Create two emergency access accounts before writing a single policy.

• Cloud-only, in your tenant's default domain — not federated, not synced from on-premises
• Permanently assigned Global Administrator
• Very long random passwords, split and stored in separate physical safes or sealed envelopes
• Excluded from every Conditional Access policy, without exception
• Monitored: alert on any sign-in, to a destination multiple people see
• Tested quarterly, with the test recorded

Two accounts, because one can be lost, disabled or caught by a change nobody anticipated. These exist so that a misconfigured policy is an inconvenience rather than an incident requiring Microsoft support to restore access.

Everything that follows assumes they exist.

Deploy in report-only first

Every policy supports report-only mode: it evaluates and logs what it would have done without enforcing. Use it for every policy, every time, for at least a week.

Then read the sign-in logs filtered to that policy. You are looking for the service account nobody documented, the legacy client, the scanner that authenticates as a user, the contractor on an unmanaged device. Those are the things that break on enforcement day, and report-only shows you all of them in advance.

The baseline policies, in deployment order

1. Block legacy authentication

The highest-value single policy. Legacy protocols — POP, IMAP, SMTP AUTH, older Office clients — cannot do modern authentication and therefore cannot do MFA. They are the standard route for password-spray attacks against accounts that are otherwise protected.

Report-only first, because something will be using it: a multifunction printer scanning to email, a line-of-business application, an old mail client. Find them, fix them, then enforce.

2. Require MFA for administrators

Every privileged role, every sign-in, no exclusions except break-glass. This is the smallest-blast- radius high-value policy you can deploy, because the population is small and technically capable.

3. Require MFA for all users

The main event. Deploy in rings — IT first, then a pilot department, then the rest. Register users in advance with a registration campaign so the first enforcement is not also their first encounter with MFA.

Prefer phishing-resistant methods where you can: passkeys, Windows Hello for Business, FIDO2 keys. Number matching on push notifications is a meaningful improvement over simple approve/deny and should be on regardless.

4. Require compliant or hybrid-joined devices for sensitive access

Once device management is in place, require a managed, compliant device for access to the things that matter most. This is what stops valid credentials on an unmanaged machine from being enough.

Start with administrative access and your most sensitive applications rather than everything at once.

5. Block or restrict unexpected locations

If you do not operate in a country, there is little reason to permit interactive sign-in from it. Named locations plus a block policy removes a large volume of background attack traffic.

Be careful with travel, and note that this is a noise-reduction control, not a security boundary — location is trivially disguised. Treat it as hygiene, not protection.

6. Session controls for unmanaged devices

Rather than blocking unmanaged access outright, constrain it: browser-only, no download, shorter session lifetime. This is often the difference between a workable BYOD policy and one people route around.

7. Require MFA to register security information

Closes a real gap. Without it, an attacker with a stolen password can sometimes register their own MFA method and establish persistence. Combined with a trusted-location or compliant-device requirement for registration, it closes the loop.

The exclusions that quietly undo everything

Every exclusion is a hole. Review them quarterly and ask whether each is still needed:

• Service accounts are the most common. Prefer workload identities with certificate authentication over excluding a user account from MFA.
• "Temporary" exclusions for a project that ended two years ago.
• Whole groups excluded where one person needed it.
• Nested group membership that grants an exclusion nobody intended.

An exclusion with no expiry date and no owner is a policy you do not have.

Verify, do not assume

• Use the What If tool to test a policy against a specific user, app and condition before enabling.
• After enforcement, filter sign-in logs by policy and confirm it applies where expected.
• Test the break-glass accounts quarterly, and confirm the sign-in alert fires.
• Re-run the review whenever you add an application, because new apps do not automatically inherit what you assume.

The honest summary

Conditional Access is the single highest-leverage security configuration available to a Microsoft 365 organisation, and the baseline above addresses the attack paths that account for most account compromise: legacy protocols, unprotected administrators, passwords without a second factor, and valid credentials on untrusted devices.

None of it is difficult. The reason it goes undeployed is fear of lockout — which is exactly what the break-glass accounts and report-only mode are for. Create those first, and the rest is a series of small, reversible changes.