This series:
Part 1 - SMS and voice MFA is ending: lock down your passkey profiles first
Part 2 - Who is actually ready?
Part 3 - Enforcing the right passkey at sign-in
Part 4 - The people problem (you are here)

In short: Some staff will refuse to install an app on a personal phone, and some do not have a smartphone at all. Until now the answer was a text message. From February 2027 it is not. This part gives an option for every type of user, sample acceptable usage policy wording, and a communication plan, and finishes with a rollout checklist for the whole series.

Parts 1 to 3 covered the technical controls. In my experience, the technology is rarely what delays an authentication change. People are.

Three groups that will push back

• BYOD users who refuse Authenticator. Many organisations run a mix of corporate and personal devices. A BYOD user can reasonably say: “I am not installing a work app on my personal phone - buy me a phone.” Until now, the answer was SMS or voice.
• Users without a smartphone. Some staff do not have one, or have a phone that cannot run current Authenticator. Again, the old answer was SMS or a voice call.
• Shared and frontline workers. Staff who share a device, or have no device at all during a shift.

From 1 February 2027, that old answer is gone. A user whose only method is SMS or voice meets a blocking passkey registration prompt, and there is no opt-out.

The nudge is already running

In the Contoso tenant, the registration campaign was already set to Microsoft managed, targeting Passkey (FIDO2) for All users. By default users can snooze it as many times as they like - so a user who does not want to engage can keep putting it off until the blocking prompt arrives.

Do not wait for that. Target the SmsVoiceOnly group from Part 2 with communications now, so the first conversation happens on your timeline, not at the login screen.

An option for every user

User	Option	Passkey profile
Corporate phone	Microsoft Authenticator passkey	Microsoft Authenticator - All users
BYOD, willing	Microsoft Authenticator passkey (in an Intune-managed work profile where possible)	Microsoft Authenticator - All users
BYOD refusal or no smartphone	FIDO2 hardware security key issued by the organisation	A third profile for the key model, assigned to a dedicated group
Desk-based, single Windows device	Windows Hello for Business	Not a passkey profile - covered by its own method policy
Tier 0	YubiKey 5 NFC from a PAW	YubiKey 5 NFC - Privileged access
Onboarding and recovery	Temporary Access Pass to register the long-term method	Not applicable

A FIDO2 hardware security key turns “buy me a phone” into “here is your key”. It costs a fraction of a handset, needs no app, and is a stronger credential than the SMS code it replaces. Use the same pattern as Part 1: a profile restricted to the key model you issue, assigned to a group such as Contoso-MFA-SecurityKeyUsers.

What about keeping SMS?

Organisations with a documented regulatory or operational need can configure a third-party telephony provider from the Microsoft Security Store. The initial providers were Soprano and Telesign. Microsoft’s own guidance is to use passkeys for every user segment and reserve telephony for documented exceptions - and that is the right default. Paying a third party to keep a phishable method alive should be the exception that needs sign-off, not the easy way out.

Update the acceptable usage policy

The most effective change is often not technical. Update the acceptable usage policy so the position is clear before anyone asks. Two points make it land:

• Access to Contoso’s Microsoft 365 tenant, and other SaaS services that use Entra ID sign-in, requires a phishing-resistant method issued or approved by Contoso.
• The change is driven by Microsoft retiring SMS and voice across the platform. It is outside Contoso’s control, and it is not a policy choice IT can reverse for an individual.

Sample wording:

“Access to Contoso’s Microsoft 365 services and other cloud services that use Contoso sign-in requires a phishing-resistant authentication method: a Microsoft Authenticator passkey on a supported mobile device, or a FIDO2 hardware security key issued by Contoso. SMS text messages and voice calls are no longer accepted, following Microsoft’s retirement of these methods across its platform. Staff who cannot or prefer not to use a mobile device will be issued a FIDO2 hardware security key on request.”

Communicate in three waves

