Microsoft Entra MFA Configuration: Mandatory MFA and Choosing the Right Method (2026)

MFA is no longer a matter of "should we turn it on?" On the Microsoft Entra ID (formerly Azure AD) side, multi-factor authentication has become mandatory: since 2024 for admin portals, and since 2025 for Azure resource management via PowerShell/CLI and REST. There is no opt-out; there was only a grace period, and those windows have closed.

So in this guide we change the question: not "do I enable MFA" but "how do I configure it correctly?" Because in the field the real damage comes not from MFA being off, but from it being half-configured — enforcing it with the wrong tool, relying on weak methods (SMS), setting up the break-glass account wrong. We’ll take these in order.

First, the 2026 reality: where and when is MFA mandatory?

Microsoft’s mandatory-MFA enforcement arrived in two phases:

• Phase 1 (October 2024): MFA required for CRUD operations in the Azure portal, the Microsoft Entra admin center and the Microsoft Intune admin center. The Microsoft 365 admin center came into scope in February 2025.
• Phase 2 (October 1, 2025): MFA required for Create/Update/Delete operations via Azure CLI, Azure PowerShell, the Azure mobile app, IaC tools and the REST API (management.azure.com — the control plane). Read-only operations are out of scope.

Important details to know:

• No opt-out. The postponement windows (Phase 1 → Sep 30, 2025; Phase 2 → Jul 1, 2026) have passed as of today.
• Break-glass / emergency access accounts are also subject to MFA — set them up with a passkey (FIDO2) or certificate-based authentication (CBA).
• Workload identities (managed identity, service principal) are not affected. But if you use a user account as a service account, it hits MFA; move those to a workload identity.
• The sync service account is not affected — your Entra Connect / Cloud Sync sync is unaffected by the MFA mandate.
• The ROPC flow is incompatible with MFA; old username+password token flows break.

The lesson: configure MFA properly before the mandate bites, so a user meets your planned flow one day rather than an error screen.

Three ways to enforce MFA — which one?

1) Security Defaults — free, one switch, "all-or-nothing." Forces MFA registration on all users and blocks legacy authentication. A good baseline for small environments without a Conditional Access (P1/P2) license. No granularity.

2) Conditional Access — recommended — requires Entra ID P1/P2. You define in detail who, from where, to which app, under which condition does MFA. For any org with the license, this is the right way to prepare for mandatory MFA and to define a break-glass exception. We cover the details in Conditional Access scenarios.

3) Legacy per-user MFA — the method of flipping users "enabled/enforced" one by one. Don’t start here for a new setup. It’s hard to manage, conflicts with Conditional Access, and Microsoft is leaving this management experience behind.

Have a license: Conditional Access. If not: Security Defaults. Don’t build per-user MFA as a new baseline.

Which methods you enable: the Authentication methods policy

Enforcing MFA (CA/Security Defaults) and deciding which methods may be used are separate jobs. The right place to manage methods today is the Authentication methods policy: Microsoft Entra admin center → Entra ID → Authentication methods → Policies (role: at least Authentication Policy Administrator).

Critical migration warning: Microsoft deprecated method management in the legacy MFA service settings and SSPR policies. Since September 30, 2025, methods can no longer be managed in those legacy policies. If you still manage them on the old screens, migrate with the "Manage migration" flow in the Authentication methods policy: Pre-migration → Migration in Progress → Migration Complete. Per-user targeting is also gone now; assign methods to groups.

Method choice: enable the strong, don’t trust the weak

In 2026 the direction is clear: phishing-resistant methods.

• Enable / encourage: Microsoft Authenticator (push + number matching — already on by default), passkey (FIDO2), Windows Hello for Business, certificate-based authentication.
• Reduce / drop: SMS and voice call. Weak, and Microsoft is phasing them down. (Timeline to confirm: from September 1, 2026 users with SMS/voice are nudged to passkey automatically; on February 1, 2027 users with only SMS/voice meet a mandatory passkey registration screen.)

Practical advice: for a new setup don’t make SMS a single factor from the start; baseline on Authenticator and plan the move to passkey.

Step-by-step: MFA with Conditional Access (P1/P2)

1. Prepare methods first: in the Authentication methods policy, enable Authenticator and passkey for target groups; complete the migration from the legacy policies.
2. Prepare break-glass accounts: at least two emergency access accounts; give them strong MFA with passkey/FIDO2 or CBA (don’t fully exempt them — the mandate allows no exemption).
3. Admin MFA policy: in Conditional Access, target privileged roles (or all admin portals) and "require multifactor authentication" (preferably authentication strength = phishing-resistant).
4. All-users MFA policy: a separate CA policy requiring MFA for all users on cloud apps; exclude the break-glass accounts.
5. Report/pilot first: start the policy in report-only mode or with a pilot group; see the impact in sign-in logs, then flip it "On."
6. Verify: watch sign-in logs for which app/condition triggers MFA; personally test that break-glass accounts can sign in with the strong method.

No license: instead of these steps, turn on Security Defaults. Not granular, but far better than leaving things unprotected.

Field pitfalls

• Fully exempting the break-glass account from MFA. The mandate allows no exemption; the right way is strong MFA (passkey/CBA).
• Trusting SMS as a single factor. Weak and being phased down. Move to Authenticator/passkey.
• Mixing per-user MFA and Conditional Access unknowingly. Conflicting requirements produce unexpected prompts.
• Still managing methods on the old MFA/SSPR screens. Not managed there after September 30, 2025; complete the migration.
• Service accounts acting like users. If you run automation under a user account it hits MFA; move it to a workload identity.
• Skipping report-only and going straight to "On." See the impact first; enforcing on the wrong scope causes lockouts.

Conclusion

With Entra MFA the job is no longer "enable" but "configure correctly." Separate three decisions: what you enforce MFA with (Conditional Access if you’re licensed, else Security Defaults), which methods you allow (Authentication methods policy — completing the migration from the legacy policies) and which strong method you baseline on (Authenticator + number matching, passkey; move away from SMS). On top, set up break-glass accounts with a strong method and rehearse the policy in report-only first. For the layer that governs who is asked for MFA and under what condition, move on to Conditional Access scenarios.