The end of SMS and phone call-based MFA in Microsoft 365: why admins need to act now
Microsoft is drawing a line under one of the oldest crutches in IT security: SMS and voice call-based multi-factor authentication in Entra ID is being phased out. From 1 September 2026, Microsoft will make passkeys the default sign-in method; from 1 February 2027, SMS and voice calls will be gone for good, at least where Microsoft provides them. For organisations that have had MFA “somehow set up” for years and never touched it again, this is the most unpleasant wake-up call of the year.
What is actually changing
Microsoft officially announced the change on 13 July 2026. Two things are happening, and they should be considered separately from a technical perspective, even though they are being communicated together.
🔵 From 1 September 2026
- Passkeys become the default sign-in experience
- All SMS/voice users are automatically migrated to the passkey profile
- The registration campaign is set to “Microsoft Managed”
- Users are prompted to register at their next MFA sign-in
🟠 From 1 February 2027
- Microsoft-provided SMS/voice is switched off completely
- Anyone who absolutely needs SMS/voice must configure their own telecoms provider
- Bookable from 30 October 2026 via the Microsoft Security Store
- Without configuration: SMS codes simply stop working
Important for admins: the question is not whether someone actually signs in via SMS, but whether the method is enabled for them. If your policy has SMS enabled for “All users”, you are fully affected, even if in reality only a handful of people have ever used it. Self-Service Password Reset (SSPR) is affected too, if SMS or phone calls are configured there as verification methods.
One detail that many overlook: there is a temporary opt-out option via the Microsoft Graph API (optOutSettings.passkeyDynamicMigration) that lets you delay the automatic switchover. It is available from 1 August 2026. That buys breathing space for a clean migration, but it is no free pass to postpone the topic until 2027.
Why this is more than just another Message Center update
Microsoft itself openly describes SMS and voice as methods that “can no longer stop AI-powered attacks”. That is not a marketing cliché.
SMS codes are based on a shared secret transmitted over an insecure channel (the mobile network), a classic target for SIM swapping, SS7 attacks and real-time phishing proxies. According to Microsoft Threat Intelligence, AI-assisted phishing campaigns now reach click rates of up to 54 %, compared with around 12 % for traditional campaigns. Passkeys, by contrast, are based on public-key cryptography and are therefore fundamentally phishing-resistant: there is no secret an attacker could intercept or trick out of a user, because the private key never leaves the device.
From a security perspective, the move is overdue and right. From an admin perspective, it is still a project rather than a tick on a checklist, above all because it arrives automatically and is mandatory for all tenants, whether or not the migration has been prepared.
Who is particularly affected
- Organisations with old or never-revised MFA configurations where SMS/voice is still broadly enabled
- Sectors with compliance requirements for telephony-based MFA, which now have to actively plan and budget for a third-party provider
- Organisations with many frontline or deskless workers without a company smartphone running an authenticator app
- B2B guests and external partners, for whom full passkey support is not available until the end of 2026
- Tenants still on legacy MFA settings instead of the modern Authentication Methods Policy
What passkeys actually are, and what they are not
Before talking about migration, a short definition is worth the time, because “passkey” is automatically equated with “hardware key” in many people's minds. That is only partly true.
Technically, a passkey is a FIDO2/WebAuthn credential: an asymmetric key pair where the public key is stored with Microsoft and the private key never leaves the device. At sign-in, the device cryptographically proves that it holds the private key, entirely without a password or code that could be intercepted. That is exactly what makes passkeys phishing-resistant: there is simply no secret left for a fake login page to harvest.
🔒 Device-bound passkeys
- Tied to a single device, never leaves it
- FIDO2 hardware security keys (USB/NFC)
- Windows Hello (face, fingerprint, PIN, bound to the TPM)
- Passkeys in the Microsoft Authenticator app
- If the device is lost: the passkey is irrevocably gone, recovery required
☁️ Synced passkeys
- Synchronised between devices in encrypted form via a cloud provider
- E.g. iCloud Keychain, Google Password Manager
- More convenient if a device is lost
- No hardware attestation possible
- Recommended for the “normal case”, not for admin roles
In short: a passkey is not necessarily hardware, and it does not necessarily run through the authenticator on a private phone. Microsoft Authenticator is just one of several possible carriers.
The answer to the most common conflict: no FIDO2 keys to buy, and no private phone to use
In practice, many organisations hit a conflict at exactly this point: FIDO2 hardware keys cost money, procurement effort and support effort per user, while at the same time many employees do not want to (or, for data protection reasons, may not) use their private smartphone for a corporate login.
Our recommendation: in most cases Windows Hello on the company laptop that already exists is the answer. Because the private key is stored in the device's TPM chip, there are no additional hardware costs and no private device is needed: sign-in runs via the camera, fingerprint sensor or PIN of the company device the user works with every day anyway. This also works on devices that are neither Entra-joined nor Entra-registered, for example on shared or unmanaged PCs.
For organisations that have already rolled out Windows Hello for Business, the switch is correspondingly the smoothest: the hardware basis (TPM, camera, fingerprint sensor) is usually long since in place, and often all that is missing is the matching passkey profile configuration in Entra ID.
For only two groups of users does this option fall short of a complete solution:
- Employees without a fixed company device (e.g. users of terminal server environments or frequently changing shared devices without biometric sensors): here there is often no way around FIDO2 hardware keys
- Admins and highly privileged roles, for which Microsoft recommends device-bound passkeys with enforced attestation anyway: here the investment in hardware keys pays off regardless of the cost question
For the bulk of the workforce, Windows Hello is therefore often the most pragmatic middle ground between “no extra budget for hardware” and “no access to private devices”, provided the company laptops have the necessary biometric sensors or at least PIN protection via TPM.
What IT teams should do now
Take stock
Check under Entra ID > Authentication methods which users and groups currently have SMS or voice enabled, both in the modern Authentication Methods Policy and in the legacy MFA settings. What matters is whether the method is enabled, not whether it is used.
Drive the passkey rollout actively
Anyone who steers the registration campaign themselves instead of letting it take effect automatically on 1 September avoids uncoordinated helpdesk tickets. Prerequisite: FIDO2/passkey must be enabled as a method and a target group defined.
Decide whether SMS/voice is still needed at all
If it is: evaluate and budget for a telecoms partner via the Microsoft Security Store in good time. Booking is only possible from the end of October 2026, but the decision should be made before then.
Check SSPR flows separately
The change affects not only sign-in but also password reset processes, which are frequently configured separately and easily overlooked.
Define the passkey carrier per user group
For most employees with a company laptop, Windows Hello is enough and costs nothing extra. Only for users without a fixed device or for admin roles is the investment in FIDO2 hardware keys worthwhile, and that needs lead time for procurement and rollout.
Use the opt-out only as a time buffer
The Graph API option buys time but is no substitute for a migration strategy; it merely defers automatic enforcement.
The point many underestimate
This change does not come in isolation. It is part of a series of security tightenings that Microsoft is rolling out across the M365 and Entra environment in 2026, from stricter rules for federated token validation to new governance features in Exchange Online. The common denominator: Microsoft is increasingly shifting responsibility back to the tenants. Anyone who does not actively maintain their authentication policies, conditional access rules and MFA methods runs into enforcement deadlines automatically, usually at a moment they do not get to choose.
How we can help
This kind of migration is exactly the case our M365 hardening service is built for. Among other things, we look at which MFA methods are currently enabled in your tenant and for whom, whether your Authentication Methods Policy or still-legacy settings apply, where users or groups have unnecessarily broad permissions for weak auth methods, and what a realistic, low-disruption rollout plan for passkeys looks like in your specific environment, including the cases where hardware security keys are the better choice.
Want to know where your MFA configuration stands before Microsoft makes the decision for you in September? Get in touch.