1. Awareness - what is changing, when, and why. Make clear it is a Microsoft platform change.
2. Action - device-specific instructions: Authenticator on Android, Authenticator on iOS, and how to request a FIDO2 hardware security key.
3. Reminder - targeted at whoever is still in the SmsVoiceOnly bucket, with a date.

Microsoft publishes end-user communication templates at aka.ms/mfatemplates as a starting point.

Rollout checklist

The series explains the controls in the order that makes them easiest to understand. In production, roll them out in this order:

Step	Part	Action
1	2	Run the readiness report, load the buckets into groups and re-run weekly
2	4	Update the acceptable usage policy, start communications and issue FIDO2 hardware security keys to those who need them
3	1	Create the Authenticator and YubiKey passkey profiles and assign the YubiKey profile to Tier 0
4	1	Move All users off the Default passkey profile once the report shows no one would be locked out
5	3	Enforce the YubiKey for Tier 0 with a custom authentication strength and Conditional Access, report-only first

Done in that order, 1 February 2027 is just another day for Contoso users rather than a wave of blocked sign-ins.

References

• Microsoft Learn - SMS and voice retirement in Microsoft Entra ID
• Microsoft Learn - Choose a telephony provider for SMS and voice authentication
• Microsoft Learn - Registration campaign (nudge) for authentication methods
• Microsoft - MFA end-user communication templates (aka.ms/mfatemplates)

This series:
Part 1 - SMS and voice MFA is ending: lock down your passkey profiles first
Part 2 - Who is actually ready?
Part 3 - Enforcing the right passkey at sign-in (you are here)
Part 4 - The people problem

In short: Part 1 decided which passkeys people may set up. That alone does not stop a Tier 0 administrator signing in with their phone instead of their YubiKey. This part adds a Conditional Access rule that only accepts the YubiKey for those administrators, tested in report-only mode before it is switched on.

Part 1 ended with an uncomfortable fact. Passkey profiles are a union: a Tier 0 admin in both All users and _PIM Tier 0 can register either an Authenticator passkey or a YubiKey, and excluding them from the passkey method removes passkeys altogether. Profiles decide what can be registered. To decide what must be used, you need Conditional Access.

Why the built-in strengths are not enough

Entra ID ships three built-in authentication strengths: Multifactor authentication, Passwordless MFA and Phishing-resistant MFA.

Phishing-resistant MFA is a good baseline for admins, but it is satisfied by any passkey the user can register - including the Authenticator passkey the All users profile allows. For Tier 0, Contoso wants one thing: a YubiKey 5 NFC. That needs a custom strength.

Build the custom authentication strength

Go to Entra ID > Authentication methods > Authentication strengths > New authentication strength.

1. Name it Tier 0 - YubiKey 5 NFC only. The description field is capped at 100 characters, so keep it short.
2. Under Phishing-resistant MFA, tick Passkeys (FIDO2) only. Leave every other method unticked.

3. Select Advanced options under Passkeys (FIDO2). You can tick Microsoft Authenticator or Windows Hello as providers, or add AAGUIDs. Add the same three YubiKey 5 NFC AAGUIDs used in the Part 1 passkey profile.

4. Review and create. The review page confirms that during sign-in the user must use a passkey matching one of the listed AAGUIDs.

Keep the two lists in step. The AAGUIDs in the authentication strength must match the AAGUIDs in the passkey profile. If a new YubiKey firmware generation arrives with a new AAGUID, add it to both - otherwise users can register a key they cannot sign in with, or the reverse.

A tenant can hold up to 15 custom authentication strengths. Advanced passkey options are not supported for external users whose home tenant is in a different Microsoft cloud.

Create the Conditional Access policy

Go to Conditional Access > Policies > New policy and create it in Report-only first.

Setting	Value
Name	CA010 - Tier 0 - Require YubiKey 5 NFC authentication strength
Users	Include: _PIM Tier 0. Exclude: break-glass (emergency access) accounts
Target resources	All resources (formerly All cloud apps)
Grant	Grant access - Require authentication strength: Tier 0 - YubiKey 5 NFC only
Enable policy	Report-only

