Microsoft Entra Passkeys Synced vs Device-Bound (Which Should You Actually Use?)

Microsoft Entra passkeys are no longer something you can quietly ignore and “come back to later”.

They are being pushed into tenants, surfaced during registration campaigns, and slowly becoming the direction Microsoft wants They are being surfaced more often in the platform, registration campaigns can bring them in front of users earlier than expected, and Microsoft is clearly positioning passkeys as a core part of its phishing-resistant authentication strategy.

Most of the content out there will tell you the same thing.

Passkeys are passwordless.
Passkeys are phishing-resistant.
Passkeys are the future.

All of that is true.

But none of it really helps when you are sat in your tenant thinking:

“Right… which one am I actually supposed to use?”

Because once you start testing properly, it becomes obvious very quickly that passkeys are not one single thing.

In Microsoft Entra, you need to think about synced passkeys, device-bound passkeys, passkeys in Microsoft Authenticator, and where Windows Hello for Business fits alongside them.

If you treat all of them as interchangeable, you can easily end up weakening your control model or creating unnecessary friction for users.

Sometimes both.

Never miss an article and subscribe, and don’t forget to check out my YouTube channel, Control Alt Delete Tech Bits

In the portal, you might need to click Upgrade to the new

So what’s the actual difference?

At a high level, it comes down to this.

Synced passkeys are designed to follow the user. Device-bound passkeys are designed to stay on one device.

A synced passkey lives inside a passkey provider such as Apple iCloud Keychain, Google Password Manager, or another supported provider. The credential is protected on the user’s device and then made available across other devices linked to that provider.

From the user’s point of view, it is very simple. They register once and then the same passkey experience can appear across their supported devices and browsers.

A device-bound passkey works differently. The private key is created and stored on a single physical device and does not leave it. In Microsoft Entra, that includes options such as FIDO2 security keys and passkeys stored in Microsoft Authenticator. On Windows, Microsoft also supports passkey scenarios that use Windows Hello for local verification.

Same destination. Different operating model.

This site and my YouTube channel are supported by Tech-Source.

Tech-Source is a UK-based technology supplier that works closely with IT teams across education, public sector, and commercial environments. They provide hardware, licensing, and infrastructure solutions, with a strong focus on practical advice rather than upselling.

Their support helps keep this site running and allows me to continue publishing in-depth, admin-focused content and walkthroughs without paywalls.

You can find out more about what they do at https://tech-source.co.uk/

Where people go wrong

The mistake I keep seeing is treating passkeys as if they are just another tenant-wide toggle.

Enable passkeys, job done.

That approach never really worked properly with MFA either, but with passkeys the gaps become obvious much faster.

Because the moment you introduce real users, real devices, personal phones, shared laptops, unmanaged endpoints, privileged accounts, and support teams, the question stops being “Should we enable passkeys?” and becomes “Which passkey model fits which user and which device?”

That is the bit that actually matters.

Let’s talk about BYOD first

If your users are signing in from personal devices, home PCs, unmanaged laptops, tablets, or the phone they already have in their pocket, then you are in BYOD territory whether you intended to be there or not.

This is where synced passkeys make a lot of sense.

They reduce friction heavily. A user sets up a passkey once and then uses it across supported devices without having to keep repeating the process on each endpoint. That makes adoption easier and support simpler.

For a lot of standard users, that convenience is exactly why synced passkeys are attractive.

But there is a trade-off.

You do not control the passkey provider, you do not control every recovery path around that provider, and you do not control where that credential may also be available if it is synced across the user’s personal ecosystem.

That does not make synced passkeys bad. It just means you need to be honest about what you are allowing.

In a BYOD scenario, synced passkeys are often the most practical option. They improve security compared with passwords, SMS, and weaker MFA methods, while keeping the user experience realistic enough that people will actually use them.

Now compare that to managed devices

Move into a well-managed environment and the picture changes.

Windows 11 devices. Intune-enrolled. BitLocker in place. Compliance policies working properly. Conditional Access already built around device trust.

This is where device-bound approaches fit much more naturally.

If the device is managed and you already care about the relationship between user identity, device state, compliance, and access to data, then keeping the credential tied to the device is usually a better match.

Device-bound passkeys reinforce that model rather than cutting across it.

This is also the point where it helps to be precise about terminology.

Windows Hello for Business is its own Microsoft authentication method and is listed separately by Microsoft from passkeys. It is not simply another label for synced or device-bound passkeys. But from a design point of view, it belongs in the same conversation because it gives you a phishing-resistant sign-in method strongly tied to the device and to local verification by PIN or biometrics.

So in a managed Windows environment, the sensible discussion is not just “passkeys or not”. It is whether you want synced passkeys for convenience, device-bound passkeys for tighter control, Windows Hello for Business for a strong device-centric experience, or a combination depending on the use case.

Synced passkeys will still work in many managed environments, but they can feel slightly out of place if your overall security model depends on strong device trust. You may have done all the work to lock down the endpoint and then allowed a sign-in credential that can also exist in a personal ecosystem you do not manage.

That is not automatically wrong, but it is a conscious design choice.

