The Entra ID Passwordless MFA Registration Change, Explained
For years, Microsoft Entra ID has forced new users through a "weakest method first" onboarding path: before you could register a passkey, FIDO2 security key, Windows Hello for Business, macOS Platform SSO, or Microsoft Authenticator passwordless sign-in, you had to first set up a baseline MFA method — typically SMS or voice call. That sequencing made phishable, SIM-swap-vulnerable methods the default entry point into every new identity, even in tenants that wanted passkeys everywhere. The Entra ID passwordless MFA registration change Microsoft is now rolling out removes that requirement.
According to Microsoft 365 message-center tracking (MC1450133, summarized by PUPUWEB and OurCloudNetwork, and picked up in community discussion on r/AZURE and r/entra this week), eligible users will be able to register a synced passkey, a Microsoft Entra passkey on Windows, or a FIDO2 security key as their very first authentication method — no SMS or voice detour required.
ℹ️ Note: This is distinct from the separate Microsoft-provided SMS/voice MFA retirement, which removes an existing weak method. This change is about the registration order for new or under-enrolled users — it makes passwordless the easiest path in, not just an eventual destination.
Per the same tracking sources, the rollout is phased:
- Phase 1 — synced passkeys, Microsoft Entra passkeys on Windows, and FIDO2 security keys — begins rolling out worldwide and in GCC tenants mid-October 2026, with completion expected by mid-November 2026.
- Phase 2 — extending first-factor passwordless registration to Windows Hello for Business, macOS Platform SSO, and Microsoft Authenticator passwordless phone sign-in — follows afterward.
⚠️ Warning: Microsoft's own message-center text for Phase 2 is internally inconsistent — it states a start of "early January 2026" (before Phase 1's October 2026 start) completing "late February 2027." Every tracker we checked (PUPUWEB, OurCloudNetwork, M365 Admin) reproduces this exact wording, so it isn't disagreement between trackers — it reads like a typo in Microsoft's original post (most likely January 2027, not 2026). Treat the Phase 1 window above as the reliable figure, and confirm the exact Phase 2 date in your own Microsoft 365 message center (MC1450133) before communicating internally. Note MC1450134 is a separate, related message — Windows Hello for Business and macOS Platform SSO becoming standalone MFA factors, GA early October-late November 2026 — not a Phase 2 timing source for this change.
Administrators are not losing control: the existing authentication methods policy and Conditional Access continue to gate which methods are actually available and to whom. The change lowers the registration friction, it does not silently enable passkeys for tenants that haven't turned the method on.
How It Works
Passwordless-first registration rides on infrastructure that already exists in Entra ID: the authentication methods policy (which authentication methods are enabled tenant-wide, including FIDO2/passkey with Allow self-service setup) and the registration campaign feature, which nudges signed-in users toward a target method after they complete MFA.
Per Microsoft Learn's registration campaign documentation, the campaign is configured through the registrationEnforcement.authenticationMethodsRegistrationCampaign block of the authentication methods policy (readable/writable via Microsoft Graph at GET/PATCH https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy), with these properties:
| Property | Values | What it controls |
|---|---|---|
state | enabled / disabled / default | Whether the campaign nudges users at all |
includeTargets[].targetedAuthenticationMethod | fido2 / microsoftAuthenticator | Which method users are pushed toward — a campaign can only target one method at a time |
snoozeDurationInDays | 0–14 (default 1) | How long before a skipped nudge reappears |
enforceRegistrationAfterAllowedSnoozes | true / false | Whether registration becomes mandatory after 3 snoozes |
When Microsoft managed state is used, Microsoft is already incrementally shifting the target from Authenticator to fido2 (passkeys) and moving the snooze interval to 1 day — but also disabling the enforced-registration-after-3-snoozes limit, so nudges become more frequent while forced registration is off for tenants that haven't set explicit values — worth knowing before you assume your current campaign target is still what you configured months ago.
Detection: What To Check In Your Tenant
Before Phase 1 lands, confirm what your tenant is actually configured to allow and who is actually registering:
| Check | Where | What you're looking for |
|---|---|---|
| FIDO2 / passkey method state | Entra admin center → Authentication methods → Policies → Passkey (FIDO2) | Is the method Enabled, and is Allow self-service setup on? |
| Registration campaign target | Entra admin center → Authentication methods → Registration campaign, or GET /policies/authenticationmethodspolicy | Is state enabled/Microsoft managed, and what is targetedAuthenticationMethod? |
| Baseline registration coverage | Authentication methods activity report (Entra admin center → Authentication methods → Activity, Registration tab) | What share of users currently have a passwordless method registered vs. phone-only |
| Registration events | Entra ID audit log, filter Activity category "Authentication methods" | Operations User registered security info and User changed default security info — track who is enrolling passkeys, and when |
| Registration gating | Conditional Access policies scoped to the Register security information user action | Confirm registration is restricted to expected networks/devices before you widen the passkey door |
💡 Tip: Run the authentication methods activity report before Phase 1 starts rolling out in your tenant region. It gives you a real baseline to compare against once passwordless-first registration goes live — useful for proving the change actually moved adoption, not just assuming it did.
Remediation: Preparing For The Rollout
- Enable the passkey (FIDO2) method with self-service setup, if you haven't already — this is the prerequisite for users to benefit from passwordless-first registration at all.
- Decide your registration campaign target now. If you want new users landing on passkeys instead of Authenticator push, set
targetedAuthenticationMethodtofido2explicitly rather than relying on Microsoft-managed defaults, which change on Microsoft's timeline, not yours. - Review Conditional Access on "Register security information." If registration should only happen from managed devices or trusted networks, confirm that policy still applies once passwordless becomes the first-touch option, not just a later upgrade — see our Conditional Access gaps guide for common misses.
- Pilot before Phase 1 completes in your region. Passkey nudges are evaluated per device-and-browser combination, not per user — test the experience across your actual device fleet (Windows/Chrome, macOS/Safari, mobile) rather than assuming uniform behavior.
- Re-check MC1450133 directly in your Microsoft 365 admin center message center closer to the rollout window — Microsoft's own Phase 2 timeline text is internally inconsistent, and the message center is the tenant-specific source of truth for your rollout wave.
- Don't stop at registration order. Passwordless-first registration only closes part of the gap — see why MFA alone is not enough for the Conditional Access and Security Defaults controls that still need to be in place.
How EtcSec Detects This
EtcSec flags tenants where passwordless methods aren't available or enforced through the MFA_NO_PASSWORDLESS and MFA_NO_FIDO2 checks (passkey/FIDO2 not enabled or not configured for self-service), MFA_NO_STRONG_METHOD (no phishing-resistant method configured at all), MFA_PHONE_ONLY (users limited to phone-based MFA, the exact pattern this Microsoft change is designed to move away from), and CA_NO_MFA_REQUIREMENT (no Conditional Access policy actually requires MFA in the first place, which undermines any registration-order improvement).
ℹ️ Note: EtcSec automatically checks for these gaps during every Azure/Entra audit. Run a free audit to see whether your tenant is positioned to take advantage of passwordless-first registration once it reaches your region.
Explore the identity security pages that support this topic