Don’t Burn the Steak: Entra Passkeys, Shared PCs, and Phishing-Resistant Access

There is a big difference between testing something in the backyard and serving it at the party.

In the backyard, you can burn the steak, adjust the heat, question your life choices, and quietly pretend the smoke was part of the plan. At the party, people expect the steak to show up plated, rested, and not resembling a hockey puck.

That is also how I think about rolling out authentication changes.

Microsoft Entra passkeys on Windows are moving into general availability, with rollout beginning in late April 2026 and expected to complete by mid-June 2026 for Worldwide tenants, according to MC1282568. The same announcement also calls out support for corporate-managed, personal, and shared Windows devices, with controls through Authentication Methods policies and Conditional Access. (MC1282568)

While this is exciting, it is also the kind of thing I want to test in the backyard before I serve it to production.

In this post, I want to walk through a practical scenario: using Microsoft Entra passkeys on Windows with Intune Shared PC mode, then using Conditional Access to require phishing-resistant MFA for access to Entra-protected apps.

The goal is not to build a full Shared PC walkthrough. Microsoft already has documentation for that. The goal is to show how the identity, device, and session pieces come together so you can start testing the pattern without burning the steak in front of everyone.

Why Shared PC Mode Is the Perfect Fit

Picture a shared Windows device used by multiple workers throughout the day.

Maria signs in and uses Outlook, Teams, or another Entra-protected app. Later, Bob needs to use the same device. Neither user should rely on shared passwords. Neither user should be able to casually inherit the other person’s app session. Access to sensitive resources should require a phishing-resistant method.

That is where this gets interesting.

Microsoft Entra passkeys on Windows let users register FIDO2 passkeys directly into the local Windows Hello container and use Windows Hello methods such as PIN, fingerprint, or facial recognition for Microsoft Entra authentication. Microsoft’s documentation also notes that the Windows device does not need to be Microsoft Entra joined or registered to use a local Windows passkey, and that a single Windows PC can store passkeys for multiple Microsoft Entra accounts. (Microsoft documentation)

That makes shared Windows scenarios worth testing.

Important detail: this does not replace Windows Hello for Business for managed corporate devices. Important detail: this does not replace Windows Hello for Business for managed corporate devices. Microsoft still positions Windows Hello for Business as the recommended option for managed, Microsoft Entra joined or registered devices. Entra passkeys on Windows are FIDO2 passkeys for Entra authentication, stored in the local Windows Hello container, and they do not support Windows device sign-in.

So, think of it this way:

Windows Hello for Business helps with signing in to managed Windows devices.
Microsoft Entra passkeys on Windows help with phishing-resistant sign-in to Entra-protected resources.
Conditional Access decides when that stronger authentication is required.
Shared PC mode helps shape the shared-device experience.

Those are different burners on the grill. Mixing them up is how the steak gets crispy.

Why Passkeys Matter Here

Passwords are portable. That is convenient for users and attackers.

Passkeys are different. In a FIDO2 flow, Microsoft Entra sends a challenge to the authenticator, the authenticator signs that challenge with the private key after the user completes a biometric or PIN gesture, and Microsoft Entra verifies the response using the public key. The private key is not sent to Microsoft Entra.

That is the security win.

For this scenario, the user registers a passkey into the local Windows Hello container. When Conditional Access requires phishing-resistant MFA, the user can satisfy the requirement with that passkey, assuming your Authentication Methods and Conditional Access policies allow it.

This is especially useful when the device model is shared, temporary, or not as clean as the traditional “one user, one corporate laptop” pattern.

However, convenience does not remove the need for guardrails.

The Setup

I am skipping the Shared PC mode setup walkthrough in this post because it is a topic worth its own dedicated coverage. Microsoft’s Control access, accounts, and power features on shared PC or multi-user devices doc is a great reference. Assume from here that you have an Entra-joined Windows device with an Intune Shared multi-user device profile assigned.

Step 1: Create Your Passkey Profile

Sign into the Microsoft Entra admin center as an Authentication Policy Administrator and browse to:

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

If passkey profiles auto-migrated into your tenant (per MC1221452, this rollout runs from early April through late May 2026), you should already have a Default passkey profile. If not, look for the banner towards the top.

