Zero to Conditional Access: Your First Five Policies and Why Order Matters

Audience: IT Pros

Platform: Microsoft 365

Series: MFA & Conditional Access

Part: 2 of 7

In Part 1 of this series, we looked at how AiTM phishing defeats MFA by stealing session cookies — and I mentioned that a single Conditional Access policy could have stopped the attack that cost a UK legal firm £87,000 in under five minutes.

The most common message I got after that post was some version of:

"OK. But where do I actually start?"

This post is the answer to that question.

I'm going to walk you through the first five Conditional Access policies you should deploy in any Microsoft 365 SMB environment — in the right order, with the right safeguards, and with enough context that you understand why each one matters before you touch anything.

This is written for the Level 1 IT tech who's been handed M365 admin access and told to "tighten things up." No assumed security background. Real configurations. Honest caveats about what can go wrong.

Let's get into it.

Before You Touch Anything: The Break Glass Account

I'm going to say this once, clearly, and then repeat it throughout this post because it matters that much.

Before you create a single Conditional Access policy, you need a Break Glass account.

A Break Glass account is a cloud-only, emergency admin account that is explicitly excluded from all Conditional Access policies. It exists for one reason: to give you a way back into your tenant if a misconfigured policy locks everyone out — including you.

This isn't a theoretical concern. Locking yourself out of a Microsoft 365 tenant with a badly configured CA policy is a rite of passage in this industry. It happens to experienced admins. It will happen to you if you skip this step.

Here's how to set one up properly:

Creating your Break Glass account:

Entra ID Admin Center
→ Users → New User → Create User

Display name:    BreakGlass-Admin (or similar — make it obvious)
Username:        breakglass@yourdomain.onmicrosoft.com
                 (use the .onmicrosoft.com domain, NOT your custom domain)
Password:        Generate a strong random password (20+ characters)
                 Store it in a sealed physical envelope, locked away
                 Also store in your password manager with restricted access

Assign it the right role:

Entra ID → Roles and Administrators
→ Global Administrator → Add Assignment → [your Break Glass account]

Exclude it from everything:

Every single Conditional Access policy you create should have this account in the exclusions list. No exceptions.

Monitor it religiously:

The Break Glass account should never be used in normal operations. Set an alert for any sign-in from this account — that's either you responding to a genuine lockout, or an attacker who has somehow compromised it.

Microsoft Sentinel / Defender → Analytics Rules → New rule
Alert on: SigninLogs where UserPrincipalName == "breakglass@yourdomain.onmicrosoft.com"

If you don't have Sentinel, set a Logic App or use the Entra ID audit log alerts instead. The point is: if that account ever signs in, you need to know immediately.

Understanding Report-Only Mode

Before we get to the policies themselves, there's one more concept you need to understand: Report-Only mode.

Every Conditional Access policy can be set to one of three states:

• Off — Policy is disabled, does nothing

• Report-only — Policy evaluates against all sign-ins and logs what it would have done, but doesn't actually enforce anything

• On — Policy is live and enforcing

Report-only mode is your safety net. For every policy in this guide, I'm going to recommend you run it in report-only first — ideally for at least a week in a live environment — and review the results before turning it on.

You can review report-only results in:

Entra ID → Monitoring → Sign-in logs
→ Filter: "Conditional Access" column → "Report-only: Failure"

Any entry showing as "Report-only: Failure" is a sign-in that would have been blocked or challenged if the policy were live. Review these before enabling. You'll often find service accounts, shared mailboxes, or legacy applications you didn't know existed that would break on day one.

That's exactly the point. Find out in report-only, not in production.

The Five Policies — In Order

Here's the sequence. Order matters because some policies are foundational and others build on top of them. Enabling them out of sequence can create gaps or — worse — lock out the very accounts you need to manage the others.

Policy 1: Block Legacy Authentication

Enable this one first. Always. No exceptions.

Legacy authentication refers to older protocols that don't support modern MFA challenges: SMTP AUTH, POP3, IMAP4, Exchange ActiveSync (basic auth), and older Office client authentication. These protocols are baked into older email clients, some line-of-business applications, and — critically — they completely bypass MFA.