And then there are your admin accounts

This is the area where I would be more cautious.

If you are dealing with Global Administrators, Privileged Role Administrators, or any account with serious impact across the tenant, convenience should not be the deciding factor.

Microsoft’s own guidance leans towards stronger assurance options for elevated privilege scenarios, especially FIDO2 security keys. Microsoft also positions passkeys in Microsoft Authenticator as another option for those user groups.

That is an important distinction.

It would be too simplistic to say that synced passkeys are always banned for admins in every organisation. But it is fair to say they are usually not the first choice where you want stronger assurance, tighter hardware control, and fewer unknowns around credential portability and recovery paths.

For privileged accounts, device-bound passkeys and FIDO2 security keys are generally the safer fit.

This is also where attestation matters.

Microsoft states that synced passkeys do not support attestation. If you enforce attestation in a passkey profile, only device-bound passkeys are allowed.

That is a big deal.

If you care about verifying the make and model of the authenticator during registration, synced passkeys are immediately out of scope for that profile. For many standard users that may be fine. For privileged users, it often is not.

Where Conditional Access fits into all this

This is the part that quietly trips people up.

Passkeys help solve the authentication problem. They do not solve every other access problem around them.

A passkey can satisfy phishing-resistant MFA requirements, but it does not automatically prove that the device is compliant, that the endpoint is healthy, that the session is low risk, or that the credential is only available on devices you trust.

That is why Conditional Access still matters.

If you allow synced passkeys, you still need to think carefully about where those users are signing in from and what else you want to require. Device compliance, sign-in risk, user risk, application scope, and session controls still matter.

If you use device-bound passkeys in a managed environment, your authentication model and your device trust model usually line up more cleanly. The credential stays local, the device relationship is stronger, and the policy story is easier to reason about.

Passkeys improve your authentication posture. They do not replace access design.

The bit no one really talks about

Synced passkeys are convenient, but they blur the boundary between personal and corporate identity.

A work account credential may be available through a consumer cloud-backed passkey provider across devices you do not own or manage.

That does not automatically make it insecure. Microsoft still classifies synced passkeys as phishing-resistant, and they are still a major step up from passwords and weaker MFA methods.

But Microsoft also says synced passkeys should be treated with the same security posture as other unattested authenticators.

That is the nuance that often gets skipped.

So the real question is not “Are synced passkeys secure?”
They are.

The better question is “Are synced passkeys the right fit for this user, this device, and this assurance level?”

That is the design question most tenants need to answer.

How I’d approach this in a real tenant

I would not try to force one model everywhere.

For standard users, especially those moving between devices or working in a hybrid or BYOD setup, synced passkeys are often the most practical choice. They reduce friction, improve the sign-in experience, and give you a clear security uplift over passwords and phishable MFA.

For managed corporate endpoints, I would favour device-bound options and Windows Hello for Business where they fit the operating model. That keeps identity, device trust, and access policy aligned.

For privileged users, I would use the strictest option that makes sense for the organisation. In many cases that means FIDO2 security keys, or other device-bound methods with stronger assurance and tighter control.

The point is not to declare one winner.

The point is to use the right option in the right place.

That is exactly why Microsoft now supports passkey profiles.

Passkey profiles let you apply different requirements to different groups, including passkey type, attestation settings, and restrictions based on authenticator AAGUID. That means you do not need one flat policy for everyone. You can design for different user populations properly.

And that is how this should be approached.

Not as a blanket switch.

As a policy decision.

Where to configure and test this

If you want to see all of this in action in your own tenant, start here:

Entra ID > Security > Authentication methods > Policies > Passkey (FIDO2)

That is where you enable passkey profiles, choose whether self-service setup is allowed, and define whether groups can use device-bound passkeys, synced passkeys, or both.

You should also review registration campaigns if you are planning rollout and user adoption, because that is often where passkeys start appearing to users earlier than expected.

And once you begin testing sign-ins, check the sign-in logs carefully. That is where you can validate how users are authenticating and whether your intended controls are working in practice.

Do not just enable the feature and assume the design is sound.

Test the registration flow.
Test the sign-in flow.
Test BYOD.
Test managed Windows devices.
Test privileged accounts separately.
Test what happens when you enforce attestation.
Test what your users actually experience.

That is where the real answers appear.

Microsoft Entra passkeys are a genuine improvement

They remove a lot of the weaknesses that came with passwords, SMS, and other phishable authentication methods.

But they also introduce meaningful design choices.

If you treat synced and device-bound passkeys as if they are the same thing, you lose the ability to shape authentication in a way that matches your environment.

If you understand where each model fits, and you build your policies around that, you end up with something far more balanced.

Better security where it matters.
Better usability where it helps.
And fewer surprises later.

Microsoft Entra passkeys are a genuine improvement. They remove a lot of the problems that passwords and weaker MFA methods introduced.

But they also introduce choice, and that’s where things get interesting.

If you treat synced and device-bound passkeys as the same thing, you lose the ability to control how identity behaves in your environment.

If you understand where each one fits, you end up with something far more balanced.

Better security where it matters, and a smoother experience everywhere else.

You might also like this article