Entra Is Retiring SMS MFA: A Keycloak Passkey Migration Plan

Last updated: September 2026

Microsoft-provided SMS and voice authentication in Entra ID retires on 1 February 2027, and passkeys became the default experience for affected users on 1 September 2026. That does not mean SMS stops working everywhere, but the replacement is not available yet either: Microsoft publishes the customer-managed telecom details on 18 September 2026, and tenants can only select a third-party provider from the Microsoft Security Store from 30 October 2026. A temporary opt-out covers the gap. The real signal is the direction of travel. NIST already classifies PSTN-delivered one-time codes as a restricted authenticator, so if you run customer or workforce identity on Keycloak, the same pressure is arriving on your realm whether or not Entra is in your stack. Keycloak ships every piece you need to make the move, and the hard part is the fallback path rather than the passkey itself.

Most write-ups of this change land in one of two ditches. Either SMS is declared dead when it isn’t, or the whole thing gets waved off as a Microsoft licensing detail. Neither is much use if you’re the person who has to decide what your login screen does next quarter.

What is Microsoft actually retiring, and when?

Microsoft is retiring its own telecom delivery of SMS and voice codes, not the concept of telephony MFA. According to Microsoft Learn, “Passkeys by default and retirement of Microsoft-provided SMS and voice authentication,” four dates matter, and only the first two have passed.

The change was communicated to tenants as Message Center post MC1426371 in July 2026, which is the reference your Microsoft 365 admin will recognize if you need to go find the tenant-side detail.

That middle pair of dates is the part most summaries drop, and it matters for planning. If you went looking for the customer-managed telecom option this week, there was nothing to configure yet. Microsoft recommends finishing that setup at least four weeks before the February deadline, which leaves a real but not generous window between 30 October and early January.

A temporary opt-out also exists, letting tenants delay the passkey default and the registration campaign during the period between September 2026 and February 2027 while transition work completes.

So the accurate framing is that Microsoft is exiting the business of sending your OTP text messages, and nudging hard toward passkeys on the way out. Organizations that genuinely need a phone-based fallback can still have one from late October, and will pay for it directly.

Does this affect you if you are not on Entra?

Yes, through the standards rather than through Microsoft. In 2025, NIST finalized Special Publication 800-63B-4, “Digital Identity Guidelines: Authentication and Authenticator Management,” which places out-of-band authentication over the public switched telephone network in a category of its own: a restricted authenticator, and at publication the only member of that category. Restricted does not mean banned. It means you may keep using it under conditions: document a risk assessment, offer users at least one alternative authenticator that is not restricted, tell them the method is going away, and keep a migration plan for when you retire it.

That second condition is the one that quietly forces the work. You cannot satisfy it by documenting your SMS risk and carrying on, because it requires the alternative to exist and be offered.

That is a fairly specific piece of homework, and it applies to a Keycloak realm exactly as much as it applies to an Entra tenant.

The practical read for a platform team: when one of the largest workforce identity providers stops carrying SMS itself, and the US standards body says PSTN codes need a documented exit plan, the question stops being whether to move and becomes which quarter you book the work into.

What counts as phishing-resistant MFA?

Phishing-resistant MFA means an authenticator that cannot be replayed by an attacker who successfully tricks the user, because the credential is cryptographically bound to the site that requested it. In practice that means WebAuthn and FIDO2 credentials, including passkeys, and PIV or smart cards. Everything that involves the user reading a code and typing it somewhere fails the test.

Here is the uncomfortable part for teams who already spent a rollout cycle on MFA: push notifications and authenticator-app codes are both better than nothing and both still phishable. An attacker running a real-time proxy relays whatever the user types, and push fatigue attacks simply ask until someone taps approve. Only the origin-bound cryptography closes that gap.

SMS carries an extra failure mode the others don’t: the attacker doesn’t need the user at all. SIM swap moves the number to a new device, and interception at the network layer reads the message in transit. That is why SMS ends up in its own restricted bucket rather than merely in the not-phishing-resistant bucket.

How do you turn on passkeys in Keycloak?

Keycloak has shipped WebAuthn for years, and the modern passkey path runs through the WebAuthn Passwordless Policy rather than requiring a hand-built authentication flow. That integration landed in 26.3.0, where Keycloak put passkeys into the default authentication forms with conditional and modal UI, and it was promoted to fully supported in 26.4.0. The current release line is 26.7.x, so on any recent version this is supported rather than preview.