For Windows Hello passkeys to work, the profile needs:

Setting	Value
Passkey type	Device-bound (allowed)
Enforce attestation	No
Key restrictions	Either disabled, or enabled with Windows Hello AAGUIDs in the allow list. Once this feature is GA, you will no longer be required to enter the AAGUIDs.

Still on the Passkey (FIDO2) method, go to the Enable and target tab. Add the group containing your shared PC users to the assignment. Set the method to Enabled for that scope.

Step 2: Register the passkey on the shared Windows device

Once the user is in scope, they can register the passkey from their Security info page.

For a shared Windows device, each user should register their own passkey. Microsoft’s documentation notes that passkeys on Windows are device-bound and not synced across devices, meaning each Windows device requires separate passkey registration for each Entra account.

A User signs in to the shared device with Entra credentials.
Once at desktop, open your browser and navigate to aka.ms/mfasetup
Add sign-in method, and then select Passkey.

Notice that the passkey is saved to the Windows device.

Name the passkey for easy reference.

At this point, the steak may smell pretty good, but we still need to make sure the grill is actually under control.

Step 3: Use Conditional Access for enforcement

Enabling passkeys gives users the method.

Conditional Access decides when the method is required.

For sensitive apps, the policy pattern is usually:

Include the pilot users (I used the same group I used for the Authentication Methods in Entra).
Target the required cloud apps or resources.
Conditions – Device Filter if you wanted to limit it to only Shared Devices
Grant access.
Require authentication strength.
Select Phishing-resistant MFA strength.
Report only if you wanted to test further.

Then the user experience when signing in to Office.

Common Gotchas

A few things worth knowing that the docs bury or that caught me during lab testing.

Attestation Is Still Not Supported at GA

Mentioned this earlier, saying it again because it is the number-one reason registration fails. Attestation remains unsupported for Windows Hello passkeys even at GA. Any passkey profile with Enforce attestation = Yes will reject Windows Hello registration attempts. Flag this for your security team ahead of time so “Enforce attestation = No” does not read like a regression to them.

First-Time Registration Slows Down First-Time Visits

Each user’s first sign-in to a shared PC takes longer because they are setting up Windows Hello for the first time on that device and registering a passkey. Communicate this to your user pool so they are not surprised. Once the passkey exists, subsequent visits are fast.

Device-Bound With No Sync

The passkey is bound to that specific shared PC for that specific user profile. If Maria uses a different shared PC tomorrow, she registers a new passkey on that one. Seven nurses on three shared workstations means each nurse registers on each station they actually use. That is by design (it is the security boundary), however worth communicating in your rollout plan.

Profile Deletion Timing

Shared PC mode supports several DeletionPolicy values. Delete immediately at sign-out gives you the cleanest handoff but means each first-time-on-device user pays the full registration cost. Delete at disk space threshold keeps profiles cached so subsequent visits are faster, however it leaves data on the device longer. Pick the one that fits your security posture, then test the actual behavior because the real-world experience differs noticeably between the two.

Passkey Profiles Auto-Migration

Separate from the Windows passkeys story, your tenant may be auto-migrating into the passkey profiles schema per MC1221452 if you never opted in manually. Worldwide auto-enablement runs from early April to late May 2026. Your existing settings get preserved in a Default passkey profile, which then becomes the profile that either enables or blocks Windows Hello passkeys depending on its configuration. One more reason to audit your profiles this week.

Wrapping up

Microsoft Entra passkeys on Windows are a meaningful step forward for phishing-resistant access. They make it possible to use Windows Hello as the local gesture for a FIDO2 passkey stored on the Windows device. They can work on devices that are not Microsoft Entra joined or registered. They can support shared Windows scenarios where multiple users need access to Entra-protected resources from the same PC.

That is powerful. Still, the success of this rollout is not just about turning on passkeys.

You need the right passkey profile, scoped to the right users. You need Conditional Access authentication strength to enforce phishing-resistant MFA where it matters. You need Shared PC mode to support the shared-device model. You need lock-on-idle to reduce unattended session risk. Most importantly, you need lab validation before production.

Burn the steak in the backyard.

Adjust the heat.

Take notes.

Then serve the clean experience at the party.