The phishing-resistant credential is no longer a single thing you deploy. It is a small portfolio, and the useful way to hold it in your head is along one axis: some credentials are bound to a device and some travel with the person. A well-run estate gives most people one of each, and in the current year every option on both sides has reached general availability, which turns the question from whether to whether-which.
This is the fifth article in the Entra ID series. The previous one described how the platform now steers users toward their strongest registered credential. This one is about the credentials at the top of that ranking, what distinguishes them, and how to choose deliberately rather than by accident.
Local and portable
Every phishing-resistant credential is a key pair where the private key never leaves the place it was created, and the only question that really separates them is where that place is. A local credential is bound to one device: Windows Hello for Business bound to a PC’s hardware, or the platform credential bound to a Mac’s secure enclave. It signs you into that machine and carries single sign-on from there, and it cannot follow you to a different one. A portable credential travels with the person instead of the device: a FIDO2 security key you carry, a synced passkey that rides your platform account across your devices, or a passkey held in an authenticator app. It authenticates you to applications and services from whatever you are sitting at.
Neither axis is better; they answer different questions. The local credential is the natural sign-in for the managed device someone uses every day, and the endpoint series covered its flagship, Windows Hello for Business, in its own family of articles. The portable credential is what gets a person into a service from a machine that is not theirs, or provides the second, independent method that survives a lost or reset device. The design goal for most users is one of each, so that the everyday sign-in is frictionless and there is always a second phishing-resistant path that does not depend on a single piece of hardware.
Some credentials are bound to a device and some travel with the person. Most people should hold one of each.
Passkeys are general now, on every surface
The portable side of the portfolio grew up this year. Synced passkeys, the kind that ride your Apple, Google, or Microsoft account across your devices, reached general availability alongside device-bound passkeys in March 2026. Their convenience carries one design consequence worth stating: synced passkeys do not support attestation, the cryptographic proof of exactly which authenticator model produced a key, so a tenant that enforces attestation will simply refuse to register them. Whether you enforce attestation is therefore a real fork. Turn it on and you can insist on specific, vetted security-key models but you lock out the synced passkeys most users already have. Leave it off and you get broad, low-friction passkey adoption at the cost of that hardware assurance. Most organizations moving toward passwordless at scale choose reach over attestation, but it should be a decision, not a default you discovered later.
Those passkey profiles are worth understanding, because they are the mechanism that sits behind the next point. A profile is how you allow or block specific authenticator models by their identifier, and a tenant can maintain up to three of them today, including the default profile, with support for more in development. Even three is enough to accept one set of passkeys for one population and a different set for another, and, as the next section shows, to block a particular authenticator entirely.
The Windows passkey to keep an eye on
The one development that demands a deliberate decision, rather than just awareness, is Microsoft Entra passkeys on Windows, which entered public preview in 2026 and is not yet generally available. It lets a user register a device-bound passkey into the local Windows Hello container and use it to sign in to Entra, even on machines that are not joined or registered to your tenant. It does not replace Windows Hello for Business; the two are complementary, and where a Hello for Business credential already exists for an account, it takes precedence for that container. The reason to track it now is that its behavior is governed entirely through the passkey profile. During the preview the Windows Hello authenticators are identified by a set of known identifiers, and whether your users can register these passkeys turns on whether those identifiers are allowed or blocked in your profile, which is the same profile mechanism from a moment ago. If users begin seeing unexpected Windows Hello passkey prompts in their browsers, the lever is that profile, not anything on the endpoint. As with synced passkeys, attestation is not supported here, so enforcing attestation and expecting Windows passkeys to work are mutually exclusive.
How Conditional Access actually consumes all this
All of these credentials exist to satisfy one control, and it is worth being precise about its contents. The built-in phishing-resistant authentication strength contains exactly three things: Windows Hello for Business or the platform credential, the FIDO2 security key or passkey, and Entra certificate-based authentication at multifactor strength. When a policy in the Conditional Access framework demands phishing-resistant authentication, one of those three is what satisfies it, and the portfolio in this article is simply the set of ways a real user meets that bar.
One behavior of that strength catches people out and belongs in every design that uses it. The strength is evaluated against the method the user actually authenticated with, and it does not step a session up in place. A user who signed in with a password and an approved push, then hits a resource requiring phishing-resistant strength, is not smoothly prompted to switch; they reach a wall and must restart the session and choose a phishing-resistant method. Apply the strength to a flow where password-primary sign-in is still common and you have designed a dead end. This is the practical reason the registration-first sequencing from the previous article matters so much: the strength only feels seamless when the strong credential is already registered and already preferred.
Designing the portfolio
The shape I recommend is deliberately simple. Give each person on a managed device a local credential, Windows Hello for Business or the platform equivalent, as their everyday sign-in. Give each person a portable credential too, a passkey or a security key, so there is a second phishing-resistant path that does not die with a single device and works from machines they do not own. Reserve certificate-based authentication for the populations that genuinely need a certificate. Make the attestation decision consciously, knowing it trades reach against hardware assurance, and make the Windows-passkey posture decision consciously, blocking the authenticator identifiers if you do not want that experience surfacing. Bootstrap all of it with Temporary Access Passes so nobody has to touch a password to register their first strong credential.
Do that and the phishing-resistant requirement stops being a hurdle and becomes the path of least resistance, which is the whole point. The credentials are in place, the system prefers them, and the control that demands them is satisfied without anyone reaching for a password. With authentication settled, the series turns next to what the platform does when a sign-in looks wrong despite a strong credential, which is the domain of identity risk.
Entra ID
‹ Previous: [E 4] Authentication Methods and the Road to Passwordless
Next: [E 6] Identity Protection: Risk as a Signal ›
