The three ways to switch on MFA across a tenant, compared by licence, flexibility and what each one enforces.
From Ultra Transcenders SC-300 by Tony Rough (coming November 2026)
There are three ways to turn on MFA across a tenant. Choosing between them depends on licensing and how much control you need.
| Security defaults | Per-user MFA | Conditional Access | |
|---|---|---|---|
| Licence | None (any tenant) | Included with Office 365 / Microsoft 365 plans | Microsoft Entra ID P1 (P2 for risk conditions) |
| Customisation | On or off only | Per-user state, few exceptions | Fully customisable |
| Exclude users | No | Yes | Yes |
| FIDO2, Windows Hello for Business, hardware tokens | No | Yes | Yes |
| Location and device conditions, report-only | No | No | Yes |
| New users protected automatically | Yes | No | Yes |
| Where | Entra ID > Overview > Properties > Manage security defaults | Users > Per-user MFA | Conditional Access |
Security defaults are aimed at Free tenants. They’re turned on for new tenants, with a 24-hour grace period before enforcement, and the least-privileged role to change them is Conditional Access Administrator. When enabled they:
Users register Microsoft Authenticator with notifications (or any OATH TOTP app). The Directory Synchronization Accounts role is excluded. To move to Conditional Access, disable security defaults first, then turn on equivalent policies (Microsoft-managed policies exist for this). After enabling security defaults, revoke existing tokens with Revoke-MgUserSignInSession so signed-in users have to register.
Common trap: Creating Conditional Access policies while security defaults are still on - an organisation that replaces security defaults with Conditional Access must disable security defaults. The two aren’t designed to run side by side.
Per-user MFA has three states: Disabled (the default), Enabled (enrolled; legacy authentication still works until registration) and Enforced (MFA required; legacy apps need app passwords). Enabled users move to Enforced automatically when they register. Manage states at Users > All users > Per-user MFA (Authentication Policy Administrator), or through the Graph perUserMfaState property. Microsoft’s guidance is clear: don’t enable or enforce per-user MFA if you use Conditional Access. Users protected by Conditional Access or security defaults correctly show as Disabled.
The service settings page (Multifactor authentication > Additional cloud-based MFA settings) is a legacy portal that still holds:
Report suspicious activity replaced Fraud alert, Block/unblock users and notifications. The legacy features were removed on 1 March 2025. Enable it at Authentication methods > Settings (Authentication Policy Administrator). Its Microsoft managed state is currently disabled, so it must be set to Enabled. A user who reports a prompt is set to high user risk (detection type User Reported Suspicious Activity). With P2, risk-based Conditional Access can then block the user or require remediation. With P1, admins work from the risk detections report and the sign-in and audit logs, or automate through Microsoft Graph.
Microsoft is moving users from telephony to passkeys:
| Date | Change |
|---|---|
| 1 September 2026 | Users enabled for SMS or voice were auto-enabled for passkeys and nudged to register (the registration campaign moved to Microsoft managed). A temporary opt-out (passkeyDynamicMigration) runs until 1 February 2027 |
| 30 October 2026 | Configuration of your own telephony provider (Microsoft Security Store) becomes available |
| 1 February 2027 | Microsoft-provided SMS and voice retired for all users except Global Administrators and external users (internal guests are included). Users whose only MFA method is SMS or voice must register a passkey to continue |
| 1 July 2027 | Retired for Global Administrators and external users |
The retirement covers SSPR too. A telephony provider can keep SMS and voice going for MFA, but not SMS as a primary sign-in method. Custom voice messages for voice calls were retired on 28 February 2026.
This note is one section of Ultra Transcenders SC-300: Microsoft Identity and Access Administrator, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.
Due on Amazon in November 2026, in Kindle and paperback editions.
About the book · SC-300 terms in the glossary · All SC-300 study notes
How the two hybrid sync engines differ in capability and limits, and where each sign-in method checks the password.
What a TAP is for, its lifetime and length settings, and which role can create one for which users.
Which events and location changes revoke a still-valid token, how long-lived CAE tokens behave, and where CAE falls back to one-hour tokens.
The difference between the two risk types, real-time versus offline detections, and which detections need P2.
How default and per-organisation settings control B2B collaboration and B2B direct connect, and when MFA and device claims are trusted.
How the two managed identity types differ in lifecycle and sharing, when to choose each, and the Azure roles needed to manage them.
Why every app has a global definition and a per-tenant instance, the three service principal types, and what happens when you change or delete one.