The new strength appears in the Require authentication strength drop-down alongside the built-in ones. Note that the portal will not let you combine Require authentication strength with Require multifactor authentication in the same policy.

From report-only to on

1. Make sure every Tier 0 admin has registered a YubiKey under the Part 1 profile. A Temporary Access Pass is the cleanest way to bootstrap that registration.
2. Leave the policy in Report-only for at least a week and review the Report-only results in the sign-in logs for _PIM Tier 0 members.
3. Any sign-in that would have failed is a Tier 0 admin still using Authenticator, a password or another key. Fix those first.
4. Switch the policy to On.

Once enforced, a Tier 0 admin who tries another passkey sees “You can’t get there from here” and has to restart the session and sign in with the YubiKey.

Protect the registration itself

Passkey profiles and authentication strengths both assume the person registering the passkey is the real user. Close the obvious gap - an attacker with a phished password and SMS code registering their own Authenticator - with a second Conditional Access policy on the Register security information user action.

Setting	Value
Name	CA011 - All users - Secure security information registration
Users	Include: All users. Exclude: break-glass accounts and guests
Target resources	User actions: Register security information
Conditions	Locations: any location, excluding Contoso trusted locations
Grant	Require multifactor authentication, or require a compliant device

New starters with nothing registered yet use a Temporary Access Pass issued by the service desk, which satisfies the MFA requirement for their first registration. The result: a new passkey can only be added from a trusted location or device, or by someone who already holds a strong method.

Going further for Tier 0

• PIM activation. Rather than requiring the YubiKey for every resource, you can tie it to role activation: create an authentication context, target it with this strength, and require that context on activation in the PIM role settings.
• Privileged Access Workstations. Add a device condition so Tier 0 sign-ins are only allowed from compliant PAW devices. The YubiKey proves who the admin is; the PAW proves where they are working from.

Next in the series

Both Conditional Access policies are in place. Part 4 deals with the hardest part of any authentication change: the people who say no.

References

• Microsoft Learn - Custom authentication strengths and advanced options for passkeys (FIDO2)
• Microsoft Learn - Conditional Access: require authentication strength
• Microsoft Learn - Enable passkeys (FIDO2) and passkey profiles in Microsoft Entra ID

This series:
Part 1 - SMS and voice MFA is ending: lock down your passkey profiles first
Part 2 - Who is actually ready? (you are here)
Part 3 - Enforcing the right passkey at sign-in
Part 4 - The people problem

In short: Before changing any sign-in settings, find out what each user has actually set up. This part shows the built-in Entra ID reports, why they are not enough on their own, and two free scripts that sort every user into a readiness group - from “ready” to “will be locked out in February 2027” - and turn those groups into action lists.

In Part 1, Contoso replaced the loose Default passkey profile with an Authenticator profile for all users and a YubiKey profile for Tier 0. In a production tenant, this report comes first: you need to know where every user stands before moving anyone off the Default profile. Otherwise the first anyone hears of a problem is a user who cannot sign in.

Start with the headline number

Entra ID > Authentication methods > Activity gives you the headline. In the Contoso tenant, 2 of 34 users were MFA capable and 0 were passwordless capable.

That is a useful number for a steering group. It does not tell you who to contact or what each of them needs.

Microsoft’s analyser checks policy, not people

Microsoft has published a PowerShell script for the retirement, Get-SmsVoicePolicyUsers.ps1 (github.com/microsoft/entra-sms-voice-usage-analyzer). It is worth running, but be clear about what it does. It reads the SMS and Voice method policy scope, the registration campaign state and the migration state, and exports the targeted groups and users to CSV.

It is a policy scope scanner, not a user inventory. It does not expand group membership, check registered methods or read sign-in activity. It tells you who SMS and voice are enabled for, not who depends on them.

User registration details

