Somewhere around Phase 8, this series started treating phishing-resistant credentials as a given. The Conditional Access framework requires them for administrators, prefers them everywhere else, and quietly assumes that every managed Windows device already carries one. This is the article that pays off that assumption. Windows Hello for Business is the credential the framework was built around, and it deserves the same architectural treatment as everything it protects.
The password did not get stronger. It left.
Most of what we call authentication hardening is decoration on the same flawed object. A password is a symmetric secret: the same string that lives in your user’s head also lives, in some derived form, on a server, and it travels between the two every time they sign in. Everything that makes passwords dangerous follows from that. They can be phished because they can be typed into the wrong place. They can be replayed because they are the same everywhere. Adding MFA on top narrows the window without changing the shape.
Windows Hello for Business changes the shape. During provisioning, the device generates an asymmetric key pair, bound to the TPM where one is available. The public key is registered against the user’s account in Entra ID. The private key never leaves the device. It cannot be exported, it is never transmitted, and the identity provider never sees it. Authentication becomes a signing ceremony: Entra issues a challenge, the device signs it with the private key, and Entra verifies the signature against the registered public key. There is no shared secret on the wire and nothing on the server worth stealing. A credential that only exists inside one TPM cannot be phished from a lookalike login page, because there is nothing the user knows that would be worth typing there.
That is the entire trick, and it is worth stating plainly because the branding invites confusion. Windows Hello for Business is not “a PIN instead of a password.” It is a device-bound key pair instead of a shared secret, with a PIN as one way of unlocking it.
What the PIN actually does
The objection I hear most often from executives and sceptical engineers alike is that a six-digit PIN sounds weaker than a fourteen-character password. It sounds weaker because we have been trained to evaluate credentials by their entropy. But the PIN is not the credential, and it never travels. It is local entropy used to unlock the key container on that one device.
The mechanics matter for anyone defending this design in a security review. Each gesture, whether PIN, fingerprint, or face, has its own protector key. The protector key wraps an authentication key, and the authentication key in turn releases the user’s private key for signing. When a TPM is present, the PIN protector performs a TPM seal operation using the PIN as entropy, which means guessing attempts run into the TPM’s anti-hammering behavior rather than an offline cracking rig. The correct verb everywhere in this chain is unlocks, not decrypts a stored password, because there is no stored password. Steal the PIN without the device and you have four to six digits of trivia. Steal the device without the PIN and you have a lockout.
Two boundary facts complete the picture. The PIN is mandatory: biometrics are a convenience layer on top of it, never a replacement, and you cannot provision Windows Hello for Business without one. And this is not the consumer convenience PIN that Windows has offered for years. The convenience PIN unlocks a cached password and inherits every weakness the password had. Microsoft’s own guidance is that new deployments should be Windows Hello for Business and never convenience PINs, and I treat any tenant still allowing convenience PINs as carrying quiet technical debt.
Steal the PIN without the device and you have six digits of trivia. Steal the device without the PIN and you have a lockout.
The trust decision you may not need to make
Open any deployment guide and you will meet the three trust models: cloud Kerberos trust, key trust, certificate trust. Here is the framing that cuts through them. The trust model governs exactly one thing, which is how the Hello credential authenticates to on-premises Active Directory. It has nothing to do with authenticating to Entra ID. That always works the same way, key against registered key, regardless of which trust model you pick or whether you pick one at all.
Which means the first question is not “which trust model” but “do I still have Active Directory in the picture.” A genuinely cloud-only tenant, with no on-prem AD and no synced identities, selects no trust model. The documentation lists trust type as not applicable for that deployment, and the credential simply registers to Entra ID and works. An Entra-joined estate that still carries AD behind it, with identities synced and file servers or Kerberos applications still in production, uses cloud Kerberos trust. That is Microsoft’s recommended model over key trust and the preferred model unless you have a hard requirement for certificate scenarios, and it earns that position by needing no PKI, no key synchronization back to AD, and none of key trust’s provisioning delay. It is enough of a subject that it gets its own article in this family.
Certificate trust deserves one honest paragraph. It is not deprecated, and it is not less secure. It is the model you accept when something in your environment demands an actual user certificate, most commonly RDP with supplied credentials or an entrenched certificate-authenticated VPN, and it charges you the heaviest infrastructure bill of the three: an enterprise PKI, certificates on domain controllers, and a certificate registration authority on AD FS. Treat it as a requirement-driven exception, not a preference. And do not plan to drift between models later; moving from certificate trust to cloud Kerberos trust is a redeployment of Hello, not a toggle.
Where this sits in 2026
Windows Hello for Business is one of exactly three methods inside the built-in phishing-resistant authentication strength in Conditional Access, alongside FIDO2 security keys and multifactor certificate-based authentication. When the framework in this series requires phishing-resistant credentials for privileged access, this is the credential most users will actually satisfy it with. One operational nuance is worth carrying into your design: authentication strengths do not step a session up. A user who signed in with a password and a push approval will not be prompted to switch to Hello mid-session when a policy demands it; they hit a wall and must restart the session and choose a different sign-in method. If you apply a phishing-resistant strength to a flow where password-primary sign-in is still common, you have designed a dead end, and your help desk will find it before you do.
The other thing that changed this spring is passkeys. Microsoft Entra passkeys on Windows reached general availability between late April and mid June of this year, and they let a user register a device-bound FIDO2 passkey into the local Windows Hello container on machines that are not Entra-joined or even registered. These are complementary credentials, not competitors. Hello for Business is the credential of the managed, single-user corporate device: it signs you into Windows itself and carries single sign-on from there. The Entra passkey on Windows is application and web sign-in for the machines you do not manage. A user with a provisioned Hello credential cannot register an Entra passkey for the same account in that container, because Hello takes precedence there.
The part that demands a decision is the default. At general availability, Microsoft inverted the rollout control: wherever the passkey authentication method is enabled, Windows Hello passkey registration is now available by default, and tenants that do not want it must explicitly block the three Windows Hello authenticator AAGUIDs in the passkey policy. If users in your tenant have started seeing unexpected Windows Hello passkey dialogs in their browsers, that inversion is why. Decide your posture deliberately, in the authentication methods policy, rather than discovering it in tickets.
The boundaries
The design assumes one person per device. The credential is generated per user, per machine, and everything about it, from the TPM binding to the gesture, presumes the person unlocking it is the person it was provisioned for. Shared workstations, kiosks, and any device where signing in as yourself is not the norm belong outside the deployment, excluded by filter rather than by hope. Local accounts are not supported at all. None of this is a limitation to engineer around; it is the design telling you where it belongs.
What remains is the part where most deployments actually go wrong, and it has nothing to do with cryptography. Turning this on for an estate is a rollout problem, there is a tenant-wide switch that looks like the obvious answer, and it is the wrong one. That decision gets the next article to itself.
Intune Deployment Guide · Phase 2: Identity and Tenant Foundation
‹ Previous: [2.4] Conditional Access Prerequisites: What Must Be True First
Next: [2.5.1] Rolling Out Windows Hello for Business: Rings, Not Switches ›
