<< Back to Blog
·18 min read

Passkeys Are Becoming the Default in Entra ID: What MSPs Need to Fix Before September

passkeys-are-becoming-entra-id-default.jpeg

Passkeys Are Becoming the Default in Entra ID: What MSPs Need to Fix Before September

Microsoft is about to start nudging SMS and voice users toward passkeys automatically. The security direction is right, but there are quite a few operational problems MSPs need to understand before September 1.

In This Article

TL;DR: What MSPs Need to Know

  • Retirement dates: Sept 1, 2026 - passkey push begins. Oct 1, 2026 - legacy Identity Protection risk policies retire. Feb 1, 2027 - Microsoft-provided SMS and voice authentication retires completely.
  • What changes: Users currently enabled for SMS or voice are automatically enabled for passkeys, and Microsoft's Registration Campaign starts prompting them to register during normal sign-in.
  • Who is affected: Every managed tenant with SMS or voice-enabled users, especially privileged accounts covered by Passkey Profiles.
  • Biggest risk: Passkey Profiles do not evaluate by "most restrictive wins." Overlapping profiles can let a privileged user register a weaker credential than intended.
  • What to do now: Audit the SMS and voice population, validate Passkey Profile targeting and group overlap, migrate legacy Identity Protection policies, document recovery, and test the real user experience - all before September 1.

Microsoft is now moving beyond simply making passkeys available. Starting September 1, 2026, users who are enabled for SMS or voice authentication will automatically be enabled for passkeys, and Microsoft's Registration Campaign will begin targeting those users for passkey registration during MFA sign-in. Microsoft-provided SMS and voice authentication then retires completely on February 1, 2027.

SMS authentication has had one foot in the grave for years, and getting users onto phishing-resistant credentials is objectively better security. The problem is that digging further into how Microsoft is implementing passkeys across Entra ID, Windows, Conditional Access, and Identity Protection makes it obvious that simply enabling the feature is not the same thing as being ready for it.

MSPs managing Microsoft 365 environments for clients have a few things to check now.

What Actually Changes on September 1

The September change matters because Microsoft is effectively starting the adoption process on the MSP's behalf.

If a user is currently enabled for SMS or voice, Microsoft can automatically enable them for passkeys. The Registration Campaign is also moving into a Microsoft Managed state targeting passkeys, which means users can begin seeing registration prompts as part of their normal authentication flow.

This approach makes sense from an adoption standpoint. If a new authentication method is simply enabled in the background with an email telling users to visit Security Info, a good percentage of those users will ignore it. Putting registration directly into a flow they already use is how Microsoft actually moves the needle.

The MSP problem is that the registration prompt can arrive before you have really thought through what type of passkey those users should be creating.

Microsoft Entra now supports synced passkeys through providers like Apple iCloud Keychain and Google Password Manager, device-bound passkeys in Microsoft Authenticator, FIDO2 hardware security keys, and Microsoft Entra passkeys stored directly in the Windows Hello container. They are all FIDO2 credentials, but they do not all have the same management and security properties.

Seeing "Passkey enabled" in an authentication policy is not enough confirmation on its own. MSPs need to know exactly which profile the user is receiving, whether synced credentials are allowed, whether attestation is required, and whether privileged accounts are separated from the rest of the organization.

Four operational gaps stand out. Each one looks fine in the Entra portal and breaks in practice.

Gap 1: The Passkey Profile Overlap Problem

This is the first configuration issue to check across tenants.

Microsoft allows different Passkey Profiles to be assigned to different groups. This is useful because it gives a clean way to separate standard users from administrators: standard users can get synced passkeys for convenience, while Global Administrators and other privileged users can be restricted to device-bound credentials.

The catch is how Microsoft evaluates overlapping profiles.

If a user is scoped to multiple Passkey Profiles, Entra does not automatically choose the most restrictive profile. Registration and authentication are allowed if the credential satisfies at least one of the profiles assigned to that user. There is no specific evaluation order where your "Admin Security" profile automatically wins because it is stricter.