Entra ID > Authentication methods > User registration details is the per-user view. Each row shows whether the user is MFA capable, passwordless capable and SSPR capable, their default MFA method and every method they have registered. It can be filtered and downloaded as CSV.

The Methods registered filter now separates Passkey (Microsoft Authenticator) from other passkeys, which is exactly the distinction the profiles in Part 1 depend on.

Why I built my own readiness scripts

Before Microsoft Graph, the quickest way to see each user’s methods was the MSOnline PowerShell module. With MSOnline retired, the community has filled the gap - AdminDroid’s free Export MFA Status Report script (published in the admindroid-community/powershell-scripts repository on GitHub) is a good example. In client reports I have generated, per-user reports like this have consistently surfaced users who have never registered Microsoft Authenticator - often users whose only method is a mobile phone number. Those are the users who will hit the blocking prompt in February 2027.

Generic MFA reports answer the question “does this user have MFA?”. For this migration the question is different: “will this user still be able to sign in once SMS and voice are gone and the restrictive passkey profiles from Part 1 apply?”. That needs the AAGUID of every registered passkey, checked against the profiles you plan to deploy - so I wrote two scripts for it, published in the cloud-secure-ai GitHub repository.

Script	What it does
Get-PasskeyReadiness.ps1	Read-only. Reads every user’s registered methods, including passkey models and AAGUIDs, and places each user in one readiness bucket. Exports a CSV and a console summary.
Sync-PasskeyReadinessGroups.ps1	Creates one security group per bucket and keeps membership up to date. Supports -WhatIf.

The readiness buckets

Bucket	Meaning and action
SmsVoiceOnly	Only phone-based MFA registered. Blocked from 1 February 2027. Highest priority.
PasskeyOutsideAllow	Has a passkey whose AAGUID is not on your allow list - for example a synced passkey. It stops working when the Default profile is retired.
PrivilegedNoHardwareKey	Member of the Tier 0 group without an approved FIDO2 hardware security key. Fix before switching on the Part 3 policy.
NoAuthenticator	Has MFA, but no Microsoft Authenticator and no allowed passkey.
NotMfaCapable	No MFA method registered at all.
Ready	Microsoft Authenticator or an allowed passkey registered.

Running the report

The script reads each user’s authentication methods directly, so the passkey AAGUIDs come back in the same call and it does not depend on Microsoft Entra ID P1 reporting. Phone numbers are masked to the last four digits, and nothing is written to the tenant. The allow lists match the Contoso profiles from Part 1:

$authenticator = 'de1e552d-db1d-4423-a619-566b625cdc84',   # Authenticator for Android
                 '90a3ccdf-635c-4729-a248-9b709135078f'    # Authenticator for iOS
$yubiKey5Nfc   = 'fa2b99dc-9e39-4257-8f92-4a30d23c4118',   # YubiKey 5 NFC 5.1
                 '2fc0579f-8113-47ea-b116-bb5a8db9202a',   # YubiKey 5 NFC 5.2/5.4
                 'a25342c0-3cdc-4414-8e46-f4807fca511c'    # YubiKey 5 NFC 5.7

.\Get-PasskeyReadiness.ps1 -AllowedAaguids ($authenticator + $yubiKey5Nfc) `
    -PrivilegedGroupId '<_PIM Tier 0 group object ID>' -PrivilegedAaguids $yubiKey5Nfc `
    -LicensedUsersOnly -EnabledUsersOnly

The output is a timestamped CSV and a summary by bucket. For scheduled runs, the script also supports certificate-based app authentication.

Requirements

• Microsoft Graph PowerShell SDK
• Get-PasskeyReadiness.ps1: User.Read.All, UserAuthenticationMethod.Read.All and GroupMember.Read.All
• Sync-PasskeyReadinessGroups.ps1: Group.ReadWrite.All and GroupMember.ReadWrite.All

Turn the report into groups

