Ask ten endpoint engineers which Windows Hello for Business (WHfB) trust model their fleet runs, and most will tell you what was deployed, not what a given device is actually using right now. Those are not always the same thing - a half-finished migration, a leftover Group Policy Object (GPO), or a precedence rule can quietly put a device on a different model than you think. And if you troubleshoot the wrong model, you will chase a certificate problem that does not exist while the real cause - a missing partial ticket-granting ticket (TGT) - sits untouched.
This guide does two things. First, it explains the three trust models in plain terms so you know what each one is doing under the hood. Second - and this is the part nobody writes down - it gives you the exact commands and registry values that prove which model a device is on, instead of guessing.
The problem: three trust models, and you cannot say which one a device runs
Ask ten engineers which Windows Hello for Business (WHfB) trust model their fleet uses and most will tell you what was deployed, not what a given device is actually running right now. A half-finished migration, a leftover Group Policy Object, or a precedence rule can quietly put a device on a different model than you think - and if you troubleshoot the wrong model, you chase a certificate problem that does not exist while the real cause sits untouched.
Why it happens: three models that behave differently
Every WHfB deployment has to turn a passwordless sign-in into a Kerberos ticket your domain controllers (DCs) will accept. The "trust type" is just how it does that. Here is the whole landscape:
| Certificate trust | Key trust | Cloud Kerberos trust | |
|---|---|---|---|
| On-prem credential | X.509 certificate in the user's store | Raw public key, used via PKINIT | Partial TGT minted by Microsoft Entra ID |
| Where the key/cert lives | Cert:\CurrentUser\My (Passport KSP) | msDS-KeyCredentialLink on the AD user | msDS-KeyCredentialLink (still synced) but not used for the ticket |
| Extra infrastructure | AD FS + enterprise CA + registration authority | Enterprise PKI (DC certs for PKINIT) | None - just the AzureADKerberos object |
| DC requirement | Trusts the issuing CA chain | DC KDC certificate + reads msDS-KeyCredentialLink | Windows Server 2016+ patched; reads AzureADKerberos |
| Entra Connect key sync needed | Yes | Yes (this is what writes the key to AD) | No |
| Best for | Legacy / RDP certificate needs | Can't deploy Entra Kerberos | Almost everyone (Microsoft's recommendation) |
The single biggest practical difference: certificate trust and key trust both need a PKI you own and maintain. Cloud Kerberos trust needs none. That is why it is the default recommendation and why the other two are, increasingly, legacy.
How to verify: prove which model a device is on
Now the useful part. There are three signals, and you read them in order.
Signal 1 - Is there a WHfB certificate in the user store?
A certificate answers the question immediately: only certificate trust puts a usable logon certificate in the user's Personal store. But you must not mistake the self-issued Microsoft Entra device-registration certificate for a WHfB one. A genuine WHfB certificate-trust logon cert has three traits together: its private key is in the Microsoft Passport Key Storage Provider, it carries a Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) or Client Authentication EKU, and it is issued by your enterprise CA (Issuer is not equal to Subject).
Signal 2 - Which on-prem policy is set?
Policy tells you what the device has been told to do. Two values in the PassportForWork policy tree decide it:
UsePassportForWork = 1, and neither special policy set means key trust; the same picture plus UseCloudTrustForOnPremAuth = 1 means cloud trust. The cloud-trust registry value is the tiebreaker. If it is absent and there is no WHfB cert, you are on key trust.Signal 3 - The definitive server-side check
The client can be misconfigured; the directory cannot lie. For cloud trust, confirm the AzureADKerberos object exists and its key versions match:
For key trust, confirm the user actually has a key written to Active Directory. If msDS-KeyCredentialLink is empty, key-trust sign-in cannot work - the DC has nothing to validate against:
The fix: choose the right model
If you are planning a new deployment or a migration, the answer is short:
- Cloud Kerberos trust - choose this unless you have a specific reason not to. No PKI, no AD FS, fastest to stand up, and it is where Microsoft is investing.
- Key trust - only if you genuinely cannot deploy Microsoft Entra Kerberos (for example, an isolated forest with no Entra Connect path) but still have an enterprise PKI.
- Certificate trust - only if you have a hard requirement that needs a real certificate, such as certain Remote Desktop Protocol (RDP) sign-in scenarios. Otherwise it is the model to migrate away from.
msDS-KeyCredentialLink via Entra Connect - even cloud Kerberos trust, which does not use it for the ticket. So the presence of a key in that attribute does not by itself prove key trust. Read it together with the policy values, not alone.Proof it worked: you can state the model with evidence
You have done this correctly when, for any device, you can name its trust model and back it with a concrete signal: a WHfB certificate in the user store (certificate trust), UseCloudTrustForOnPremAuth = 1 plus a partial TGT (cloud Kerberos trust), or a populated msDS-KeyCredentialLink with neither of those policies (key trust). "I checked" beats "I assume" every time.
References
- Plan a Windows Hello for Business deployment (trust types)
- Windows Hello for Business authentication technical deep dive
- Windows Hello for Business policy settings
- Troubleshoot devices by using the dsregcmd command
Script for this post is in Daily-Tasks.