← All field notes

The Entra ID Conditional Access baseline every small company should have (and the one rule that locks everyone out)

Six policies that stop the attacks small businesses actually get hit with, in the order I deploy them — plus the break-glass account that keeps a bad policy from becoming a very long evening.

Most small companies on Microsoft 365 have MFA switched on and believe they're done. They aren't, and the gap is bigger than it looks — legacy authentication protocols will happily bypass the MFA you just enabled.

Here's the baseline I deploy, in order, and the mistake that will lock you out of your own tenant.

Before anything: the break-glass account

Do this first. Not after. Before.

Create two cloud-only Global Administrator accounts that are excluded from every Conditional Access policy you will ever write. Long random passwords, stored in a physical safe or a separate password manager. No MFA on at least one of them (yes, deliberately — that's the point).

Every experienced admin has locked themselves out of a tenant with a Conditional Access policy exactly once. The break-glass account is why it's a twenty-minute annoyance instead of a support ticket with Microsoft and a very long evening.

Monitor sign-ins on these accounts with an alert. If one is ever used and it wasn't you, that's an incident.

The six policies, in deployment order

1. Block legacy authentication.

This is the highest-value single policy and it's usually the first thing missed. Legacy protocols — POP, IMAP, SMTP AUTH, older Office clients — don't support modern authentication and therefore don't honor MFA. An attacker with a valid password walks straight past your MFA using an IMAP client.

Deploy in report-only mode first. Look at what breaks. It's usually a multifunction printer scanning to email and one ancient line-of-business app.

2. Require MFA for all users.

Standard, but with a specific note: use number matching, not simple approve/deny push. MFA fatigue attacks — spamming push notifications until someone taps approve to make it stop — work depressingly well against the old prompt.

3. Require MFA for administrators, with no exceptions.

A separate, stricter policy for privileged roles. No trusted-location exclusions. Admin accounts are the target.

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

If you have Intune, this is the step that turns a stolen credential into a dead end. An attacker with the password and the MFA code still needs an enrolled device.

5. Block or restrict access from countries you don't operate in.

Blunt, and it works. If your entire company is in Florida, a sign-in from another continent isn't a false positive. Use it as a signal, not the only wall — VPNs exist.

6. Sign-in frequency and persistent browser session controls for privileged access.

Shorter session lifetime for admins. Longer for regular users, or you'll train everyone to hate you and start looking for workarounds.

The rollout sequence that avoids an outage

  1. Report-only mode for every new policy. Always. It logs what would have happened without enforcing.
  2. Let it run a full business week. You need month-end, the person who works Sundays, and the contractor who logs in from a different network.
  3. Read the Conditional Access Insights workbook. It shows exactly who would have been blocked.
  4. Enable for a pilot group — IT plus two tolerant volunteers.
  5. Expand to all users, break-glass accounts still excluded.

Where AI is actually useful here

Not in generating the policies — the baseline is well established and you should use published guidance, not a model's recollection of it.

Where it helps is reading the output. Conditional Access sign-in logs are dense JSON, and asking a model to summarize which policies fired for which users across a week of report-only data turns an afternoon of squinting into a few minutes. Same for drafting the "here's what's changing and why" email that determines whether your rollout goes smoothly.

The rule I follow: AI for reading and explaining, human for deciding and enabling. Never let a model toggle enforcement.

What this actually buys you

Blocking legacy auth plus enforcing MFA with number matching eliminates the overwhelming majority of what actually hits small businesses: credential stuffing, password spray, and the MFA-fatigue follow-up. It's not exotic. It's just usually not done.


The takeaway: create the break-glass account, block legacy authentication, then deploy everything else in report-only first. In that order.

Want this built instead of read?

I build the internal apps, automations and integrations described in these notes — one client at a time, fixed price, documented so you own it.