Migrating Windows Hello for Business From Certificate Trust to Cloud Kerberos Trust (and Retiring NDES)

Certificate trust was the right answer in 2017. It is not the right answer now. If your Windows Hello for Business (WHfB) deployment still enrols a certificate into the Hello container and leans on Active Directory Federation Services (AD FS) plus an enterprise certificate authority (CA) to issue it, you are running more infrastructure than the modern cloud Kerberos trust model needs — and every one of those moving parts is something that expires, breaks, or gets attacked.

This guide is the migration brief. We will explain why there is no in-place upgrade from certificate trust to cloud Kerberos trust, walk the safe phased cut-over (including the one destructive step everyone forgets), and then answer the question that actually stalls these projects: can I finally decommission NDES, or will that break my Wi-Fi and VPN?

The problem: certificate trust is a lot of glass to keep from cracking

Here is what certificate trust actually stands up. During provisioning, after the user's key pair is registered with Azure Device Registration Service, Windows builds a PKCS#10 certificate request and sends it to a certificate registration authority (RA) hosted on your AD FS farm. The RA queries Active Directory (the msDS-KeyCredentialLink attribute) to confirm the public key is really the user's, signs the request with its enrollment-agent certificate, and forwards it to your enterprise CA. The CA issues a WHfB logon certificate, which lands in the user's Personal certificate store. That certificate is what authenticates to your DCs.

Count the dependencies: an AD FS farm, the device registration and certificate registration authority roles on it, an enrollment-agent certificate, a WHfB certificate template on the enterprise CA, and the CA itself. Every certificate in that chain expires. AD FS is a public-facing attack surface. And none of it is needed once Microsoft Entra ID can mint the Kerberos ticket for you.

Why it happens: there is no in-place migration

You cannot simply flip a policy and roll from certificate trust to cloud Kerberos trust. Microsoft is explicit about this: there is no direct migration path. The reason is the Windows Hello container — the protected store that holds the user's WHfB credential. Under certificate trust that container holds a certificate-based credential. Cloud Kerberos trust needs a key-based credential in a fresh container. The two cannot occupy the same container, so the old one must be deleted before the new model can provision.

Contrast that with key trust, which does migrate cleanly (set up Entra Kerberos, enable the cloud-trust policy, sign out and in). Certificate trust is the awkward one, and the awkwardness is entirely about that container.

How to verify you are actually on certificate trust

Before you change anything, confirm the current state on a sample device. The reliable client-side signal is the WHfB certificate itself: it lives in the user's Personal store and its private key sits in the Microsoft Passport Key Storage Provider. Check for it:

Also check the policy that pins the device to certificate trust. On a managed device the value is written under the PassportForWork policy tree:

The fix: the migration, phase by phase

Phase 1 — Stand up cloud Kerberos trust in parallel

Do this first, and leave certificate trust running. Deploy Microsoft Entra Kerberos (the Set-AzureADKerberosServer cmdlet from the AzureADHybridAuthenticationManagement module) for each domain, exactly as in the deployment guide. Nothing changes for users yet, because the certificate-trust policy still wins.

Phase 2 — Pilot the cut-over on a ring of devices

On your pilot group, in this order:

1. Set Use certificate for on-premises authentication to Not configured (remove it from scope — do not just set it to disabled if you can avoid it).
2. Enable Use cloud trust for on-premises authentication and confirm Use Windows Hello for Business is on.
3. Delete the existing Hello container in the user context. This is the destructive step:

4. Sign out and sign back in. The certificate-trust credential is gone, the cloud-trust policy is in force, and WHfB re-provisions with a fresh key-based credential.
5. On a Microsoft Entra hybrid joined device, that first sign-in must have line of sight to a domain controller so the partial TGT can be exchanged for a full one.

Phase 3 — Decommission the certificate-trust infrastructure (carefully)

Only after the whole fleet is confirmed on cloud trust. Retire in this order: remove the WHfB certificate template from the enterprise CA (or unpublish it so no new certs issue), then decommission the AD FS certificate registration authority role, and finally the AD FS farm itself if nothing else depends on it.

Confirm what your NDES/SCEP connector is actually issuing before touching it:

Cross-reference each connector against your active SCEP configuration profiles under Devices › Configuration. If any Wi-Fi or VPN profile depends on a SCEP profile served by that connector, NDES stays — WHfB migration or not.

Proof it worked

On a migrated device, three things confirm success. First, the WHfB certificate is gone from the user store (the earlier Get-ChildItem Cert:\CurrentUser\My check returns no Passport-backed cert). Second, dsregcmd /status shows the on-prem ticket obtained via cloud trust:

Third, open an on-prem file share. Single sign-on with no password prompt, using a credential that has no certificate behind it, is the whole point of the exercise.

References

• Cloud Kerberos trust deployment guide (includes the certificate-trust migration steps)
• How Windows Hello for Business provisioning works (certificate-trust flow)
• Windows Hello for Business policy settings
• Certificate connectors for Microsoft Intune (NDES/SCEP)