Microsoft Is Making Phishing-Resistant MFA the Default. Your Exceptions Become the Risk.
Microsoft will make passkeys the default for Entra users who rely on SMS or voice, then retire Microsoft’s own delivery of those legacy factors in February 2027. The migration is not only an authentication upgrade. It is an inventory of every exception the organisation has postponed.
Microsoft has put an end date on a familiar compromise.
From 1 September 2026, Microsoft Entra will automatically enable passkeys for users who are enabled for SMS or voice authentication and nudge them to register a passkey during multi-factor authentication. On 1 February 2027, Microsoft-provided SMS and voice authentication will be retired for public-cloud tenants.
Organisations can retain SMS or voice by choosing a customer-managed telecom provider through Microsoft Security Store. That option preserves the method, not Microsoft’s delivery service.
The technical change is clear. The organisational work is in finding every person and process that is not ready for it.
The retirement happens in two stages
The first stage starts on 1 September 2026. Eligible users will have passkeys enabled automatically and will be prompted to register one during MFA. Administrators can temporarily opt out of this automatic enablement until the final retirement date. Microsoft says API support for that control will be available from 1 August 2026.
The second stage starts on 1 February 2027. Microsoft’s SMS and voice service stops. A user whose only registered methods are SMS or voice will enter a blocking passkey-registration experience, with no opt-out. The change also covers self-service password reset.
The current schedule applies to public-cloud tenants. Microsoft says other clouds will follow later. Internal and B2B guest support for passkeys is planned by the end of 2026 and is included in the retirement scope.
Why Microsoft is forcing the issue
SMS and voice are convenient because they work with devices users already have. They are also exposed to phishing, social engineering, SIM swapping, number reassignment, telecom interception and real-time code relay.
Passkeys change the model. The user authenticates with a cryptographic credential tied to the legitimate service and unlocked on their device. There is no one-time code to read to a caller or enter into a lookalike domain.
That origin binding matters as phishing becomes more interactive. BlackTree’s analysis of the Wall Street vishing wave showed how attackers can persuade users to approve the very controls designed to protect them. Passkeys reduce that human relay problem.
Microsoft is therefore doing more than changing a preferred sign-in method. It is removing a widely used fallback whose weaknesses are difficult to mitigate at scale.
Your exceptions become the project
The happy path is straightforward: a managed user with a compatible device registers a passkey and continues working.
The risk sits outside that path. Shared operational phones, contractors, frontline workers, recovery accounts, users without compatible devices, guests, accessibility needs, break-glass procedures and help-desk recovery flows may all depend on SMS or voice for different reasons.
Moving those users to a customer-managed telecom provider may avoid disruption, but it also preserves the phishing and telecom risks that motivated the retirement. An exception should therefore have an owner, a reason, a compensating control and an expiry date.
This is also a capacity problem. Registration campaigns create support demand. Lost-device scenarios need testing. Conditional Access policies can produce unexpected loops. Guest and cross-tenant use must be validated before the deadline reaches production users.
What Entra teams should do now
- Measure current dependence. Use Microsoft’s SMS and voice usage analyser and sign-in data to identify registered methods and actual use.
- Segment the population. Separate users who can move immediately from those with device, guest, accessibility or operational constraints.
- Deploy passkeys before the nudge. Follow Microsoft’s phishing-resistant passwordless deployment guidance, pilot with representative groups and train the help desk.
- Test recovery. A phishing-resistant sign-in programme fails if account recovery falls back to a weak, easily engineered method.
- Review Conditional Access. Confirm that registration, compliant-device and authentication-strength policies work together for new and recovering users.
- Govern telecom exceptions. If SMS or voice must remain, treat the provider decision as a security exception, not a simple procurement task.
- Plan guest migration. Validate B2B and internal guest workflows as Microsoft’s passkey support arrives, rather than assuming the host tenant will solve every case.
A deadline can improve identity hygiene
SMS and voice persisted because they were universally understood and rarely the highest-priority identity problem. Microsoft’s deadline changes that calculation.
The organisations that benefit most will use the retirement to remove weak fallbacks, harden recovery and discover forgotten user populations. The organisations that simply redirect SMS to a new provider will meet the service deadline while preserving much of the original risk.
Passkeys becoming the default is the easy part. Deciding which exceptions are still acceptable is the real security work.