A report is only useful if it drives action. Sync-PasskeyReadinessGroups.ps1 loads each bucket into its own security group. Run it with -WhatIf first to see what it would create:

.\Sync-PasskeyReadinessGroups.ps1 -CsvPath .\PasskeyReadiness_<timestamp>.csv -GroupPrefix 'Contoso-MFA-' -WhatIf
.\Sync-PasskeyReadinessGroups.ps1 -CsvPath .\PasskeyReadiness_<timestamp>.csv -GroupPrefix 'Contoso-MFA-' -RemoveStale

• Contoso-MFA-SmsVoiceOnly - targeted first by the registration campaign and communications (Part 4)
• Contoso-MFA-PasskeyOutsideAllow - contacted before the Default profile is retired, so they can register an allowed passkey
• Contoso-MFA-PrivilegedNoHardwareKey - issued a YubiKey before the Part 3 policy is switched on
• Contoso-MFA-NoAuthenticator - targeted by the Authenticator registration campaign

Re-run both scripts weekly. With -RemoveStale, users drop out of a group as soon as they fix their registration, so the groups always reflect who still needs help. When SmsVoiceOnly and PasskeyOutsideAllow reach zero, retiring the Default passkey profile is a non-event.

Next in the series

Part 3 returns to the question left open in Part 1: if profiles are a union, how do you make sure Tier 0 admins actually sign in with their YubiKey? The answer is a Conditional Access authentication strength.

References

• Microsoft Learn - SMS and voice retirement in Microsoft Entra ID
• GitHub - microsoft/entra-sms-voice-usage-analyzer
• Microsoft Learn - userRegistrationDetails resource type (Microsoft Graph)
• AdminDroid community - Export MFA Status Report using MS Graph: github.com/admindroid-community/powershell-scripts/blob/master/Export%20MFA%20Status%20Report%20using%20MS%20Graph/GetMFAStatusReport.ps1
• GitHub - cloud-secure-ai/entra-passkey-readiness (Get-PasskeyReadiness.ps1 and Sync-PasskeyReadinessGroups.ps1) - github.com/cloud-secure-ai/entra-passkey-readiness

This series:
Part 1 - SMS and voice MFA is ending: lock down your passkey profiles first (you are here)
Part 2 - Who is actually ready?
Part 3 - Enforcing the right passkey at sign-in
Part 4 - The people problem

In short: Microsoft is switching off SMS text and voice call sign-in codes for Microsoft 365. Users are being moved to passkeys, but the default settings accept almost any passkey, including ones stored in personal Google or Apple accounts. This part shows how Contoso restricts that to Microsoft Authenticator for everyone and a YubiKey hardware key for its most privileged administrators.

Why SMS and voice are going

A code sent by text message or read out in a phone call proves very little. An attacker can trick a user into typing it into a fake sign-in page, or take over the phone number with a SIM swap. A passkey works differently: it is a cryptographic key held on the user’s phone or on a hardware key, it only works on the genuine Microsoft sign-in page, and there is nothing for the user to read out or type in. That is why passkeys are described as phishing-resistant.

Key terms used in this series

Term	Meaning
Passkey	A sign-in credential stored on a phone, computer or hardware key, unlocked with a PIN, fingerprint or face. Replaces passwords and one-time codes.
Device-bound passkey	Stays on one device or hardware key and cannot be copied. Microsoft Authenticator and YubiKeys hold device-bound passkeys.
Synced passkey	Copied between a user’s devices through a personal cloud account such as Google Password Manager or iCloud Keychain.
AAGUID	A model identifier every passkey provider reports, for example “Microsoft Authenticator for iOS” or “YubiKey 5 NFC”. It is how Entra ID tells one type of passkey from another.
Attestation	Proof, signed by the manufacturer, that the passkey really comes from the model it claims. Without it, the AAGUID is taken on trust.
Passkey profile	A set of Entra ID rules for which passkeys a group of users may register.
Tier 0	The most privileged administrators - those who can control the whole tenant. At Contoso their roles are managed with Privileged Identity Management (PIM) and they work from a Privileged Access Workstation (PAW), a locked-down device used only for admin work.
Conditional Access	Entra ID’s rules engine for sign-ins: who, from where, to what, and with which method.