Imagine you target All Users with a profile that permits synced passkeys. You then create another group for privileged administrators and assign that group a device-bound-only profile. Your Global Administrator is still a member of All Users, so they now effectively fall under both profiles.

If you assume the administrator profile overrides the general user profile, your policy design may not be doing what you think it is doing.

Critical: A Global Administrator who is also a member of All Users inherits both profiles. If All Users permits synced passkeys, that admin can register one, even though a separate device-bound-only profile also applies to their account.

Microsoft does treat exclusions differently. If a user is explicitly excluded from the Passkey FIDO2 policy, that exclusion wins and prevents registration and authentication entirely. But when dealing with multiple included profiles, you need to understand the group membership and design the assignments accordingly.

For MSPs standardizing this across tenants, this is one of those controls that needs to be evaluated programmatically. Looking at the names of the profiles in the portal is not enough; the actual group memberships need to be resolved to determine which profiles can apply to each privileged user.

This is the same failure mode we see across many "set it once" Entra controls. A baseline that looks correct in the portal and a baseline that is actually enforced across every tenant, for every included group, are two different things. If you are managing this across more than a handful of tenants, the group-membership resolution described above is not a one-time audit. It is something that needs to run continuously, because group membership changes and passkey profiles do not re-evaluate themselves.

Gap 2: Windows Hello for Business Confusion

Microsoft Entra passkeys on Windows are one of the newer additions to this story, and this is going to create quite a few support tickets.

Microsoft now allows a device-bound Entra passkey to be stored directly in the local Windows Hello container. The user can then authenticate to Entra using their face, fingerprint, or Windows Hello PIN. The important part is that Microsoft explicitly says this does not replace Windows Hello for Business. WHfB remains Microsoft's recommended solution for signing into managed Entra joined or registered corporate devices.

From an administrator's perspective, that distinction makes sense.

From the user's perspective, both experiences basically look like "I used my face or PIN."

Here is the important part: Microsoft documents that a user cannot register a Microsoft Entra passkey on Windows if a Windows Hello for Business credential already exists for the same account in the same Windows Hello container.

The user already signs in with Windows Hello. Microsoft prompts them to create a passkey. They choose the Windows option because it looks logical. Windows tells them they already have something registered, or registration fails. Then they call the helpdesk and say, "Microsoft told me to set this up, but it says I already did."

This is exactly the kind of issue that should be documented before the Registration Campaign starts putting the experience in front of users.

The Entra passkey on Windows is also device-bound and does not synchronize across devices. If a user has three Windows devices and wants an Entra passkey available on all three, each device requires a separate registration.

None of this is inherently bad. It just reinforces that Windows Hello for Business, an Entra passkey on Windows, a passkey inside Authenticator, and a synced passkey are different credentials even though the end-user experience can look almost identical.

Identity Protection Has to Change in a Passwordless World: This is probably the most interesting part of Microsoft's current authentication changes.

For years, the standard response to a high-risk user in Entra Identity Protection has been pretty straightforward: if Microsoft believes the account is compromised, require a secure password change.

That works for password-based compromise, but makes little sense once the user authenticates with a passkey.

Microsoft has introduced a Conditional Access grant control called Require risk remediation that is designed to handle this exact problem. Instead of assuming every compromised identity needs a password reset, Entra now adapts the remediation flow based on the authentication method.

For a password-based user, Microsoft can require strong authentication and then a secure password change. For a passwordless user, Microsoft revokes the user's sessions so they must authenticate again. When Require risk remediation is selected, Entra automatically applies an Authentication Strength requirement and sets Sign-in Frequency to Every time.

This direction is a meaningful shift, because it changes the remediation model from "change the password" to "remediate the identity." That is where identity security needs to go if we are serious about getting rid of passwords.