1. Authentication > Policies > Webauthn Passwordless Policy. Set Enable Passkeys to ON and Require Discoverable Credentials to Yes. Discoverable credentials are what let a browser offer the account picker without the user typing a username first.
2. Authentication > Required Actions. Enable Webauthn Register Passwordless. This is the required action that creates a discoverable credential governed by the passwordless policy. The similarly named Webauthn Register creates a second-factor credential governed by the separate WebAuthn Policy, and mixing the two up is the most common way this configuration goes sideways.
3. Attestation and authenticator constraints, in the same policy. Attestation Conveyance Preference, Authenticator Attachment and Acceptable AAGUIDs are where you decide whether to accept syncable passkeys from platform keychains, or to require attested hardware keys for a privileged subset. Consumer-facing realms almost always want the former, and admin realms often want the latter.

If you want the full walkthrough with the flow diagrams, we wrote it up separately in the Keycloak passkeys and WebAuthn guide, and there’s a front-end integration companion covering passkeys in React and Next.js.

The notable thing is how little of the migration effort this step consumes. Enabling passkeys is an afternoon of configuration, and removing the SMS authenticator safely is the part that takes a quarter, which is why the rest of this post is about the second half.

How do you retire SMS without locking people out?

The failure mode to avoid is the one where a user loses a phone, has no second method registered, and lands in a helpdesk queue holding a password reset that your new policy no longer accepts on its own. Recovery is the part of a passkey migration that actually needs design work.

Keycloak gives you three fallbacks that don’t involve a phone number, and the ordering matters:

• Recovery codes. Keycloak’s Recovery Authentication Codes graduated from preview to a supported feature in release 26.3.0. A user generates a set of single-use codes and stores them outside the device. For a workforce realm this is usually the cleanest backstop, because it survives a lost phone and a lost laptop at once.
• A second passkey. Two credentials on two devices removes most recovery events before they happen. A registration campaign that asks for a second passkey a week after the first one is cheap to run and disproportionately effective.
• TOTP as a transitional second factor. Not phishing-resistant, but strictly better than SMS while you get adoption up, and it fails closed rather than leaking to whoever holds the phone number.

Then phase the enforcement rather than flipping it. A workable sequence looks like this: enable passkey registration and let it run voluntarily, watch the registration rate, make registration a required action for new users, then make it required for everyone, and only after that remove the SMS authenticator from the flow. The last step is the one to hold until your registered-credential coverage is high enough that the helpdesk can absorb the stragglers.

What we see in practice: the adoption curve is almost entirely driven by whether the prompt appears at sign-in or only in the account console. Self-service registration pages that users have to go find on their own convert poorly, and teams that rely on them tend to stall well short of their target and conclude that passkeys are unpopular, when the more likely explanation is that the prompt never reached most people.

What about step-up, when some users still need a weaker factor?

Keycloak handles the mixed-population case through Level of Authentication mapping rather than through a single realm-wide switch. The Conditional - Level of Authentication execution in an authentication flow lets you attach different requirements to different LoA values, and the client requests a level with acr_values. A session that authenticated with a password and a TOTP code carries one ACR value; a session that used a passkey carries another.

That gives you a way to keep a long tail of users on a weaker factor for general sign-in while requiring a passkey for the operations that matter, such as changing payment details or administering the realm. Our step-up authentication guide covers the flow construction in detail.

It’s a genuinely useful staging tool during a migration, because it decouples “everyone has a passkey” from “sensitive actions are phishing-resistant,” and lets you reach the second of those well before the first.

If you broker Entra through Keycloak, whose MFA counts?

When Keycloak brokers an external identity provider, the MFA performed at the home tenant and the MFA required by your realm are two separate decisions, and Keycloak does not automatically trust the former. Each identity provider configuration carries a post-login flow, which runs in your realm after the external authentication returns. That is where a realm-level requirement gets enforced regardless of what the upstream tenant did.

This matters more than usual during the Entra transition, because the population brokered from an Entra tenant is about to change authenticators underneath you. Users who were completing MFA with a text message at the home tenant will be registering passkeys there instead, on Microsoft’s schedule rather than yours. If your realm has its own requirement in a post-login flow, that change is invisible to you and everything keeps working. If your realm was implicitly relying on the upstream factor, it is worth confirming what you’re actually receiving before February 2027.

