Microsoft's Passkey Switch Started September 1. We Got Part of Our August Post Wrong.

In August we covered Microsoft retiring the texted login code in favor of passkeys. The sentence that mattered most in that post was wrong. September 1 has come and gone, Microsoft has revised its own documentation twice since we published, and one of those revisions moved a deadline for a group of accounts every business has. So here is the corrected version.

The sentence: "If your people already use the Microsoft Authenticator app or a passkey, this change will pass you by quietly." The passkey half holds up. The Authenticator half does not.

What actually puts an account in scope

Microsoft's retirement page is specific about the trigger. On September 1, 2026, users enabled for SMS or voice in the Entra Authentication Methods Policy, or in legacy MFA settings, were auto-enabled for passkeys. What matters is whether text or phone codes are still turned on for that account in the policy.

So somebody who opens Authenticator ten times a day can still be in scope, because the text method is still enabled. Microsoft puts it this way: "users who remain enabled for SMS or voice might still receive prompts to register passkeys on eligible devices." The people Microsoft says can carry on are those already signing in with passkeys, Windows Hello for Business, or another phishing-resistant method. Authenticator push is not named.

We wrote the calmer version in our August post. It is corrected now, body and masthead.

What September 1 turned on

In-scope users go into a passkey profile that allows all passkey types, and the Registration Campaign is set to Microsoft Managed state targeting passkeys. The next time one of those users completes MFA, the campaign nudges them to register a passkey.

It is a nudge, not a wall. Microsoft's wording: "By default, users will have unlimited snoozes of the nudge prompt."

It also does not land everywhere on the same day. Microsoft's phrasing is that the change starts September 1, and BleepingComputer's report described it reaching organizations one at a time rather than all at once. If nobody in your business has seen the prompt yet, that is not evidence you are out of scope. The tenant policy is the only place to check. Microsoft publishes a PowerShell script that lists which of your users are still enabled for SMS or voice, and a non-zero result means you are in scope.

The documented pause

A temporary opt-out is available for the September 1, 2026 through February 1, 2027 changes, described as a way to "delay passkey and Registration Campaign enablement while you complete transition activities." It is a Microsoft Graph call rather than a switch in the admin center: set passkeyDynamicMigration to true on the authentication methods policy, which needs the Policy.ReadWrite.AuthenticationMethod permission. Microsoft documented it on July 29, two weeks before our August post. New to us. Not new.

The next line is the one people get backwards: "Beginning February 1, 2027, standard passkey migration and enforcement timelines apply regardless of this setting for users in scope of the February 1 retirement." The pause moves the nudge. It does not move the retirement.

Would we use it? Case by case, and our default is passkeys on. A short pause can buy a cleaner migration for one business. That is a conversation about one business, not a default.

February 1, 2027, and now July 1, 2027

This is the part Microsoft changed after our August post. Revisions on September 16 and September 23 split one deadline into two.

February 1, 2027 is when Microsoft-provided SMS and voice delivery retires for everyone except Global Administrators and external users. Internal guest users stay on the February 1 date. Global Administrators and external users move to July 1, 2027. If you read the August coverage anywhere, including ours, and filed away "everything ends February 1," your admin accounts are on a different clock than your staff.

After the date that applies to them, users whose only available MFA method is SMS or voice have to register a passkey during sign-in to keep going, unless the business has configured a telephony provider and migrated those users to it. Microsoft says that prompt is blocking.

Microsoft's FAQ answers the lockout question directly: "No. If customers do not configure a telephony provider by the applicable retirement date, users who still use SMS and voice will receive a blocking registration prompt to register a passkey. They will no longer be able to skip this prompt and will need to complete passkey registration before they can continue to sign in." Blocked at sign-in until they register, not shut out of the account.

And Microsoft is blunt about the exit: "There is no opt out for enforcement. This requirement applies to all tenants on the applicable retirement date for each user population."

If a business truly needs texted codes

Microsoft calls it Choose Your Own Telephony Provider, and you contract the provider yourself through the Microsoft Security Store. You cannot configure it yet. Soprano and Telesign are the initial providers in a private preview, their offers are listed in the Security Store now, and the configuration experience opens October 30, 2026. From that date you can set one provider per channel, one for SMS and one for voice.

It costs money on two lines. The provider charges for the messages, priced by the offer you pick: Soprano lists a per-user offer and a per-transaction offer, Telesign lists Telesign Verify for Microsoft Entra. Separately, the feature routes authentication through a function deployed in your own Azure subscription, and Microsoft says standard Azure consumption charges apply there, expected to be minimal next to the provider's bill.

One more limit worth knowing before anyone plans around it: a telephony provider does not bring back text messages as a way to sign in. Microsoft says the feature does not support SMS sign-in as a primary authentication method, and that retirement applies even if you contract a provider.

A provider only helps for the users you actually migrate to it before their retirement date. Moving users to passkeys instead carries no additional cost, and Microsoft recommends passkeys as the primary migration path for all users where possible.

Where the passkey lives

Across our own clients, Keeper is the password manager, and where we expect the passkey to sit. Keeper's docs say storing passkeys in the vault "allows them to be used across different browsers and operating systems." Microsoft says Entra ID accepts synced passkeys, names Apple iCloud Keychain and Google Password Manager as the built-in examples, and points to 1Password and Bitwarden as other passkey providers. Keeper is not named in Microsoft's docs, so that connection is our read rather than a vendor statement. Whether a Keeper passkey is accepted in a given tenant depends on that tenant's passkey settings.

Two settings decide it. Microsoft's own line is that synced passkeys do not support attestation, so where a passkey profile enforces attestation, a vault-held passkey cannot be registered at all. And a key restriction can allow or block a specific provider by its identifier, which can rule out one vendor while permitting another.

The question to ask yourself

Two questions about your own account. Which method signs you in: text code, app push, or passkey? Is it the most secure one available to you? That is the least an owner can do to protect their data.

Want to know which of your accounts are still enabled for text codes? Book a free strategy call or call (347) 273-1200.