The hard stop is coming

Microsoft has been signalling the end of SMS and voice as authentication methods for some time. That signal now has dates attached, and the first one has already passed.

• 1 September 2026 - passkeys became the default authentication experience in Microsoft Entra ID. Every user enabled for SMS or voice was automatically enabled for passkeys and is nudged to register one at their next MFA sign-in.
• 1 February 2027 - Microsoft-provided SMS and voice is retired for all users except Global Administrators and external users. After this date, a user whose only MFA method is SMS or voice must register a passkey before they can continue signing in. The prompt is blocking and there is no opt-out.
• 1 July 2027 - the same retirement and blocking prompt apply to Global Administrators and external users.

There is a temporary opt-out from the automatic passkey enablement, set through Microsoft Graph, but it only covers the September 2026 to February 2027 window. It does not stop the retirement or the enforcement. Organisations with a genuine regulatory or operational need for SMS or voice will have to bring a third-party telephony provider from the Microsoft Security Store - the new Add telecom profile option on the Authentication methods blade is where that lives.

What Microsoft does for you - and why that is not enough

If your tenant still has SMS or voice users, you will find a locked, system-managed row in the Passkey (FIDO2) policy: All SMS/Voice Users, assigned the SMS/voice user Passkeys profile. It is enabled by the system and cannot be turned off from the policy.

Getting SMS and voice users onto passkeys is the right outcome. The problem is which passkeys. When passkey profiles were rolled out, existing settings were migrated into the Default passkey profile. In the Contoso tenant, that profile had no attestation, allowed both device-bound and synced passkeys, and had no key restrictions. In practice, any passkey provider a user chooses - Google Password Manager, iCloud Keychain, Samsung Pass or anything else - is acceptable.

Synced passkeys are phishing-resistant, but they live in a consumer account Contoso does not manage. The passkey that unlocks Microsoft 365 should be one Contoso can identify and control.

The design: two profiles, two populations

Passkey profiles let you set different rules for different groups. The Contoso design uses two:

• Microsoft Authenticator - All users: attestation enforced, device-bound only, restricted to the Microsoft Authenticator for Android and iOS AAGUIDs. Assigned to All users for full coverage.
• YubiKey 5 NFC (USB-A) - Privileged access: attestation enforced, device-bound only, restricted to the YubiKey 5 NFC AAGUIDs. Assigned to the _PIM Tier 0 security group, in line with a Zero Trust privileged access model where Tier 0 identities authenticate from a Privileged Access Workstation with a hardware key.

Building the YubiKey profile

In the Microsoft Entra admin centre, go to Entra ID > Authentication methods > Policies > Passkey (FIDO2) > Configure > Add profile.

Two behaviours in the portal are worth knowing before you start. First, once Enforce attestation is ticked, the only passkey type offered is Device-bound - synced passkeys do not support attestation.

Second, when you tick Target specific AAGUIDs, the Behaviour defaults to Block, not Allow. Leave it on Block and you have built a block list. For an allow-list profile, change it to Allow before adding AAGUIDs.

Add AAGUID gives three choices: Windows Hello, Microsoft Authenticator (which adds both the Android and iOS AAGUIDs) and Enter AAGUID for anything else.

A YubiKey model does not have a single AAGUID. It changes with firmware generation, and YubiKey firmware cannot be upgraded, so keys bought in different years report different values. To cover every YubiKey 5 NFC (USB-A) Contoso might issue, the profile includes:

• fa2b99dc-9e39-4257-8f92-4a30d23c4118 - firmware 5.1
• 2fc0579f-8113-47ea-b116-bb5a8db9202a - firmware 5.2 and 5.4
• a25342c0-3cdc-4414-8e46-f4807fca511c - firmware 5.7

