Passkeys become the default in Entra: SMS and voice retire 1 February 2027

A passkey is a sign-in key stored on your device (phone, computer or a physical security key) and unlocked with a fingerprint, face or PIN. It cannot be phished, because there is no code to intercept or forward to a fake site. It replaces both password and SMS code in a single step.

From 1 September 2026 Microsoft makes passkeys the default in Entra ID (Microsoft's identity platform, formerly Azure AD). Two things happen automatically in your tenant:

• •Passkeys are enabled for users currently set up with SMS or voice. You do not need to turn the feature on yourself.
• •The registration campaign is set to Microsoft-managed. That means users are prompted to create a passkey the next time they sign in with MFA.

Users can skip the prompt and keep their current method for now. On this date it is an invitation, not a requirement. But it is the starting gun: Microsoft is moving everyone toward passkeys, and the next date has real consequences.

From 1 February 2027 Microsoft's own SMS and voice codes can no longer be used as an MFA method (multifactor authentication, the extra step beyond the password). This is where it gets serious.

If you have users who only verify with an SMS code or an automated call from Microsoft, they lose their sign-in method that day. Without another registered method they cannot get in, and then they call you or the helpdesk.

It typically hits two groups: employees without a smartphone running the Authenticator app, and service or shared accounts where someone once set a phone number as the only method. Find them now, not in January 2027.

Here is a distinction many people miss. Registering and signing in with a passkey works on the free tier of Entra ID. It costs nothing extra, and all your users can use it.

Requiring users to use a passkey (or another phishing-resistant method) is a different matter. You do it with authentication strengths in Conditional Access, and Conditional Access needs Entra ID P1.

Here is how the Entra ID tier comes with the common plans:

So if you run Business Basic or Standard, your users can create passkeys, but you cannot force it with a policy. To document that only phishing-resistant sign-in grants access to your data, you need at least Business Premium or a separate Entra ID P1 add-on. It is another concrete example of what the license tier actually decides.

NIS2 (the EU network and information security directive) requires a set of technical security measures in Article 21, and multifactor authentication is named explicitly. Regulators and the industry increasingly point to phishing-resistant MFA as the standard to hit, because SMS codes can be defeated with phishing and SIM swapping.

That is exactly what passkeys deliver. A passkey satisfies Microsoft's built-in requirement for phishing-resistant MFA, alongside Windows Hello for Business and certificate-based sign-in. So Microsoft's shift lines up with the direction NIS2 is already pushing you.

For a Danish SMB working toward NIS2 or the D-mærke there are two points:

• •Passkeys are the easy route to documenting phishing-resistant access. You move from a method that can be phished to one that cannot.
• •Documentation requires enforcement, and enforcement requires P1. Users being *able* to use passkeys is not enough for an auditor. You need to show a policy that *requires* it, and that policy is Conditional Access.

That is how license and compliance connect in practice: the technical capability is free, but the documentable control sits behind the P1 license.

The second deadline (1 February 2027) is the one that can hurt. Here is how to get ready in good time:

Some organizations cannot do without a code on the phone. That applies to employees without a company phone running the app, or industries where SMS is the only realistic method for part of the staff.

It is still possible after 1 February 2027, but the responsibility moves to you. Microsoft stops delivering the SMS and the call itself, and you instead connect your own telecom provider through the Microsoft Security Store. If you do not set that up, the method disappears for those users.

My advice is to treat SMS as a transition solution you actively wind down, not a permanent state. The direction from both Microsoft and NIS2 is clear: away from codes that can be phished, toward passkeys. The sooner you move the bulk of users, the less trouble you have with Security Store setup and exceptions.

Tie it in with your SSPR work, where from 7 September 2026 Microsoft also only accepts self-service reset based on methods the user has registered themselves. It is the same move toward registered, phishing-resistant methods.

Sources: Microsoft Learn: Passkeys by default and retirement of SMS and voice, Microsoft Learn: FAQ on the retirement, Microsoft 365 Message Center MC1426371, Microsoft Learn: authentication strengths and license requirements.