Passkeys by default and retirement of Microsoft-provided SMS and voice in Entra ID

Stefan Dohnal •
Entra ID
Entra ID Authentication methods Passkeys SMS Voice

BannerImage

Table of contents

What Microsoft actually announced

Microsoft recently published an update for Microsoft Entra ID that does two things at the same time: it makes passkeys the default authentication experience and it schedules the retirement of Microsoft-provided SMS and voice delivery for authentication and SSPR.

The goal is not to remove every possible SMS or voice scenario globally, but to stop being the telecom provider for Entra ID tenants and to push organizations towards phishing-resistant, public-key based authentication methods like passkeys, FIDO2 security keys, Windows Hello for Business and platform credentials on macOS.

Personally, I highly appreciate this change to raise awareness for the future (and already go-to standard) of authentication. This post will outline how the announcement can be treated as an opportunity and how it impacted a real-life project I am working on.

Timeline

The visualization below illustrates the timeline of Microsoft’s passkey and SMS/voice retirement announcement.

In other words: September 2026 is when Microsoft starts nudging your user base into passkeys, and February 2027 is when their SMS and voice channel really goes away.

Gate 1 – Do you need to act before September 2026?

The first question I ask customers is simple:

“Can we afford to let Microsoft’s passkey registration campaigns run as-is – or do we want to stay in full control of when and how users see new prompts?”

For some larger organizations I work with, the picture looks like this:

  • Nobody relies only on SMS or voice anymore as their primary factor (which is good).
  • But there is still a large number of users with SMS or voice registered as a method, often for Self-Service Password Reset (SSPR).
  • In one tenant with around 5,000 users, about 1,700 users still had SMS and/or voice registered and used it for SSPR when needed. The planned migration path was to move them to Microsoft Authenticator push for SSPR.

In that kind of environment, September 2026 is not a “drop everything” date – but it is also not something you want to completely ignore.

A few indicators that you can probably wait and let the Microsoft-managed registration campaign run:

  • Most users already sign in with Microsoft Authenticator or other non-SMS methods today.
  • SMS and voice exist mainly as backup methods and are used rarely.
  • Your helpdesk can handle additional passkey registration prompts and has communication templates ready.

Indicators that you should act before September:

  • You have sensitive personas (for example admins, finance, executives, OT operators) where you do not want a surprise registration UX you did not announce.
  • You run in environments with strict change windows where new prompts must be tested and communicated first.
  • You want to combine passkey rollout with other changes in your authentication methods policy instead of letting it “just happen”.

Gate 1 is therefore a governance decision: are you okay with Microsoft driving the registration UX for your SMS and voice users, or do you want to own that implementation timeline? I always recommend to define dedicated plans for changes and migration paths. In above exampled scenario we were working anyways on cleanup of older authentication methods and we decided to treat this planned change as an opportunity to finalize cleanup before September 2026.

Gate 2 – Do you still want SMS or voice after February 2027?

The second decision is more fundamental:

“Does SMS or voice still have a legitimate place in our authentication and SSPR strategy – and if yes, for whom exactly?”

Microsoft’s change is specifically about Microsoft-provided SMS and voice delivery in Entra ID. If you still need SMS or voice, the new pattern is to integrate a customer-managed telecom provider via the Microsoft Security Store instead.

This raises a few questions:

  • Are there regulatory, operational or usability reasons that make SMS or voice a necessary backup channel for certain personas?
  • Do you have user populations without managed devices or without reliable access to an authenticator app, where an SMS-capable phone is realistically the only thing they always carry?
  • How well do you trust the SIM management processes of telecom providers you work with, given how often SIM swap stories pop up in the security news?

From my point of view, this change is a good opportunity to push SMS and voice where they belong:

  • Not as the primary factor or default fall-back for everyone.
  • But as a narrowly scoped, well-understood option for specific scenarios where other methods are not feasible today.

If you decide that SMS and voice do not have a future in your tenant at all, February 2027 becomes the firm end of your grace period. If you decide they do, then you also accept the additional complexity of managing a telecom provider integration and treating it like any other critical dependency in your identity stack.

A pragmatic migration plan

Let’s turn this into something actionable. A lot of the fear around announcements like this comes from not having a simple, realistic plan.

Phase 1 – Get visibility into SMS and voice usage

Before changing anything, you need to understand your starting point.

  • Inventory registered methods
    Identify users who still have SMS or voice registered as authentication methods and, more importantly, who actually use them – especially for SSPR.
    Microsoft published a script so any Entra ID administrator can evaluate the impact of the planned change according to Microsoft measures.

  • Cluster your populations
    Group users into typical personas: admins, information workers, contractors, frontline workers, external partners, guests and so on. SMS in a contractor-heavy environment looks very different from SMS usage in a pure office workforce.

  • Correlate with sign-in and SSPR logs
    Combine method registration with sign-in and SSPR logs to see which combinations are used in practice. This is where numbers like “1,700 out of 5,000 users still rely on SMS for SSPR” become concrete and actionable.