Building the Authenticator profile

Repeat the process with the Microsoft Authenticator shortcut. The portal adds the Android and iOS AAGUIDs and shows them by name rather than as GUIDs.

Assigning the profiles

On the Enable and target tab, change the All users target from Default passkey profile to Microsoft Authenticator - All users, then add _PIM Tier 0 as a target and assign it the YubiKey profile. The Default passkey profile cannot be deleted or renamed, but it no longer needs to be assigned.

Can’t anyone just install Authenticator?

A fair challenge to this design: if the profile allows Microsoft Authenticator, any iOS or Android user can install the app, so what has been locked down? The answer is that the profile controls the type of passkey, not the phone it sits on - and that is exactly what it is meant to do.

• The passkey cannot leave the device. An Authenticator passkey is device-bound and attested. It is not copied to a Google or Apple account, and it cannot be exported or shared. A synced passkey in a personal password manager can be, which is what the Default profile allowed.
• Installing the app proves nothing on its own. Registering a passkey is itself an authenticated action: the user must already pass MFA to add one. The real risk is an attacker who has phished a password and an SMS code registering their own Authenticator. Part 3 closes that gap with a Conditional Access policy on security information registration.
• Contoso can see and revoke it. Every Authenticator passkey appears against the user with its model, and the Part 2 report lists them. A lost phone is a single method to remove.

If Contoso wants passkeys only on company-managed phones, that is a device control rather than a passkey control - Intune compliance or app protection in Conditional Access - and it sits on top of this design rather than replacing it.

Does All users override the Tier 0 assignment?

No - and this is the point most likely to catch people out. Profiles are not evaluated in order, and none takes precedence. When a user is scoped into more than one profile, a passkey is allowed if it fully satisfies at least one of them. A Tier 0 admin who is in both All users and _PIM Tier 0 can therefore register either a YubiKey or an Authenticator passkey.

Excluding _PIM Tier 0 does not help either. The Exclude tab applies to the whole Passkey (FIDO2) method and takes precedence over every include, so excluded users lose passkeys entirely - YubiKey included.

Keep All users for full coverage. Passkey profiles control what can be registered. Conditional Access controls what must be used. Requiring the YubiKey for Tier 0 at sign-in is the subject of Part 3.

Before you change your own tenant

Recommended rollout order. This series is written in the order that best explains the controls, not the order to deploy them. In production: (1) report on what users have registered (Part 2); (2) start communications and offer an option to every user (Part 4); (3) create both profiles and assign the YubiKey profile to Tier 0; (4) move All users off the Default profile only when the Part 2 report shows nobody would be locked out; (5) enforce the YubiKey for Tier 0 with Conditional Access, report-only first (Part 3).

• Key restrictions apply to sign-in as well as registration. Moving All users off the Default profile means any passkey registered under it that does not match the new profile - a synced passkey, or another vendor’s security key - stops working. Report on what is registered first. Part 2 covers how.
• Attestation is checked at registration only. Enforcing it later does not invalidate passkeys registered without it.
• Profile limits. The portal states that up to 10 passkey profiles are supported.
• The system-managed SMS/voice target is outside your control. Moving those users off SMS and voice deliberately, rather than waiting for the February 2027 cut-off, is what puts them under your profiles.

Next in the series

Part 2 looks at the starting point: how to report on registered authentication methods per user, find who still relies on SMS or voice, and who has a passkey that will stop working once the Default profile is retired.

References

• Microsoft Learn - SMS and voice retirement in Microsoft Entra ID
• Microsoft Learn - Enable passkeys (FIDO2) and passkey profiles in Microsoft Entra ID
• Microsoft Security blog - Passkeys are the default authentication method in Entra ID (13 July 2026)
• Message Centre MC1221452 - General availability of passkey profiles (mc.merill.net)
• Yubico - YubiKey hardware FIDO2 AAGUIDs