If you have MFA enforced but legacy authentication is allowed, an attacker with stolen credentials can use a legacy protocol to sign in and MFA will never be triggered. All your MFA work is irrelevant for any sign-in using these protocols.

⚠️ Common misconception: "But we disabled Basic Auth in Exchange Online." Disabling Basic Auth in Exchange Online is not the same as blocking legacy authentication at the Entra ID / Conditional Access level. Do both.

Configuration

Entra ID Admin Center → Protection → Conditional Access → New Policy

Name:        CA001 - Block Legacy Authentication

Assignments:
  Users:     All Users
             Exclusions: [Your Break Glass account]
  Resources: All cloud apps
  Conditions:
    Client apps: ☑ Exchange ActiveSync clients
                 ☑ Other clients
    (Leave Browser and Mobile apps/desktop clients UNCHECKED)

Access Controls → Grant:
  ● Block access

Enable policy: Report-only first

💡 Before you enable: Run in report-only for one week. Check the Sign-in logs for any "Other clients" sign-ins. Common culprits are:

• Old printers or scanners sending email via SMTP AUTH

• Line-of-business applications using basic auth

• Older versions of Outlook (pre-2016)

For printers/scanners: configure them to use a service account with SMTP AUTH explicitly enabled (you can allow legacy auth per-account while blocking it globally). For LOB apps: this is the impetus to get them updated or replaced.

Why first? Because blocking legacy auth is the fastest win with the broadest impact. Until this is on, everything else you do has a hole in it.

Policy 2: Require MFA for All Users

With legacy auth blocked, you can now enforce MFA for all modern authentication sign-ins. This is the foundational policy that everything else builds on.

A word on the right way to do this, because there are a few approaches and they're not all equal:

• Security Defaults — Microsoft's one-click MFA enforcement. Fine as a starting point, but it's a blunt instrument with no customisation. It also conflicts with Conditional Access policies — you must disable Security Defaults before creating CA policies. If you're here reading this guide, you should be using CA, not Security Defaults.

• Per-User MFA — The old way. Avoid it. It doesn't integrate with Conditional Access properly, creates management headaches, and doesn't give you the policy granularity you need.

• Conditional Access — Require MFA for all users — The right way. This is what we're building.

Configuration

Entra ID Admin Center → Protection → Conditional Access → New Policy

Name:        CA002 - Require MFA - All Users

Assignments:
  Users:     All Users
             Exclusions: [Your Break Glass account]
  Resources: All cloud apps
  Conditions: None

Access Controls → Grant:
  ● Grant access
    ☑ Require multifactor authentication

