Make MFA mandatory on Microsoft 365 without lockouts

MFA blocks more than 99% of password attacks, according to Microsoft's analysis. It is by far the highest effort-to-protection measure for an SMB. Yet many organizations still hesitate to enforce it, fearing they will lock out users, disrupt service accounts, or worse, lock themselves out of the tenant. That caution is legitimate: it's not the rule that's risky, it's how you enable it.

The good news: a proven method lets you roll out MFA fleet-wide with no unwanted lockouts. It rests on three pillars — report-only mode to observe before enforcing, a break-glass account to keep an escape hatch, and blocking legacy authentication so MFA can't be bypassed. Let's walk through it step by step, with a concrete example and the mistakes to avoid.

Why MFA alone isn't enough

Enabling MFA without blocking legacy authentication leaves a door wide open. Old protocols — POP, IMAP, basic SMTP, legacy mail clients — don't support MFA and allow sign-in with just a username and password. An attacker who stole a password will use that channel, never once meeting a second-factor prompt. Blocking legacy authentication is therefore inseparable from MFA: the two measures form a single whole, and enforcing one without the other gives a false sense of security.

Concretely, you deploy two complementary Conditional Access rules: one requires MFA for all users on cloud apps, the other blocks legacy authentication clients. Without the second, the first can be bypassed; without the first, the second protects nothing. It is this combination that actually closes the door.

The right rollout sequence

1. 1Create the 'MFA for everyone' Conditional Access rule in report-only (audit) mode.
2. 2Select and exclude a break-glass (emergency access) account from the rule.
3. 3Create, in parallel, a rule blocking legacy authentication, also in report-only.
4. 4Watch simulated sign-ins for a few days in the sign-in logs.
5. 5Identify and handle false positives: service accounts, specific applications.
6. 6Switch both rules to enforced once the needed exclusions are in place.

The break-glass account, an essential safety net

Never enable a Conditional Access rule without first excluding an emergency-access account.

The break-glass account is a dedicated admin account, reserved for emergencies, excluded from the rule, to keep access if MFA fails — an identity-provider outage, a lost MFA device, a misconfiguration. Microsoft recommends keeping at least one, with a long password stored offline, and monitoring its sign-ins. AuPoint requires selecting one before enabling any rule and excludes it automatically from every deployment, making the omission impossible.

A concrete example: moving sixty users to MFA

A sixty-person company wants to roll out MFA fleet-wide. The administrator creates both rules in report-only and excludes an emergency account. For a week, they watch the sign-in logs: most users would have completed MFA without trouble, but three cases stand out — a service account syncing an accounting application, a multifunction printer sending email over SMTP, and an old phone configured with IMAP.

They handle each case: the service account moves to modern authentication, the printer switches to an authenticated SMTP connector, and the old phone is reconfigured. Once these three false positives are resolved, they switch both rules to enforced on a Monday morning, after warning the team the week before and sharing a short guide on registering the authenticator app. On the day, no one is locked out and support receives only a handful of questions. Because the risky cases were caught during the report-only phase rather than in production, MFA is rolled out fleet-wide with no incident at all — the exact opposite of the chaotic activation the team had feared.

Not all MFA methods are equal

Making MFA mandatory is good; choosing strong methods is better. Not all methods offer the same resistance to modern attacks, particularly real-time phishing that intercepts one-time codes.

• SMS and voice call work but remain the weakest methods, vulnerable to SIM-swap hijacking.
• Push notification via Microsoft Authenticator is a good compromise, especially with number matching enabled against MFA fatigue.
• FIDO2 security keys and passkeys are phishing-resistant: they are the recommended methods for privileged accounts.
• Windows Hello for Business offers strong, passwordless authentication backed by the device hardware.

A sound strategy is to require MFA for everyone, then reserve phishing-resistant methods for administrators and sensitive access. You enable number matching in Authenticator to counter fraudulent approval prompts, and gradually discourage SMS. This hardening happens after the rollout, once the MFA baseline is in place and stabilized.

The mistakes that cause lockouts

• Enabling straight in enforced mode, with no report-only phase: false positives become real lockouts.
• Forgetting to exclude the break-glass account: risk of total lockout, including the administrator.
• Overlooking service accounts and non-interactive apps, which can't perform MFA.
• Enabling MFA without blocking legacy authentication: the protection stays bypassable.
• Not warning users: a wave of support calls on activation day.

How AuPoint makes the rollout safe

AuPoint offers MFA and legacy-authentication blocking as ready-made controls, described in plain English. Before applying, the impact preview shows how many users will be affected and which ones. The 'exclude me' option and the break-glass account are injected automatically into the exclusions, making lockout impossible. Every rule can be deployed in report-only first, then switched to enforced in one click — and reversed just as easily if you have any doubt.

On the compliance side, MFA satisfies a central requirement of ISO 27001, NIS2 and GDPR. The control is mapped to these frameworks and included in your exportable compliance report, letting you prove strong authentication during an audit or a client questionnaire, without reconstructing the history by hand. The same report also flags whether legacy authentication is still open anywhere, so the two rules stay aligned over time.

FAQ

How long should I observe in report-only?

A few days is usually enough to cover a full activity cycle, including weekly sign-ins or occasionally used accounts. The goal is to catch every false positive before switching to enforced, not to leave the rule dormant in audit indefinitely.

What about service accounts?

Non-interactive accounts can't perform MFA. You must identify them, exclude them from the rule and secure them another way (managed identities, location restrictions, modern authentication). Report-only mode surfaces them precisely, before any lockout.

Can MFA be bypassed?

Yes, if legacy authentication stays enabled. That's why you must always pair MFA with blocking old protocols. The two rules go together and should be switched to enforced at the same time.

Connect your tenant to AuPoint, select your break-glass account and deploy MFA in report-only with one click. Observe, adjust, then move to enforcement with peace of mind — knowing that a break-glass account always keeps a door open. Start free today.