SMS and voice are leaving Entra ID.
And the second date cannot be deferred.

Microsoft has decided two distinct things, and it helps to keep them apart. The first: passkeys become the default authentication experience in Microsoft Entra ID. The second, the one that really matters: SMS and voice will no longer be provided natively by Entra ID. This is not encouragement to modernise — it is the removal of a method that, in a great many organisations, is the only second factor actually configured.

The four dates to note

1 September can be deferred. 1 February cannot.

This is the distinction most likely to prove expensive, because the first date is soft and invites complacency. On 1 September, users enabled for SMS or voice are placed in a profile that allows all types of passkey, and the registration campaign picks them up automatically: at their next sign-in with MFA they see the prompt to register one. By default that prompt can be snoozed an unlimited number of times. In practice, most users click “later” and that is the end of it.

On 1 February 2027 the behaviour changes in kind. Users whose only available MFA method at that point is SMS or voice receive a passkey registration prompt at sign-in that can no longer be snoozed: without completing it, they do not get in. Microsoft says so without ambiguity — there is no opt-out for the February deadline and the rule applies to every tenant. Nobody is permanently locked out of their account, but in practice, on the morning of 1 February, part of the workforce will face a mandatory registration they have never seen before, with no warning and no idea what to do.

The trap: when “no action required” is the wrong answer

Microsoft provides a script to inventory who in the tenant still uses SMS or voice, runnable with the global reader, authentication policy administrator or security reader roles. It is the right starting point, but its output should be read with care: the script looks at the modern authentication methods policy.

If the tenant has not completed migration from the legacy one — the state the portal calls “migration not started” — SMS and voice can appear disabled in the modern policy while users keep using them through the old per-user MFA settings. The script returns a reassuring “no action required” and the tenant looks fine. But the Microsoft documentation brings into scope users enabled for SMS or voice in the authentication methods policy or in legacy MFA settings. The bill arrives in February.

There is only one check to run before trusting the inventory: look at the migration state in Entra ID, under Protection, Authentication methods, Manage migration. If it is not “Migration complete”, the tenant lives in a mixed state and the inventory has to be redone by looking at the methods users have actually registered, not at the policy settings.

The personal phone, and the GDPR question inside the obvious fix

Here the issue stops being technical. The scenario you meet most often in mid-sized organisations is this: MFA is on, the second factor is an SMS, and the number it arrives on is the employee’s personal number. Microsoft Authenticator was never rolled out, and the reason is always the same — there are no company phones, so the app would have to land on somebody’s private device.

The instinctive reaction to this news will be “then let’s deploy Authenticator”. It is worth pausing, because that choice carries an implication that rarely gets assessed. If Conditional Access uses GPS-based named locations, Authenticator asks for location permission in “always allow” mode and the system collects the phone’s position every hour — even in report-only mode. On a personal device that means a continuous stream of an employee’s location data, with everything that implies for lawful basis and proportionality. Microsoft itself recommends reserving those policies for very sensitive applications. Standard number matching, to be clear, does none of this: it shows an approximate location derived from the IP address, not the phone’s coordinates.

What makes this interesting is that a forced migration is a chance to get out of the problem rather than move it. A passkey on a company device, or a FIDO2 security key assigned to the person, closes the question at source: no app on a private phone, no location tracking, no personal number inside company systems. For anyone thinking in NIS2 terms there is a further argument: the authentication method becomes a governable company asset rather than a favour asked of the employee.

People without a smartphone, and people on a Mac

Entra ID supports two families of passkey: synced ones, saved in a platform credential manager such as iCloud Keychain or Google Password Manager and available across the person’s devices, and device-bound ones, which stay on a single device — passkeys in Microsoft Authenticator, Entra passkeys on Windows, FIDO2 security keys. No group of staff is left without an option, but the routes are not equivalent.

• People with no smartphone, or who want no company apps on their own — a physical FIDO2 security key, bought by the organisation and assigned to the person. No additional licence, no data collected from a private device. It is also the most solid choice for administrative accounts.
• Windows workstations — an Entra passkey on the device itself, or Windows Hello for Business where it is already in use. Anyone with a FIDO2 deployment already under way is halfway there: we described the full procedure in our article on passwordless Windows sign-in with FIDO2.
• Mac — three routes, with different implications. A passkey with Touch ID requires no licence and no smartphone, but stays tied to the person’s personal Apple ID, which brings back the private-asset problem. A company FIDO2 key separates identity cleanly. Platform SSO with the Secure Enclave is the managed, device-bound option, conceptually similar to Windows Hello for Business, but it requires Intune.

What to do now

• 1Inventory who uses SMS or voice, and check the migration state — in that order. First confirm whether the tenant is at “Migration complete”; only then is the inventory result reliable.
• 2Decide the method for each group of staff before September — who has a company device, who works on a Mac, who has no smartphone, who holds privileged roles. These are different choices, and they need making before users start seeing unexpected prompts.
• 3Start the registration campaign on your own terms — enable Passkey (FIDO2) as a method first and scope in the security group of SMS and voice users, rather than being caught by the automatic activation in September. It requires no additional licence.
• 4Communicate before, not during — Microsoft names coordinated communication as the single biggest predictor of a smooth rollout, and provides templates for email and Teams. A notice sent after the first prompt is already one more call to the help desk.
• 5Consider a telecom provider only for documented needs — if a regulatory or operational constraint requires an out-of-band telephone channel, write down which one, for which group of users and on what rule it rests. Provider information arrives from 18 September, configuration from 30 October, and messaging costs move to the organisation.

What it takes to actually govern this

One point deserves precision, because it gets lost in the enthusiastic messaging around passkeys. Enabling passkeys and running a registration campaign require no additional licence: you only need MFA in place. But offering a method and governing it are two different things.

Requiring a phishing-resistant method for sensitive applications or administrative roles, excluding weak methods in given contexts, differentiating rules by group: these are authentication strengths, that is, Conditional Access features, and Conditional Access requires Entra ID P1. Without P1 you can enable or disable methods at tenant level and invite users to register, but you cannot write rules: you are left with security defaults, a generic all-or-nothing MFA. For many organisations this deadline will, in practice, be the moment the licensing question comes back on the table — and it is better faced now than in January.

A final point of scope, because it causes confusion: Azure AD B2C is not affected by this announcement. For Microsoft Entra External ID the change is planned for next year, with a separate communication.