Microsoft Entra ID is now actively moving users away from Microsoft-provided SMS and voice authentication toward phishing-resistant authentication methods such as passkeys.
Since September 1, 2026, users who are enabled for SMS or voice authentication have started being automatically enabled for passkeys and brought into the passkey registration campaign. When those users sign in and complete MFA, they may now see a prompt asking them to register a passkey.
For most IT administrators, this means the passkey conversation is no longer only about how to enable passkeys.
We also need to understand the actual registration experience our users will see.
That becomes especially important for users who have never used Microsoft Authenticator and have always relied on:
Password + SMS OTP or: Password + Voice MFA
There is another important detail as well.
When the user starts passkey registration from a browser such as Microsoft Edge, the browser and Windows can present different places where the new passkey can be saved.
If the user simply accepts the default option without understanding it, the passkey may end up in a different credential provider than the organization expected.
That is the part I want to focus on in this Blog.
Why SMS and Voice Users Are Suddenly Seeing Passkey Registration
Starting September 1, 2026, users enabled for SMS or voice in the Authentication Methods Policy or legacy MFA configuration are automatically brought into scope for passkeys.
When those users next sign in and complete MFA, the registration campaign can prompt them to create a passkey. By default, the current registration prompt can still be snoozed.
This is an important change for organizations that still have a large SMS or voice population.
The current experience might look like:
Username + Password → SMS OTP / Voice →Passkey registration nudge →Create a passkey
At this point, many users will simply click Continue.
But that is exactly where administrators should pay attention.
This Is Not Just About Clicking “Create a Passkey”
A passkey needs to be stored somewhere.
Depending on the device, browser and credential providers available to the user, that passkey could be stored in places such as:
- Microsoft Password Manager
- Windows Hello
- Microsoft Authenticator
- An Android phone
- An iPhone or iPad
- A physical FIDO2 security key
- Another supported password/passkey manager
The user therefore needs to understand which passkey type your organization actually wants them to register.
This becomes particularly visible when registration starts from Microsoft Edge on Windows.
What Users May See in Microsoft Edge
If the user continues the passkey registration flow from Microsoft Edge, the operating system or browser may present a passkey creation dialog with a suggested save location.
In environments where Microsoft Password Manager is available, that may be the suggested option.
For example, if Microsoft Password Manager is selected, the passkey is saved there.
Microsoft Password Manager supports synced passkeys and integrates with the Windows passkey provider model. Edge can save new passkeys to its built-in password manager when this capability is enabled.
That may be exactly what you want. Or it may not be.
Users Need to Know Where They Are Saving the Passkey
This is one of the most important things to include in user communication.
A user might think:
“I am registering a Microsoft Authenticator passkey.”
But if they are completing the generic browser WebAuthn flow and simply accept the browser's suggested credential provider, the credential might actually be stored in Microsoft Password Manager rather than Microsoft Authenticator.
Those are not the same deployment model. This doesn't mean one is automatically better than the other.
It simply means the administrator needs to decide which experience is intended.
If your organization's objective is: Microsoft Authenticator device-bound passkeys
then users should be guided toward that specific credential provider.
If your organization allows: synced passkeys in Microsoft Password Manager
then accepting that option may be completely valid.
The problem starts when neither the admin nor the user knows which one has been selected.
Look for “Save Another Way”
If the suggested location isn't where you want the passkey to be stored, don't simply continue.
The registration experience provides an option such as: Save another way
or, depending on the platform and dialog:
Change
Selecting this presents the other passkey providers available to the user.
The available options might include:
Password Manager, Windows Hello or external security key (Windows device / Windows Hello, iPhone, iPad or Android device, Security key)
The exact experience depends on the operating system, browser and passkey providers installed or enabled on that endpoint.
Choosing a Mobile Device
If the user wants the passkey to be created on their phone rather than in the browser's password manager, they can select:
iPhone, iPad or Android device
The user scans the QR code using their phone and continues the WebAuthn flow on that device.
Bluetooth and internet connectivity are typically involved to establish proximity and complete the registration securely.
Once Bluetooth is connected to the Windows device, the user will see a prompt in the Microsoft Authenticator app to create a passkey for their account.
Once the passkey is successfully saved in Microsoft Authenticator, the user can see it listed in the Authenticator app. The user will also be prompted to name the passkey, making it easier to identify later on the Security info page.
The private key isn't being transferred over Bluetooth between the devices.
The phone is participating as the authenticator in the WebAuthn ceremony.
The user can now view the passkey registered to their account by navigating to the My Security Info page.
Where Microsoft Authenticator Fits Into This
If the goal is specifically to create a Microsoft Authenticator device-bound passkey, the cleanest experience for existing Authenticator users is still to create it directly through Microsoft Authenticator.
But there are users who cannot easily do that.
For example:
- They have never signed in to Microsoft Authenticator.
- They currently use only SMS or voice MFA.
- They cannot complete Authenticator registration because of the way Conditional Access is configured.
- They are being guided through the registration campaign from Security info.
For those users, there is an alternative WebAuthn path from Security info.
Registering an Authenticator Passkey from Security Info
From Security info, the user can select:
Add sign-in method →Passkey in Microsoft Authenticator
During that registration experience, there is an option:
Having trouble followed by: Create your passkey a different way
Once the user selects Android, the following screen will appear. Follow the on-screen instructions, then select Next to continue.
Once you select Next, another screen will appear asking you to confirm Bluetooth connectivity. Make sure Bluetooth is turned on for both your Windows device and your mobile phone.
Read the instructions shown on the screen, and once both devices are ready, select I’m ready to continue with the passkey creation process in the Microsoft Authenticator app on your mobile device.
The browser will now redirect to the Setting up your passkey screen. A Windows Security prompt will then appear asking where you want to save the passkey.
At this stage, carefully check the selected save location. Even if you selected Android or iOS in the previous step, Windows may still default to This Windows device.
To save the passkey on your mobile device instead, select Change and choose the appropriate option before continuing.
In the next Windows Security prompt, select iPhone, iPad, or Android device to continue with saving the passkey on your mobile device.
A QR code will now appear on the screen. Scan this QR code using your mobile device to continue creating and saving the passkey on your phone.
Once the QR code is scanned successfully, you will be prompted to provide a name for the passkey so that it can be easily identified later.
After the registration is completed, the browser will display a Passkey created confirmation. Select Done to return to the Security info page, where the newly created passkey will appear in the list with the name you provided.
This method is particularly useful for a user who has never used Authenticator previously but is now being moved away from SMS or voice authentication.
The Important Difference Between the Two Web Experiences
Generic Passkey Registration
If the user chooses:
Passkey from Security info or follows a general browser WebAuthn registration prompt, they may be able to choose among different credential providers.
For example:
- Microsoft Password Manager
- Windows Hello
- Mobile device
- Security key
The passkey is stored wherever the user selects.
Passkey in Microsoft Authenticator
If the objective is specifically an Authenticator passkey, start with:
Passkey in Microsoft Authenticator
and follow the Authenticator-specific registration path.
If the normal Authenticator sign-in cannot be completed:
Having trouble →Create your passkey a different way → Android / iPhone
This has to be clearly explained to your help desk and users.
Otherwise someone can successfully create a passkey and still end up with a different passkey provider than the deployment team expected.
Microsoft Password Manager Is Not Microsoft Authenticator
This point deserves its own section. Microsoft Password Manager and Microsoft Authenticator are separate credential stores.
A passkey saved in: Microsoft Password Manager is not the same thing as a:
Microsoft Authenticator device-bound passkey
Microsoft Password Manager supports synced passkeys, while Authenticator device-bound passkeys follow a different credential model.
Both can use FIDO2/WebAuthn.
Both can provide phishing-resistant authentication when used in supported scenarios.
But their storage, synchronization and lifecycle behavior are different.
So when a user sees Microsoft Password Manager during registration, don't assume that choosing it will create an Authenticator passkey.
It won't.
This Will Matter More as the SMS/Voice Retirement Gets Closer
The current registration nudge is only the beginning.
For most users, Microsoft-provided SMS and voice authentication is scheduled to retire on February 1, 2027.
Global Administrators and external users currently follow a later date of July 1, 2027. Internal guest users remain in the February 1 scope.
After the applicable retirement date, users whose only remaining MFA method is Microsoft-provided SMS or voice will no longer be able to simply continue signing in that way.
If no customer-managed telecommunications provider has been configured for them, users whose only available MFA method is SMS or voice will be required to register a passkey before continuing.
At that stage, the passkey registration prompt becomes blocking rather than something the user can simply postpone.
That makes user education around the registration experience even more important.
The Migration Experience I Expect Many Organizations to See
A common user journey will look something like this:
Today
Password → SMS OTP → Access application
During the migration period
Password → SMS OTP → Passkey registration nudge → Passkey creation wizard → Choose where the passkey should be stored → Complete registration
After migration
Passkey → Phishing-resistant sign-in
The important new step is: Choose where the passkey should be stored.
That decision shouldn't be left entirely to chance.
What About Intune App Protection?
There is another scenario where the WebAuthn option can become useful.
Organizations frequently deploy mobile access using Intune App Protection Policies.
However, simply assigning an App Protection Policy doesn't automatically block passkey registration.
The important part is the associated Conditional Access grant control.
For example:
Target resources: All resources
with:
Require app protection policy
can interfere with the Authenticator registration experience because Microsoft Authenticator does not satisfy those particular grant controls on Android or iOS.
So avoid saying:
MAM blocks passkey registration.
That would be too broad.
The actual troubleshooting question should be:
Which Conditional Access grant controls are being evaluated during the Authenticator registration flow?
WebAuthn Does Not Bypass Conditional Access
Using the WebAuthn registration path doesn't mean Conditional Access is being bypassed.
Policies protecting: Register security information continue to apply.
For example, if your organization requires:
MFA, a particular authentication strength, a compliant device
or another grant control while registering authentication methods, the user still needs to satisfy that policy.
WebAuthn changes how the credential is created. It doesn't remove your Entra security controls.
One Important Limitation: Attestation
If your Authenticator passkey profile requires attestation, the alternative WebAuthn registration path for Authenticator isn't available.
In that situation, the Authenticator passkey needs to be registered through the supported direct Authenticator experience.
So before designing your user communication, first decide:
Are we requiring attested Authenticator passkeys?
If yes, your onboarding instructions need to reflect that.
Cross-Device Registration Requirements
If Security info is open on one device and the passkey is being created on a phone, make sure you test the network path.
For Authenticator's cross-device registration flow, the environment needs internet connectivity and Bluetooth, and the documented endpoints include:
cable.ua5v.comcable.auth.com
If these are blocked or interfered with by enterprise network controls, registration can fail even though the Entra configuration itself is correct.
This is worth testing before launching a large registration campaign.
What I Would Tell End Users
The user communication doesn't need to explain FIDO2, WebAuthn or AAGUIDs.
Keep it simple:
When you are prompted to create your passkey, check where the passkey will be saved before selecting Continue.
If the displayed location isn't the passkey provider recommended by your organization, select Save another way and choose the required device or provider.
That one instruction can prevent a lot of confusion.
What IT Administrators Should Decide Before the Rollout
Before allowing the registration campaign to reach thousands of users, answer a few questions internally.
Which passkey types do we support?
Do we want:
- Authenticator device-bound passkeys?
- Windows Hello/Windows device passkeys?
- Microsoft Password Manager synced passkeys?
- Third-party synced passkeys?
- FIDO2 security keys?
or a combination of them?
Also decide whether your Authentication Methods Policy allows all passkey types or whether you are restricting specific passkey providers.
Once that is clear, the registration guidance becomes much easier.
My Recommended Pilot Scenarios
I would test the rollout with users representing the actual production population.
| Scenario | What to Validate |
|---|---|
| SMS-only user | Passkey registration nudge |
| Voice-only user | Passkey registration nudge |
| Edge on Windows | Suggested passkey provider |
| Microsoft Password Manager enabled | Where the passkey is stored |
| Save another way | Alternative credential providers |
| Windows Hello | Local device passkey |
| Android device | Cross-device WebAuthn |
| iPhone | Cross-device WebAuthn |
| Existing Authenticator user | Direct Authenticator passkey |
| No existing Authenticator account | Security info WebAuthn flow |
| BYOD + MAM | Conditional Access behavior |
| Compliant device | Registration security requirements |
| Attestation enabled | Direct Authenticator registration requirement |
| Restricted corporate network | Bluetooth and WebAuthn connectivity |
Final Thoughts
As Microsoft moves users away from SMS and voice authentication, more users will start seeing passkey registration prompts. The important part is not just creating the passkey, but understanding where it is being saved.
If Edge presents Microsoft Password Manager by default, users should verify that this matches the organization’s intended passkey deployment. If not, they can choose Save another way and select the required device or passkey provider.
For users who cannot complete the normal Authenticator registration flow, the Security info + WebAuthn option provides another useful registration path.
Before rolling this out broadly, test the complete user experience and make sure your user guidance clearly explains which passkey option they should choose.
0 Comments