The engine is default allow
Microsoft Entra conditional access has one property that decides whether a tenant is defensible, and most deployments ignore it: the policy engine is default allow. A sign-in that matches no policy is not challenged and not flagged. It is admitted with whatever single factor the account holder typed. Nearly every conditional access failure we see traces back to this. The tenant does not lack policies; it lacks coverage. Policies accrete one incident at a time, each scoped to the app or the group that caused the last problem, and the seams between them are exactly where an attacker signs in.
So the design goal is not 'require MFA for Office 365'. The goal is a closed set: every path a sign-in can take should terminate in a policy you wrote on purpose. That reframing changes how you scope policies, how you handle exceptions, and what you monitor. The rest of this note works through the pieces that decide whether the set actually closes: architecture, the break glass account, legacy authentication, device compliance, and the specific gaps that keep turning up in otherwise well-run tenants.
Design the set, not the policies
A defensible policy set is small and broad, not large and narrow. Start from a handful of global policies scoped to all users and all resources: phishing-resistant MFA for administrators, MFA for everyone else, block legacy authentication, require a compliant device for corporate data, constrain or block guests. Then carve exceptions out of those policies explicitly rather than building bespoke policies per application. Ten broad policies with documented exclusions can be audited in an afternoon. Sixty narrow ones targeting enumerated apps cannot, and every new app the business adopts is born uncovered.
Treat exclusions as debt with an owner and an expiry. Every excluded user, group and named location needs a one-line justification somewhere reviewable, and a periodic check that removes the ones nobody can defend. Exclusion groups grow in one direction only, because adding someone unblocks a ticket and removing someone risks a phone call. Without a forced review, the exception list quietly becomes the real policy.
Ship changes through report-only mode. Entra evaluates report-only policies against live sign-ins and records what would have happened, which turns a risky enforcement change into a data question: run it for a week, query the sign-in logs, find the service account or the boardroom tablet that would have broken, fix that first, then enforce. The What If tool is useful for spot checks, but report-only against real traffic is what tells the truth.
The break glass account you will need at 2am
Broad policies raise the stakes of a bad change. It is entirely possible to lock every administrator out of the tenant, including the person who needs to fix the policy that did it. The answer is an emergency access account, and its design matters more than its existence. Cloud-only, on the onmicrosoft.com domain, so a federation outage or a broken on-premises sync cannot take it down with everything else. Not tied to a person. Excluded from every conditional access policy, which is precisely why it cannot be a plain password in a drawer.
Current Microsoft guidance is to give emergency access accounts phishing-resistant credentials rather than exempting them from MFA altogether. A FIDO2 security key stored offline in a safe does this cleanly, and a second account with a second key covers the case where the first credential fails. Then wire an alert to a monitored channel that fires on any sign-in by these accounts, because a break glass sign-in is either a declared emergency or an incident in progress; there is no third option. Test the whole path on a schedule. An emergency credential nobody has exercised is a rumour, not a control.
Legacy authentication is the bypass lane
Legacy authentication protocols (IMAP, POP, older ActiveSync, SMTP AUTH) predate modern token flows and cannot carry an MFA challenge. Any account reachable over them is protected by exactly one password no matter how strict the rest of the policy set is, which is why password spray tooling aims at these endpoints first. Exchange Online has switched basic authentication off protocol by protocol, but SMTP AUTH is the long tail: it gets re-enabled per mailbox for the photocopier, the scanner and the line-of-business app that emails invoices, and those mailboxes hold real credentials that get sprayed like any other.
The fix is a conditional access policy that blocks legacy authentication clients for all users with no exclusions, alongside disabling SMTP AUTH at the organisation level and treating each per-mailbox re-enablement as an exception with an owner. Before enforcing, filter the sign-in logs by client app to see what still speaks the old protocols; most devices move to an authenticated connector without drama. While you are in that part of the console, use the authentication flows condition to block device code flow for everyone who has no conceivable use for it. Device code phishing works precisely because the flow is designed to move a sign-in from one device to another, and almost nobody in a typical tenant needs it.
Device compliance is only as honest as the policy behind it
Requiring a compliant device is the strongest grant most organisations can deploy. It binds access to hardware you manage and sharply raises the cost of stolen-credential and stolen-token attacks. It is also the grant most likely to be quietly hollow. Intune has a tenant-wide setting that decides how to treat devices with no compliance policy assigned, and the default marks them compliant. If compliance policies are assigned to a curated group that misses half the fleet, that half passes the conditional access check having proven nothing at all.
Flip that default to not compliant, assign compliance policies to all devices, and make the policy itself say something: minimum OS version, disk encryption on, endpoint protection healthy, not jailbroken. Then decide the unmanaged device story deliberately. Blocking unmanaged devices outright is clean where the business allows it; where it does not, constrain browser sessions with app enforced restrictions and a short sign-in frequency instead of pretending the risk is not there. A stolen token replayed from an attacker's machine is the modern stolen password, and device-bound access is the control that answers it.
Where tenants leak, and how to prove yours does not
The failures worth hunting are rarely exotic. The same short list turns up tenant after tenant:
Proving the set holds is mechanical. Pull the sign-in logs and hunt for successful sign-ins that matched zero conditional access policies; each one is a seam. Run What If against an admin account from an untrusted device and confirm the answer is the one you designed. Protect the security info registration action with its own policy so enrolment requires a Temporary Access Pass or a trusted context, never an open door. And export the policy set through Microsoft Graph into version control, so a policy change is a diff somebody reviews rather than a portal edit nobody notices.
Conditional access rewards a few days of deliberate design and punishes years of accretion. If the policy list has grown past the point where anyone can say what a given sign-in will hit, rebuild it as a small closed set with documented exceptions. That rebuild is the core of the Azure security reviews Black Shard runs, and it is the same exercise whether a firm does it or you do: enumerate the paths, close the seams, alarm the break glass. The engine is default allow. The job is to make sure nothing interesting is ever left to the default.
- A trusted named location covering the office IP that skips MFA, on a connection shared with guest wifi or an entire serviced building
- Exclusion groups nobody has reviewed since the policy shipped, still holding accounts for people long gone
- Service accounts excluded from everything because MFA once broke a script, instead of being moved to managed identities or scoped workload identity policies
- Security info registration left open, so whoever signs in first with a sprayed password enrols their own MFA method and owns the account
- Guest accounts outside every policy because each policy targets members only
- Policies parked in report-only mode for a year, producing telemetry and no protection