This phase is usually an analytics exercise, not a configuration change – but it gives you the map you need for the rest.

Phase 2 – Promote phishing-resistant methods as the new normal

If you want to be ready for September 2026 and February 2027, you should already have an answer to the question:

“What is my default, phishing-resistant path for most users?”

In many projects today, this looks like:

  • Admins and privileged roles
    FIDO2 security keys (or other device-bound passkeys) combined with strong Conditional Access and PIM. These accounts are not where you want synced passkeys or generic SMS-based factors.

  • Standard users and information workers
    Microsoft Authenticator passkeys, Windows Hello for Business on Windows devices, and platform credentials on macOS. This gives you phishing-resistant authentication without the logistics overhead of hardware-only approaches.

  • Specific personas
    For some groups, synced passkeys maintained by password managers or platform keychains can be an acceptable middle ground, as long as they stay away from admin roles.

On the policy side, this is where you:

  • Make sure these methods are enabled and discoverable in your Authentication Methods configuration.
  • Avoid designing your policies and manuals in a way that teaches users “SMS is the easiest way to get back in”.

The idea is not to flip a single switch overnight, but to move your default posture so that passkeys and other phishing-resistant methods naturally become the path of least resistance.

Phase 3 – Decide what to do with SMS and voice before 2027

With the groundwork done, you can make a deliberate decision instead of reacting late.

If you decide against SMS and voice:

  • Plan a staged deprecation where new registrations are discouraged or blocked, and existing users are migrated to other methods.
  • Align your communication so that users understand why SMS is being phased out and what they should use instead.
  • Update your documentation and support runbooks so that February 2027 is a non-event in practice.

If you decide for SMS and voice (for well-defined populations):

  • Treat the telecom provider integration as a first-class project, not as an afterthought.
  • Define exactly which groups are allowed to use SMS or voice and under which conditions.
  • Document the risk trade-offs explicitly, especially around SIM swap and social engineering at telecom providers. If you rely on them, their processes become part of your security posture.

In both variants, you end up with a cleaner, more predictable authentication landscape than many tenants have today.

Strategic perspective – what this really changes

Looking at this as a security architect, the announcement is less about Microsoft taking something away and more about setting a new baseline expectation:

  • Phishable factors like SMS and voice are no longer treated as “good enough defaults” that the platform will happily deliver for everyone.
  • Public-key, phishing-resistant authentication becomes the expected default for Entra ID, not an optional advanced feature.

At the same time, Microsoft is still leaving a door open for organizations that genuinely cannot get rid of SMS or voice yet – but that door now comes with an explicit “you own this” label in the form of a telecom provider integration.

If you have been postponing a proper passkey and FIDO2 rollout for years, this is one of those moments where the platform forces the conversation. And from a security perspective, that is not necessarily a bad thing.

Self Service Password Reset - support of phishing-resistant methods

At the time of writing, there is no public announcement from Microsoft that confirms if or when Self-Service Password Reset (SSPR) will support phishing-resistant methods such as passkeys, Windows Hello for Business, or FIDO2-based sign-in.
I’m convinced that Microsoft is already looking at SSPR on a strategic level – either by evolving the service itself or by introducing some form of passwordless-aware recovery – but nothing in the current documentation commits to a specific timeline.

In many organizations, regular password changes are still a hard requirement, even when passwordless sign-in is the default. That creates an awkward tension: as long as a password exists on the Entra ID object, you need a reliable way to reset it – but the strongest sign-in methods you promote today don’t show up as SSPR methods yet.

If you move fast towards passkeys without designing a modern SSPR story in parallel, you don’t just have a password problem – you have a recovery problem waiting to happen.

Wrapping up

To summarise the most important points for your own planning:

  • No need to panic – but ignoring this until January 2027 is also not a strategy.
  • Use Gate 1 to decide whether Microsoft’s passkey registration campaigns in September 2026 can run as-is or whether you want to stay in tight control of the rollout.
  • Use Gate 2 to decide if SMS and voice still belong in your long-term design at all – and if yes, for which personas and via which telecom provider.
  • Focus your energy on building a phishing-resistant default path for the majority of your users, instead of discussing every possible edge case first.

If you already have strong FIDO2 and passkey deployments, this change will probably help you rather than hurt you. If you still rely heavily on SMS for SSPR and as a comfort blanket for “just in case”, now is a good time to turn that into a real project – not a last-minute fire drill.