For the broader mapping between the two systems, we have a walkthrough of Entra ID concepts through a Keycloak lens, and the mechanics of setting up Entra ID SAML as a Keycloak identity provider.

What should you measure during the rollout?

Track four numbers, weekly, from the start of the campaign rather than from the point where something goes wrong.

1. Credential coverage. The share of active users with at least one passkey registered. This is the number that gates every enforcement decision.
2. Second-credential coverage. The share with two or more. This predicts your recovery volume better than the first number does.
3. Helpdesk contacts per thousand sign-ins. Watch the delta when you change enforcement, not the absolute value.
4. Authentication method mix. What users actually complete with, which is frequently not what the policy suggests they should be using.

Keycloak’s event log carries the raw material for all four, with one detail worth knowing before you build a dashboard on it. Admin events record administrative API operations, not logins. The number you want comes from LOGIN events, which carry a credential_type detail for the authenticators that set one, WebAuthn and recovery codes among them. That is enough to compute method mix and coverage, and exporting the events to your existing log pipeline is a standard setup rather than a custom build.

If you also want password hygiene covered during the same window, the password policy guide pairs with this work, and the audit logs and multi-factor authentication feature pages describe the same surfaces on managed Keycloak.

If you’re arriving from the Entra side rather than the Keycloak side, the category to compare against is identity management as a service: the same authentication, MFA and federation surface, operated by someone else. Skycloak runs upstream Keycloak, so every policy path and required action above is identical on managed hosting. What changes is who schedules the 26.x upgrades during a migration window, and who is on the hook when a browser vendor changes passkey behavior mid-rollout.

Frequently asked questions

Is SMS MFA being banned?

No. Microsoft is retiring its own SMS and voice delivery in Entra ID on 1 February 2027, and tenants can keep telephony by configuring a third-party telecom provider through the Microsoft Security Store, which opens for that from 30 October 2026. Separately, NIST SP 800-63B-4, published in 2025, classifies PSTN-delivered codes as a restricted authenticator, permitting continued use only alongside a non-restricted alternative, a risk assessment and a migration plan.

What is phishing-resistant MFA?

Phishing-resistant MFA uses credentials cryptographically bound to the requesting origin, so an attacker relaying a login in real time gets nothing usable. Passkeys, WebAuthn and FIDO2 security keys, and smart cards qualify. Authenticator-app codes, push approvals and SMS codes do not, because each involves a secret the user can be tricked into handing over.

Does Keycloak support passkeys?

Yes, as a fully supported feature since release 26.4.0. Keycloak integrated passkeys into the default authentication forms in 26.3.0 and promoted that from preview to supported in 26.4.0. Enable the Enable Passkeys switch in Authentication > Policies > Webauthn Passwordless Policy, with discoverable credentials required, and no custom browser flow is needed.

What happens to users who lose their passkey device?

They fall back to whatever else they have registered. Keycloak’s recovery codes, supported since release 26.3.0, are the usual answer, and a second passkey on a second device prevents most of these events entirely. Design this before enforcement, because recovery volume is what determines whether a rollout feels smooth or painful.

Can we keep SMS for some users and require passkeys for others?

Yes, using Level of Authentication mapping. The Conditional - Level of Authentication execution lets different flows satisfy different ACR values, and clients request a level with acr_values. A common staging pattern requires passkeys only for sensitive operations while general sign-in accepts a weaker factor during the transition.

How long does a passkey migration take?

The Keycloak configuration takes an afternoon. Getting registration coverage high enough to remove the old authenticator safely is the part measured in quarters, and it depends almost entirely on whether users see the registration prompt during sign-in rather than having to find it in an account console.

Sources

• Microsoft Learn, “Passkeys by default and retirement of Microsoft-provided SMS and voice authentication,” retrieved 2026-09-15, https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement
• Microsoft Learn, “FAQ for Microsoft-provided SMS and voice retirement,” retrieved 2026-09-15, https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement-faq
• NIST, “Special Publication 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management,” finalized 2025, retrieved 2026-09-15, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf
• Keycloak, “Keycloak 26.3.0 released,” passkeys in the default forms and recovery codes promoted from preview to supported, retrieved 2026-09-15, https://www.keycloak.org/2025/07/keycloak-2630-released
• Keycloak, “Passkeys support in upcoming Keycloak release (26.4),” retrieved 2026-09-15, https://www.keycloak.org/2025/09/passkeys-support-26-4