There is another reason MSPs should be looking at this now. Microsoft's legacy Identity Protection user risk and sign-in risk policies are retiring on October 1, 2026. Microsoft wants these controls migrated into Conditional Access.

MSPs are facing two major changes one month apart:

  • September 1: Microsoft starts pushing passkey adoption much harder.
  • October 1: Legacy Identity Protection risk policies retire.

If a tenant still has the old Identity Protection policies enabled, waiting until September to deal with them is not advisable. Move them into Conditional Access, put the replacements into Report-only first, validate the sign-in logs, and start testing Require risk remediation with the authentication methods the client's users actually use.

Gap 3: Passkey Lifecycle Rough Edges

Registration is always the exciting part of a new authentication technology. Deletion, recovery, device replacement, and identity changes are where you figure out whether the operational model is actually mature.

Passkeys still have some rough edges here.

Microsoft documents scenarios where a credential can remain on the user's device or inside their passkey provider after the corresponding authentication method has been removed from Entra ID. When that happens, the user may need to remove the local credential and register a new one before authentication works normally again.

That sounds like a small edge case until you think about it at MSP scale.

If 2 percent of users hit a weird registration issue in a 50-person tenant, you have one ticket. If you roll passkeys out across 10,000 managed users, that edge case becomes a helpdesk procedure.

This is the part many organizations miss when evaluating passwordless authentication. Registration is only one part of the lifecycle; deletion, replacement, recovery, and troubleshooting also need a documented process.

If you deal with acquisitions, company rebrands, domain changes, or tenant migrations, passkey behavior should also be part of your identity change checklist. Credentials that are tightly bound to an identity or device need to be considered whenever that identity changes.

Gap 4: Synced Passkeys and the Global Admin Visibility Problem

For standard users, synced passkeys make a lot of sense.

They solve one of the biggest operational problems with device-bound credentials because the user does not lose the credential just because they replace a phone or laptop. Microsoft says the recovery and reissuance benefits are one of the major reasons synced passkeys make sense for most ordinary users. Microsoft recommends device-bound credentials for administrators and highly privileged users, while using synced passkeys for non-admin users.

The reason to avoid them for privileged accounts is visibility.

Microsoft currently says administrators cannot see or control exactly which devices contain a synchronized copy of a passkey, and Entra cannot query where that credential has synchronized. That is not necessarily a Microsoft-specific flaw - it is part of the broader way synced passkey ecosystems work today.

For a normal user, that tradeoff is worth it.

For a Global Administrator, Privileged Role Administrator, Conditional Access Administrator, or another identity that can fundamentally alter the security posture of a tenant, a much tighter device boundary is warranted.

Give the standard workforce the convenient experience. Give privileged identities the high-assurance experience. This is exactly what Passkey Profiles should be used for, assuming the targeting is actually configured correctly.

There Are Going to Be Helpdesk Tickets

The technical limitations covered here do not mean Microsoft should slow down the move to passkeys. Quite the opposite: traditional MFA methods are still being phished every day, and moving users toward phishing-resistant authentication is one of the best improvements Microsoft can make to the default security posture of Entra ID.

But adoption rate matters just as much as technical capability.

If the registration experience is confusing, users will skip it until Microsoft makes it mandatory. If your helpdesk cannot explain why Windows Hello is not the same credential as an Entra passkey on Windows, users will think the feature is broken. If your Conditional Access design accidentally allows a privileged user to fall into a synced profile, you may have reduced the assurance level without realizing it.

Cross-device authentication is another one worth documenting. Using a passkey from another device depends on the supported cross-device authentication flow and typically uses Bluetooth proximity between the devices. That can become relevant in organizations where Bluetooth is restricted as part of the security baseline.

These are not reasons to avoid passkeys. They are reasons to test the actual end-user journey instead of validating a policy in the Entra portal and calling the rollout complete.

Three-Week Action Plan

