Microsoft now forces MFA on the admin portals, and it will happily deploy a few Microsoft-managed Conditional Access policies into your tenant on its own. That is a floor, not a ceiling. If you want sign-in security that matches how your organisation actually works, you still have to design your own Conditional Access policies for Microsoft 365 — and the order you build them in matters as much as the policies themselves. This post covers the baseline set I deploy, the break-glass account that keeps you from locking yourself out, and how to roll it all out without taking down sign-in for the whole company.

Key Takeaways

• Build break-glass (emergency access) accounts and exclude them from every policy before you create a single Conditional Access rule — this is the step that prevents a tenant-wide lockout.
• A solid baseline of Conditional Access policies for Microsoft 365 is: require MFA for all users, require phishing-resistant MFA for admins, and block legacy authentication.
• Every new policy should start in report-only mode so you can see who it would have affected before it actually enforces anything.
• Microsoft's mandatory MFA enforcement and Microsoft-managed policies are a useful floor, but they do not replace a deliberate, tested policy set tuned to your environment.
• Conditional Access requires Entra ID P1; risk-based conditions such as sign-in risk and user risk require Entra ID P2.

Environment

• Microsoft 365 tenant with Entra ID P1 for Conditional Access (P2 where risk-based policies are mentioned).
• Security defaults disabled — Conditional Access and security defaults are mutually exclusive.
• At least two cloud-only break-glass accounts with the Global Administrator role.
• An authentication method rollout already in progress (Microsoft Authenticator, and FIDO2 / passkeys for admins).

The Problem

Conditional Access is the closest thing Entra ID has to a firewall for sign-ins. Each policy is an if-then statement: if these users access these apps under these conditions, then require MFA, require a compliant device, or block. The model is powerful, which is exactly why it is easy to get wrong. A single policy scoped to "all users" and "all apps" with a condition you did not fully think through can lock every account — including yours — out of the tenant. There is no undo button when the account that would fix the policy is the account the policy just blocked.

Microsoft has tried to raise the baseline for everyone. Since October 2024 it has been progressively enforcing mandatory MFA on the Azure portal, Entra admin center, and Intune admin center, expanding to the Microsoft 365 admin center in February 2025 and to command-line and scripted CRUD operations from October 2025. It also deploys Microsoft-managed Conditional Access policies in report-only state to eligible tenants. Both are genuinely helpful. Neither covers blocking legacy authentication for your line-of-business apps, requiring stronger auth for your privileged roles, or excluding the service account that breaks if you force MFA on it. That tuning is still your job.

The Solution

Step 1 — Create break-glass accounts and exclude them from everything

Before any policy, create two emergency access accounts. They are cloud-only (no on-premises dependency), use the onmicrosoft.com domain, hold the Global Administrator role permanently, and have very long random passwords stored offline — split between two safes or password vaults so no single person holds a full credential. Microsoft's emergency access account guidance is the reference here, and it is worth following to the letter.

The critical part for Conditional Access: exclude these accounts from every policy you create. The cleanest way is to put them in a dedicated group and exclude that group by default in each policy. If a misconfigured rule ever locks out the tenant, the break-glass account is the way back in. Then set up alerting so you know the instant one is actually used — a break-glass sign-in should always be an incident.

Step 2 — Build every policy in report-only mode first

Report-only mode evaluates a policy against real sign-ins and records what would have happened, without enforcing it. Every policy below should start here. Leave it running for a week or two, then review the sign-in logs under the report-only tab to find the accounts and apps that would have been blocked — the service account using legacy auth, the meeting-room device that cannot do MFA, the contractor on an unmanaged laptop. Fix the exclusions, then flip to "On".

The What If tool complements this: it lets you simulate a specific user signing in to a specific app under specific conditions and shows which policies apply. I use it to sanity-check a policy before enabling it, and again whenever someone reports an unexpected block.

Step 3 — Require MFA for all users

This is the workhorse policy. Scope it to all users (excluding the break-glass group), all cloud apps, and grant access only when MFA succeeds. Microsoft's mandatory enforcement covers the admin portals, but it does not cover every app your users touch, so an explicit "require MFA for all users" policy closes that gap on your terms.

• Users: All users, excluding the emergency access group.
• Target resources: All cloud apps.
• Grant: Require multifactor authentication.

Watch for service accounts and unattended workloads in the report-only results before enforcing. Those should move to workload identities or certificate-based auth rather than being permanently excluded from MFA.

Step 4 — Require phishing-resistant MFA for administrators

Privileged accounts deserve a stronger bar than a push notification, which adversary-in-the-middle phishing kits can defeat. Scope a second policy to your administrative roles and require an authentication strength of phishing-resistant MFA — FIDO2 security keys, passkeys, or Windows Hello for Business.

• Users: Directory roles — Global Administrator, Security Administrator, and the other privileged roles, excluding the emergency access group.
• Target resources: All cloud apps.
• Grant: Require authentication strength → Phishing-resistant MFA.