Session:
  Sign-in frequency: Every time
    (For high-security environments. For normal users, you can
     leave this at default — we'll refine it in a later policy)

Enable policy: Report-only first

💡 Check before enabling: In report-only, look for any service accounts or shared accounts that don't have MFA registered. These will break when the policy goes live. Use this opportunity to do a sweep: Entra ID → Users → Filter by "MFA registration status."

Also check: do all your users have the Microsoft Authenticator app set up? If not, now is the time to run an MFA registration campaign before this policy goes live.

The order matters here: Policy 1 (blocking legacy auth) should be live before this one. If you enable MFA enforcement while legacy auth is still allowed, users on legacy clients will start getting blocked — but not because of your MFA policy. The error messages will be confusing and you'll spend hours troubleshooting the wrong thing.

Policy 3: Block High-Risk Sign-Ins (Entra ID Protection)

With the basics in place, we can start using intelligence. Entra ID Protection — included in Microsoft 365 Business Premium and Entra ID P2 — evaluates every sign-in using Microsoft's threat intelligence and assigns a risk score: Low, Medium, or High.

High-risk sign-ins are those that Microsoft's systems have flagged as almost certainly malicious. This includes:

• Sign-ins from known attacker IP addresses

• Sign-ins accompanied by credential stuffing patterns

• Sign-ins immediately after the same account was seen on a credential dump

• Impossible travel (signed in from London, then Lagos, 10 minutes apart)

• Token replay — which is exactly what happens when an attacker uses a stolen session cookie

🎯 Remember our AiTM adversary from the first blog in this series?: This is how Entra ID Protection helps catch AiTM attacks. When an attacker replays a stolen cookie from a different IP or device, the anomaly often triggers a high-risk sign-in flag — which this policy will automatically block.

Configuration

Entra ID Admin Center → Protection → Conditional Access → New Policy

Name:        CA003 - Block High Risk Sign-ins

Assignments:
  Users:     All Users
             Exclusions: [Your Break Glass account]
  Resources: All cloud apps
  Conditions:
    Sign-in risk: ☑ High

Access Controls → Grant:
  ● Block access

Enable policy: Report-only first

A note on licensing: This policy requires Entra ID P2 or Microsoft 365 Business Premium for the sign-in risk condition. If you're on a lower tier, you won't see the "Sign-in risk" option. This is one of the strongest arguments for Business Premium — the risk-based CA capability alone is worth the licensing delta for most SMBs.

Optional — Medium risk, require MFA:

You can also create a companion policy that challenges Medium risk sign-ins with MFA rather than blocking them outright. This is more user-friendly and still provides meaningful protection:

Name:        CA003b - Require MFA for Medium Risk Sign-ins

Conditions:
  Sign-in risk: ☑ Medium

Grant:
  ● Grant access
    ☑ Require multifactor authentication

⚠️ Review before enabling: In report-only, any High risk sign-ins you see are worth investigating immediately — even though the policy isn't live yet. These are real flagged events, not simulations.

Policy 4: Require Compliant Device for Microsoft 365

This is the policy I referred to in the AiTM post as the one that stops cookie theft cold.

When a device compliance requirement is in place, Microsoft 365 checks that the device making the request is:

1. Enrolled in Intune — Microsoft's device management platform

2. Compliant with your compliance policy — which you define (encryption enabled, AV running, OS up to date, etc.)

An attacker who has stolen a session cookie and is replaying it from their own machine will fail this check. Their machine isn't enrolled in your Intune. The cookie replay is blocked. Access denied.

This policy requires Intune to be set up and devices to be enrolled before it can do anything useful. If you haven't done that yet, this is the one to pause on — but it's also the one to prioritise getting there.

Prerequisites

Before enabling this policy:

1. Set up an Intune compliance policy — Intune Admin Center → Devices → Compliance Policies → Create Policy. At minimum, require: BitLocker encryption, Windows Defender active, OS minimum version.

2. Enrol your devices — Either via Autopilot, manual enrolment, or Group Policy (hybrid join). All devices that users sign in from must be enrolled before this policy goes live.

3. Check enrolment status — Intune Admin Center → Devices → All Devices. Every device your users work from should appear here and show as "Compliant" before you enable the policy.

Configuration

Entra ID Admin Center → Protection → Conditional Access → New Policy

Name:        CA004 - Require Compliant Device - M365

Assignments:
  Users:     All Users
             Exclusions: [Your Break Glass account]
  Resources: Office 365
             (Scope to O365 specifically, not "All cloud apps" —
              some apps may not support device compliance checks)
  Conditions: None

Access Controls → Grant:
  ● Grant access
    ☑ Require device to be marked as compliant

Enable policy: Report-only first — run for at LEAST two weeks

⚠️ This one needs extra care in report-only. The failure logs will show you every device that isn't enrolled. Before you enable, every device in your environment that users need to work from must be enrolled and compliant. Personal devices (BYOD) that users work from are a particular challenge — you'll need to decide whether to enforce Intune enrolment on personal devices (requires App Protection Policies as an alternative), or whether to accept that BYOD remains a gap.

For most SMBs: enforce compliant device on company-owned devices, use App Protection Policies for BYOD. That's a separate guide — but don't enable this policy on "All Devices" until you've thought through your BYOD position.

Policy 5: Restrict Azure Portal and Admin Tools to Admins Only

The final foundational policy is one that prevents a compromised standard user account from accessing the Azure portal, Entra ID admin center, or Microsoft Intune admin center.

Standard users have no legitimate reason to access these portals. If a regular employee's account is compromised and an attacker starts poking around the admin portals, that's a major escalation risk. This policy shuts that door.

Configuration

Entra ID Admin Center → Protection → Conditional Access → New Policy

Name:        CA005 - Restrict Admin Portals to Admins

Assignments:
  Users:     All Users
             Exclusions: [Your Break Glass account]
                         [All admin accounts / admin role members]
  Resources: Microsoft Admin Portals
             (This is a specific option in the resource selector —
              covers Azure portal, Entra ID admin center,
              Microsoft 365 admin center, Intune admin center)
  Conditions: None

Access Controls → Grant:
  ● Block access

Enable policy: Report-only first

💡 Exclusions matter here. Make sure every account that legitimately needs admin portal access is in the exclusions — either individually or via a group. The Break Glass account must also be excluded. After enabling, test by signing in as a standard user and attempting to access portal.azure.com — you should get an access blocked message.

Putting It All Together: The Deployment Sequence

Here's the order to go from report-only to live, with recommended time in report-only before enabling:

The compliant device policy goes last because it has the most prerequisites and the highest potential to impact users if deployed before devices are enrolled. Everything else can layer on while you're working through Intune enrolment.

Naming Conventions: The Thing Nobody Talks About

Before I let you go, a word on naming. It sounds boring. It will save you significant pain at 11pm when something breaks and you're trying to figure out which policy is doing what.

Use a consistent naming convention from day one:

CA[number] - [Action] - [Target/Scope]

Examples:
CA001 - Block - Legacy Authentication
CA002 - Require MFA - All Users
CA003 - Block - High Risk Sign-ins
CA003b - Require MFA - Medium Risk Sign-ins
CA004 - Require Compliant Device - M365
CA005 - Block - Admin Portals Non-Admins

The number prefix means your policies sort in deployment order in the portal. The action prefix (Block / Require / Allow) tells you at a glance what a policy does before you open it. The scope tells you what it applies to.

Future you will thank present you.

What You've Built

After deploying these five policies, your Microsoft 365 environment now:

• Blocks all legacy authentication — closing the MFA bypass hole

• Requires MFA for all modern sign-ins — the foundational layer

• Automatically blocks high-risk and anomalous sign-ins — using Microsoft's threat intelligence

• Stops cookie replay attacks — by requiring device compliance (once Intune is rolled out)

• Limits the blast radius of a compromised standard account — by locking them out of admin portals

That's not a complete security programme. There's more to do — Named Locations, token lifetime controls, app-specific policies, and the more advanced Entra ID Protection configurations we'll cover later in this series. But it's a genuine, meaningful baseline that puts you significantly ahead of most SMB environments.

The attacks that are successfully compromising UK businesses right now are not sophisticated. They're exploiting the absence of exactly these controls.

Get these in place. Then we'll build on them.

Quick Reference Checklist

• [ ] Break Glass account created, password stored securely offline

• [ ] Break Glass account assigned Global Administrator role

• [ ] Security Defaults disabled (required before CA policies work)

• [ ] CA001 — Block Legacy Authentication — report-only, then live

• [ ] CA002 — Require MFA All Users — report-only, then live (after CA001)

• [ ] CA003 — Block High Risk Sign-ins — report-only, then live

• [ ] CA005 — Restrict Admin Portals — report-only, then live

• [ ] Intune set up and devices being enrolled (prerequisite for CA004)

• [ ] CA004 — Require Compliant Device — report-only for 2+ weeks, then live

• [ ] Break Glass account excluded from ALL policies above

• [ ] Sign-in alerts configured for Break Glass account

• [ ] Naming convention documented and followed

Up Next in the Series

Part 3: MFA Fatigue Attacks — How Attackers Weaponise Your Authenticator App Against You

We've built the defensive layer. In Part 3, we zoom back out to the threat side — specifically the technique that has successfully breached Uber, Caesars, and countless SMBs: MFA push fatigue. How it works, why people fall for it, and the free settings that make it dramatically harder to pull off.

CyberSync UK — Practical cybersecurity for UK businesses and the people who defend them. Questions about your M365 setup? Get in touch at cybersync.uk

Tags: ConditionalAccess EntraID Microsoft365 MFA ITsecurity UKcyber Intune EntraIDProtection cybersecurity ITpro

Series Link: MFA & Conditional Access