Week 1: Audit

  • Find every tenant with active SMS or voice users, using Microsoft's guidance for identifying that population, before the Registration Campaign starts doing the communication.
  • Review Passkey Profile targeting: confirm standard users sit on an intentional profile, privileged users sit on an intentional high-assurance profile, and validate group overlap instead of assuming the stricter configuration wins.

Week 2: Migrate & Document

  • Migrate any legacy Identity Protection risk policies into Conditional Access before October 1.
  • For clients with Entra ID P2 or the appropriate Entra Suite licensing, configure Require risk remediation so the response to a compromised user makes sense whether that person authenticates with a password or a passkey.
  • Document recovery: what the helpdesk does when a user gets a new phone, what happens when a passkey exists locally but not in Entra, and how to bootstrap a new credential if a user has lost every phishing-resistant method they own.

Week 3: Test

  • Test the user experience on Windows, Android, iOS, and whatever browsers clients actually use. Do not build the deployment around what the Entra portal says should happen; test what the end user will actually see.

For one tenant, this is all manageable manually. For an MSP managing dozens or hundreds of tenants, this becomes a standardization problem: visibility is needed into which tenants still depend on SMS, which profiles are assigned, whether privileged users can register synced credentials, whether legacy Identity Protection policies still exist, and whether Conditional Access actually supports a passwordless user from registration through compromise and recovery.

That is the part MSPs need to get in front of before September. Multi-tenant M365 security management tools make it much easier to handle.

The Takeaway

Passkeys remain one of the best moves Microsoft has made for the default security posture of Entra ID.

A FIDO2 passkey beats SMS, push-based MFA, or a password almost every time. Microsoft moving millions of Entra users toward phishing-resistant authentication is a good thing, and retiring Microsoft-provided SMS and voice authentication is long overdue.

MSPs should not interpret Microsoft's September change as another checkbox that Microsoft is handling for them.

Passkeys are becoming part of the identity architecture now. They interact with Authentication Methods, Conditional Access, Identity Protection, Windows Hello for Business, mobile devices, recovery procedures, and privileged access. That means they need to be standardized and managed like any other security control.

Microsoft is going to start pushing the users. The MSP's job is to make sure the tenant is ready before they do.

With Optimize365, MSPs can check every managed tenant's SMS and voice population and Passkey Profile targeting in a single pass, instead of tenant by tenant, before the September 1 changes take effect. Check it out here.

Frequently Asked Questions

What changes in Entra ID on September 1, 2026? Users currently enabled for SMS or voice authentication are automatically enabled for passkeys, and Microsoft's Registration Campaign begins prompting them to register a passkey during normal MFA sign-in.

When does Microsoft-provided SMS and voice authentication retire completely? Microsoft-provided SMS and voice authentication retires completely on February 1, 2027.

Do Passkey Profiles automatically enforce the most restrictive policy for a user in multiple groups? No. If a user is scoped to multiple Passkey Profiles, Entra allows registration and authentication if the credential satisfies at least one assigned profile. There is no automatic evaluation order that favors the stricter profile.

Why can't a user register an Entra passkey on Windows if Windows Hello for Business is already configured? Microsoft does not allow a Microsoft Entra passkey on Windows to be registered if a Windows Hello for Business credential already exists for the same account in the same Windows Hello container.

Should MSPs use synced or device-bound passkeys for Global Administrators? Device-bound passkeys are recommended for Global Administrators and other privileged roles, because administrators cannot see or control which devices hold a synchronized copy of a passkey.

What happens to legacy Identity Protection risk policies on October 1, 2026? Microsoft retires the legacy Identity Protection user risk and sign-in risk policies on October 1, 2026. These need to be migrated into Conditional Access before that date.

What does the Require risk remediation control do? Require risk remediation is a Conditional Access grant control that adapts the remediation flow to the authentication method: password-based users are required to change their password, while passwordless users have their sessions revoked and must re-authenticate.