Scoping by directory role rather than by a static group means new admins are covered automatically the moment they are assigned the role. That is one fewer manual step to forget.

Step 5 — Block legacy authentication

Legacy authentication protocols — older mail clients, IMAP, POP, SMTP AUTH, and similar — cannot perform MFA, which makes them the path of least resistance for password spray and credential stuffing. Even with Exchange Online basic auth largely retired, legacy auth still shows up against other endpoints, and it bypasses every MFA policy above. Block it explicitly.

• Users: All users, excluding the emergency access group.
• Target resources: All cloud apps.
• Conditions: Client apps → Exchange ActiveSync clients and other clients (the legacy categories).
• Grant: Block access.

Report-only mode is non-negotiable here. There is almost always one forgotten multifunction printer or scripted mailbox still using basic auth, and you want to find it in the logs rather than in a help-desk queue. Pair this policy with monitoring — the same legacy-auth sign-ins are a strong signal in a SIEM, which I cover in SIEM correlation rules for real attacks.

Step 6 — Add device and location conditions where they fit

Once the baseline is stable, layer on context. A "require compliant or hybrid-joined device" policy keeps corporate apps off unmanaged machines. Named locations let you treat your office egress IPs as trusted and apply tighter controls to everything else. If you have Entra ID P2, sign-in risk and user-risk policies let you demand MFA or a password change only when Identity Protection flags the sign-in as risky, which keeps friction off normal logins.

Add these one at a time, each in report-only first. A pile of overlapping Conditional Access policies that nobody understands is its own security problem — keep the set small enough that you can explain every policy in a sentence. Before you tighten device controls, it helps to audit where your accounts and roles actually stand today; the approach in my first security audit script guide is a reasonable starting point for that inventory.

Frequently Asked Questions

Do I need Entra ID P1 for Conditional Access policies?

Yes. Conditional Access requires Entra ID P1, which is included in Microsoft 365 E3 and E5 and Business Premium. Risk-based conditions — sign-in risk and user risk from Identity Protection — require Entra ID P2. Security defaults are the free alternative, but they are all-or-nothing and cannot be tuned the way Conditional Access can.

What is a break-glass account and why exclude it from every policy?

A break-glass, or emergency access, account is a cloud-only Global Administrator account kept aside for the moment a Conditional Access policy, federation outage, or MFA provider failure locks everyone else out. You exclude it from all policies so that whatever breaks your normal sign-ins cannot also block your way back in. Its use should always trigger an alert.

Does Microsoft's mandatory MFA mean I do not need my own policies?

No. Mandatory MFA covers sign-ins to the Azure, Entra, Intune, and Microsoft 365 admin portals and scripted admin operations. It does not block legacy authentication, enforce phishing-resistant methods for admins, or apply MFA to your other applications. Your own Conditional Access policies for Microsoft 365 cover everything the mandatory baseline does not.

What does report-only mode actually do?

Report-only mode evaluates a policy against live sign-ins and logs the result it would have produced, without enforcing it. You review those results in the sign-in logs to catch accounts and apps that would have been blocked, fix the exclusions, and only then switch the policy on. It is the single best protection against a self-inflicted lockout.

Will blocking legacy authentication break Outlook or Teams?

Modern Outlook, Teams, and the Microsoft 365 apps all use modern authentication and are unaffected. Blocking legacy auth only stops older clients and protocols that cannot do MFA. The usual casualties are old line-of-business scripts, multifunction printers scanning to email, and unpatched mail clients — which report-only mode will surface before enforcement.

Conclusion

Should a platform charge for Conditional Access and then also ship its own managed policies on top? You can argue about the licensing. But the managed policies and mandatory MFA are a floor, and a floor built for every tenant cannot account for your service accounts, your legacy printer, or your admins who should be on security keys. That tuning is the part only you can do.

The baseline here — break-glass accounts excluded from everything, MFA for all users, phishing-resistant MFA for admins, legacy auth blocked, every policy tested in report-only first — is not exotic. It is the unglamorous set that stops the attacks that actually happen. Build it in that order, test before you enforce, and keep the policy count low enough to reason about. The result is sign-in security you understand, which is worth more than a clever policy you are afraid to touch.

Related Posts

• From Logs to Threats: SIEM Correlation Rules for Real Attacks — the monitoring side, including the legacy-auth and failed-MFA sign-ins these policies generate.
• PowerShell Quick Guide: Creating Your First Security Audit Script — auditing the accounts and roles you are about to scope policies around.
• Essential Windows Event IDs for Security Monitoring — the on-premises identity events worth watching alongside cloud sign-ins.

Editorial note: posts on this blog are drafted with AI assistance and then reviewed, edited, and tested against a real environment before publishing. Commands, output, and screenshots come from systems I actually ran the work on.