PKI Requirements for Windows Hello for Business Cert trust

If you’ve read ANY of my previous posts, or worked with me, or listened to any of my presentations, you know that I’m not exactly a proponent of HAADJ. In fact, I’ve turned down customer engagements because they insist on clinging to hybrid in 2025. Anyway, a friend reached out and asked me to write about the WHfB Cert trust requirements when bringing existing PKIs up to speed, so here we go.

Let’s face it – when it comes to onboarding Windows Hello for Business Certificate Trust, the real hero (or villain, depending on your caffeine levels) is your PKI. Yes, that ancient beast lurking in your infrastructure, quietly judging your certificate templates and CRL distribution points. This article is all about what you need to do to tame it.
Now, before you roll your eyes and ask, “Is this a Hybrid Azure AD Join love letter?” – rest assured, it’s not. In fact, if Hybrid were a party, I’d be the one awkwardly hovering by the exit, clutching my cloud-native coat and whispering, “I’ve got other plans”.
Instead, we’re diving into the cert trust setup with a healthy dose of irony, a few puns, and a strong suggestion that maybe – just maybe – it’s time to consider cloud-only scenarios. Because while Hybrid might still be hanging around like a legacy karaoke machine, the cloud is belting out hits with zero latency.
So grab your PKI checklist, dust off those certificate templates, and let’s get certifiably serious (but not too serious) about making Windows Hello for Business work – without getting stuck in the Hybrid haze.

Windows Hello for Business (WHfB) introduces a modern, passwordless authentication method that could require integration with an organization’s Public Key Infrastructure (PKI). In a hybrid certificate trust deployment of WHfB, both your domain controllers and your users’ devices rely on digital certificates issued by an enterprise PKI for authentication. This article details the certificate template requirements for onboarding Windows Hello for Business and explains how companies with established PKI environments (that have been in use for many years) should plan their deployment. We will highlight new requirements – such as use of Key Storage Providers – and other template attributes that have become necessary in recent guidance, contrasting them with legacy recommendations. The goal is to ensure technical professionals can update or design their certificate templates to meet WHfB requirements, especially if their existing PKI was built on older standards.

Overview: Windows Hello for Business and PKI

Windows Hello for Business provides three main trust models for authentication in hybrid AD environments: Key Trust, Cloud Kerberos Trust and Certificate Trust. The certificate trust model – which this article focuses on – uses a certificate-based authentication mechanism similar to smart card logon. In this model, each WHfB-enabled user gets an authentication certificate on their device during provisioning, and domain controllers use Kerberos Authentication certificates to establish trust. For a deep dive into the latest and greatest around WHfB, see one of my previous articles on Cloud Trust.

To support certificate trust, your PKI must issue two types of certificates with specific template settings:

• Domain Controller certificates: These are issued to all domain controllers to allow them to perform certificate-based Kerberos authentication (including as part of WHfB). They must include the modern KDC Authentication capability and use strong cryptography.
• Windows Hello for Business user certificates: These are issued to user devices during WHfB provisioning (often via AD FS acting as an enrollment agent) and are used by the device to authenticate the user to the domain (in lieu of a password).

Organizations with an existing PKI (perhaps running for many years) likely have certificate templates already in use for domain controllers or smartcard logon. However, WHfB introduces new requirements – for example, the use of Key Storage Providers (KSP) instead of legacy Crypto Service Providers – that were not enforced in older guidance. In the sections below, we outline the required settings for each certificate template and discuss what changes may be needed if your current PKI was built on legacy defaults.

Certificate Template Requirements for WHfB

Let’s break down the requirements for the certificate templates involved in a WHfB certificate trust deployment. We’ll address domain controller certificates first, then the Windows Hello for Business authentication certificate used by clients. For each template, critical settings like cryptographic provider, key size, allowed algorithms, and special flags will be highlighted.

1. Domain Controller Certificate Template (Kerberos Authentication)

All domain controllers must have a certificate that includes the KDC Authentication extended key usage, enabling them to participate in Kerberos PKINIT (the certificate-based Kerberos protocol). Microsoft’s current guidance is to use the Kerberos Authentication template (or a duplicate of it) as the basis for domain controller certs, rather than older templates like “Domain Controller” or “Domain Controller Authentication”. The Kerberos Authentication template is a Version 3 template that supports newer cryptography. Microsoft recommends duplicating this template and modifying it to meet modern requirements:

• Template Base: Duplicate Kerberos Authentication template and create a new template (e.g., named “Domain Controller Authentication (Kerberos)”).
• Compatibility: Set minimum CA version to Windows Server 2016 and minimum client OS to Windows 10/Server 2016. This ensures the template can use v3/v4 features.
• Subject Name: Use Active Directory–generated subject name. Typically, Subject = DC’s FQDN and include the DNS name in Subject Alternative Name.
• Cryptography Settings: Provider Category = Key Storage Provider (KSP). This is a crucial update – legacy templates used legacy CSPs by default, but now you must require KSP to use modern crypto APIs. Algorithm should be RSA, with a minimum key size of 2048 bits, and use SHA-256 as the request hash algorithm. Setting the Provider Category to Key Storage Provider in the template ensures the certificate’s private key is generated and managed by CNG (Cryptography Next Generation) providers rather than the older CryptoAPI CSPs.
• Extended Key Usage (EKU): Must include KDC Authentication (OID 1.3.6.1.5.2.3.5). In practice, the Kerberos Authentication template by default includes EKUs for Client Authentication, Server Authentication, and KDC Authentication – all are needed. (It also covers Smart Card Logon by including that OID by default.)
• Key Usage: Include Digital Signature and Key Encipherment (typical for authentication certs).
• Private Key Flags: Enable “Renew with same key” if available. Version 4 templates (introduced in Win Server 2012) support a flag to reuse the same key on renewal. Using the same key for renewal can be beneficial for continuity.
• Supersede Old Templates: If older DC cert templates (like Domain Controller or DC Authentication) were used in your environment, configure the new template to supersede them. This helps auto-enrollment replace old certificates with the new one. Microsoft’s guidance is to supersede the legacy v1/v2 templates with the new one so domain controllers drop the outdated certs.
• Enrollment: Ensure domain controllers can auto-enroll for this new template. That typically means enabling auto-enrollment via Group Policy for the Domain Controllers OU.

In summary, the domain controller certificate template for WHfB should enforce modern cryptography (RSA 2048/SHA256), use the Key Storage Provider category, and include Kerberos Authentication EKU. These requirements are stricter than old default DC certificates. For example, legacy Domain Controller templates (v1) could not be changed and lacked the KDC EKU, and the later “Domain Controller Authentication” (v2) template did not use newer crypto APIs (CNG). By creating an updated template (v3/v4) with KSP, you ensure domain controllers use the latest crypto providers and are trusted by Windows Hello for Business clients.

Why Key Storage Provider? Requiring Key Storage Provider means the certificate’s key can be created by CNG providers, potentially in hardware. This is important for WHfB because it aligns with using TPM-protected keys. Older “Legacy CSP” options might not leverage the TPM or modern algorithms. Microsoft explicitly recommends setting Provider Category = Key Storage Provider on the Kerberos Authentication-derived template to ensure “the best available cryptography” for domain controllers.

2. Windows Hello for Business User Authentication Certificate Template

During WHfB onboarding (provisioning) on a domain-joined device, the user will obtain a certificate used for authentication (often called the WHfB authentication certificate). This certificate is typically issued via an intermediary (like AD FS) on behalf of the user to the user’s device, and it serves a similar purpose as a smart card logon certificate. The certificate template for this needs careful configuration to meet WHfB requirements:

• Template Base: Start with duplicating the Smartcard Logon template as a base. The Smart Card Logon template contains the appropriate EKU and general settings needed for user authentication certs.
• Compatibility: Set CA compatibility to Windows Server 2016, and certificate recipient (client) to Windows 10/Windows Server 2016. This ensures the template can use new features (it will be at least a v3 or v4 template).
• Subject Name: Use Active Directory information. Configure Subject Name format as Fully Distinguished Name of the user, and include the User Principal Name (UPN) in the Subject Alternative Name (SAN) field. In other words, the cert will have the user’s AD Distinguished Name as the subject and their UPN (username@domain) as an alt name, which is needed for logon mapping.
• Cryptography: Set Provider Category = Key Storage Provider (KSP), Algorithm = RSA, Minimum key size = 2048 bits, Hash = SHA-256. Just like the DC cert, this user cert must use a KSP. This allows the private key to be generated by modern providers – in practice, WHfB will use the Microsoft Software Key Storage Provider or Microsoft Platform Crypto Provider (for TPM) to generate the key in the device’s credential store. Legacy guidance for smartcard certificates did not always enforce KSP (since physical smart cards often used vendor CSPs), but for WHfB it is now a requirement to use KSP for the virtual smart card scenario.
• Extended Key Usage: Ensure Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) is present in Application Policies (this EKU allows the certificate to be used for logon). You may also have Client Authentication (1.3.6.1.5.5.7.3.2) present; the Smartcard Logon template includes both by default. The key point is the certificate must be recognized as a smart card logon certificate by the domain.
• Issuance Requirements: Set “This number of authorized signatures” = 1 and require the signature by a Certificate Request Agent (an enrollment agent). This is a special setting meaning the certificate request must be signed by an authorized agent certificate. In a WHfB deployment, AD FS (or Azure AD Connect provisioning agent) acts as that agent – it holds an Enrollment Agent certificate and will sign the user’s request on their behalf. Requiring a Certificate Request Agent signature ensures that only the service (AD FS) and not end-users directly can enroll for this template. Also select “Valid existing certificate” for the certificate request agent enforcement, so that the agent must have a valid cert itself.
• Private Key & Renewal: Enable “Renew with same key” in the Request Handling settings. This corresponds to the flag CT_FLAG_REQUIRE_SAME_KEY_RENEWAL, which ensures that when the certificate is renewed (upon expiration), the same key pair is used rather than generating a new key. For WHfB, this is logical since the key is tied to the device’s TPM; reusing it avoids generating a completely new credential each time.
• Security: Limit enrollment to appropriate security principals. Add the user group that will be allowed to enroll (e.g., a group “WHfB Users”) with Enroll permission, and remove Enroll permissions from others. This prevents misuse of the template. Often, one does not allow auto-enrollment for this template; enrollment will be triggered by the WHfB provisioning process instead.
• Special Flag for WHfB: Mark the template with the Windows Hello for Business logon flag. Microsoft introduced a private key flag called HELLO_LOGON_KEY (value 0x00200000) to designate certificates intended for WHfB usage. After creating the template, you enable this by running a certutil -dstemplate command:
• certutil -dsTemplate <TemplateName> +CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY This flag isn’t present in legacy templates at all – it was added in newer Windows versions. By setting it, the certificate will be marked in Active Directory such that Windows knows this certificate can be used for Hello for Business login. In practical terms, this helps the OS enforce certain behaviors for WHfB credentials.

With these settings, the issued certificate on a WHfB device will have the proper subject (user’s identity), will chain to the enterprise CA, and will be usable for logon. The private key will be generated in the device’s secure key store, ideally backed by the TPM (because we allowed only KSP providers, the OS will choose a suitable provider such as the Microsoft Platform Crypto Provider if a TPM is available). The certificate issuance is locked down to only occur via the authorized Enrollment Agent (your AD FS), preventing rogue enrollment. This design mirrors a smart card issuance process, but virtually (as there’s no smart card involved).

Legacy vs. New: It’s worth noting how this differs from legacy certificate templates:

• Older smart card or user auth certificate templates often allowed Legacy CSPs (for example, to support physical smart cards that used a specific CSP). The new approach mandates KSP, which enables support for modern algorithms and TPM key storage.
• Legacy guidance didn’t include the HELLO_LOGON_KEY flag because it didn’t exist until recent schema updates. This flag is a new introduction for WHfB scenarios.
• Many older templates didn’t use the “authorized signature” (enrollment agent) requirement; that setting is used here because WHfB uses a brokered enrollment via AD FS. If your company’s PKI is old, you might never have used the Certificate Request Agent concept – it was primarily used for smart card issuance or NDES scenarios. Now it’s integral to WHfB certificate trust deployments.
• Cryptographic requirements (RSA 2048/SHA256) were not always enforced in older templates. For instance, some organizations might still have had templates allowing 1024-bit keys or using SHA-1 if they were set up ages ago. WHfB effectively forces a cleanup: only strong algorithms are acceptable.

New vs Legacy: Key Storage Provider and Other Recent Requirements

Let’s unpack this shift from legacy Cryptographic Service Providers (CSPs) towards Key Storage Providers (KSPs) in certificate templates and other recently introduced requirements that long-standing PKIs need to consider:

• Key Storage Provider (KSP) Requirement: In the past, when you created certificate templates, you might not have specified the cryptographic provider category at all – or you left it as “legacy CSP” which was the default for many older templates. For example, a Windows Server 2003-era template would implicitly use legacy CryptoAPI providers (like “Microsoft Enhanced Cryptographic Provider”). Now, current best practice requires using KSPs (CNG). In both the domain controller and WHfB user templates described above, we explicitly set Provider Category = Key Storage Provider. KSPs are part of the newer Cryptography API: Next Generation (CNG) and are needed for advanced features like elliptical curve cryptography, TPM key storage, and modern key attestation. By contrast, legacy CSPs don’t support those especially well. Companies with old PKIs might have dozens of templates all using legacy providers. For WHfB, you will likely need to create new templates (or update existing ones if possible) to use KSP. This ensures keys can be stored with modern security (for instance, TPM-backed keys). Implication: If your CA or clients are too old to support KSP (for example, a CA running on Windows 2008 wouldn’t know about a “Windows 10” KSP-only template), that’s a red flag – you may need to upgrade infrastructure (we discuss planning below). The requirement for KSP goes hand-in-hand with raising the compatibility of templates to at least Windows Server 2012/2016 level. And in all honesty, if you’re still on Windows 2008 Servers, you might want to start modernizing there rather than on the client side.
• Modern Key Flags and Properties: Newer certificate template versions introduced certain flags not present or not used in older deployments: CT_FLAG_REQUIRE_SAME_KEY_RENEWAL: Ensures same key on renewal. Introduced with v4 templates (Windows Server 2012). If your PKI has been around “for many years,” there’s a chance your templates were v2 or v3 at best and might not have utilized this. Now it’s recommended (we enabled it for both DC and user WHfB templates) to avoid key proliferation. CT_FLAG_HELLO_LOGON_KEY: This flag is specifically for WHfB, marking the key as a Hello for Business logon key. It’s a recent addition (only in the last few years, after WHfB was introduced in Windows 10). Enterprises with old PKI wouldn’t have any templates with this flag because it didn’t exist. It’s not strictly mandatory to function, but strongly recommended to set it for the WHfB auth template to ensure full compatibility. The presence of this flag can be a signal to the system that this certificate should be treated differently (for instance, certain APIs might check for it). When you run the certutil command to add it, you are essentially updating the msPKI-Private-Key-Flag attribute on the template in Active Directory to include the bit 0x00200000. Attestation settings: While not explicitly required by WHfB in Microsoft’s docs, certificate templates now have the ability to require TPM key attestation. Flags like CT_FLAG_ATTEST_REQUIRED or related EKU settings can enforce that the certificate will only be issued if the client proves the key is in a TPM. For a company with a long-running PKI, this concept didn’t exist until Windows 8/10 era. In our WHfB template example, we did not require attestation (the flag was effectively ATTEST_NONE), but organizations could choose to require it to ensure every WHfB key is hardware-protected. This is an example of a “recent attribute” worth considering if you have stringent security – it’s not a legacy requirement, but a modern option. Cryptographic Algorithms: Legacy environments might still have templates allowing outdated algorithms (e.g., SHA-1, or RSA 1024, or even older CSPs that don’t understand ECC). Modern guidance mandates SHA-256 or stronger, RSA 2048 or larger (or use of ECC with equivalent strength). If your old PKI hasn’t been updated, you may need to explicitly set templates to SHA-256 (as we did). In fact, Microsoft’s Kerberos Authentication default template had older crypto (SHA-1) until you update it, which is why duplication and switching to KSP and SHA256 is required.
• Enrollment Agent / Brokered Enrollment: A subtle but important new requirement in WHfB certificate trust is that a service (AD FS) enrolls on behalf of the user. Traditionally, users self-enroll (auto-enrollment or manual) for user certificates. In WHfB, the user’s device doesn’t directly talk to the CA; instead, AD FS (with an enrollment agent cert) does. From a template perspective, the “authorized signature = Certificate Request Agent” was not commonly used by most enterprises historically. If your PKI has been around, you likely never used this except perhaps for smartcards. Now it becomes central. So, when planning, ensure you have an Enrollment Agent certificate issued to the AD FS service and the template’s permissions/issuance are configured accordingly. This is more of a deployment detail but ties into template settings (the issuance requirement we set).

In summary, Key Storage Provider usage is one of the biggest shifts from legacy to current requirements – both for security (TPM integration, modern crypto) and compatibility with Windows 10+ features. Other new attributes like Hello logon key flags, attestation enforcement, and renew-with-same-key are changes that anyone with an “old PKI” should review and incorporate when preparing for WHfB. These ensure that your certificates are issued with high security assurances and recognized properly by new systems. Ignoring these and trying to use old templates “as-is” could lead to enrollment failures or less secure deployments (for example, a WHfB key generated via a legacy CSP might not end up in the TPM, weakening security – precisely what you want to avoid in a passwordless solution).

Planning WHfB Onboarding with an Older PKI

If your company has had a PKI running for years (or even decades), you likely have to do some preparation to onboard Windows Hello for Business smoothly. Here’s a plan and key considerations:

1. Assess Your Current PKI Environment: Start by reviewing your Certification Authorities (CAs) and templates in use:

• What OS version are your CAs? If you still run a Windows Server 2008 R2 CA (or older), you should upgrade or introduce a new CA on a newer OS. WHfB certificate templates set to Windows 2016 compatibility won’t be usable on a 2008 CA. Ideally, have CAs on Windows Server 2016 or later, so they understand the new template settings and flags.
• Are you using SHA-1 anywhere (CA signatures or templates)? If so, plan to migrate to SHA-256. Windows Hello for Business will not work with old hash algorithms. Your root CA should have a SHA256 (or better) signature, and all issuing CAs too – which might already be done, but worth checking.
• Inventory existing certificate templates for domain controllers and smart card logon (if any). Note their versions and settings (key length, CSP/KSP, EKUs). This serves as a baseline of what must change.

2. Update Domain Controller Certificates: As detailed earlier, you should introduce a new Domain Controller certificate template based on Kerberos Authentication:

• Duplicate Kerberos Authentication template, set Provider to KSP, RSA 2048, SHA256, etc., include KDC EKU.
• On the CA, publish this new template and disable or delete the old DC cert templates (afterwards). You might not want to fully delete old templates immediately, but mark them superseded so they won’t be issued going forward.
• Implement Group Policy for auto-enrollment for the Domain Controllers OU. In older setups, you might not have used GPO auto-enrollment if using default templates (some DCs auto-enrolled by themselves for the default ones). But for the new template, you will need to enforce auto-enrollment to push it out.
• When this is done, all domain controllers will enroll the new certificate and thus be WHfB-ready. This step is crucial even if you choose a key trust model eventually, because hybrid key trust also requires domain controller auth certificates for Kerberos anyway. Many legacy environments still have only the old “Domain Controller” cert (no KDC EKU, using SHA1). Without updating, WHfB authentication will fail or be insecure.

3. Prepare the WHfB Authentication Template: Set up the user authentication certificate template for WHfB:

• Duplicate Smartcard Logon template with 2016+ compatibility. Adjust subject, cryptography (KSP, 2048, SHA256), EKU, issuance requirements (1 sign by request agent), security as described.
• On the CA, publish this template so the CA can issue it.
• Issue an Enrollment Agent certificate for the service that will request these on behalf of users. In a typical WHfB hybrid deployment, AD FS is used. AD FS needs a cert that has the Certificate Request Agent OID (EnrollOnBehalfOf) so it can sign user CSRs. You might use the built-in Enrollment Agent template for this. Many old PKIs never issued one of these, so this is a new step.
• Configure AD FS (or Azure AD Connect if using it) to know about this template. For example, in AD FS you set the Certificate Authentication policy to use the new template name (in Microsoft documentation, they instruct using certutil to set the template’s msPKI-PrivateKeyFlag for Hello and then AD FS will use it).
• Test enrollment: You can test a manual enrollment via the enrollment agent to ensure the template works before rolling out to users. This might involve using certreq with an agent or a test user, just to verify CA issues the cert correctly. Catching misconfigurations now is easier than later.

4. Ensure CRL Distribution and AIA are accessible: One sometimes overlooked aspect – your PKI’s Certificate Revocation List (CRL) and Authority Information Access (AIA) must be reachable by clients and domain controllers. WHfB logon will perform certificate chain validation:

• Domain controllers will check the user cert’s validity (thus need to reach CRL of your issuing CA).
• Clients may check the DC cert too. If your PKI is internal, ensure machines (especially if some are off-network) can reach CRLs (maybe publish CRL via HTTP that’s accessible, etc.). Old PKIs sometimes have only LDAP URLs which are fine on-prem but not for Entra ID joined scenarios.
• Although not a template requirement, this is a planning must-do: verify your CRLs aren’t using deprecated algorithms and are regularly published. An old PKI might have long CRL publishing intervals, which you might want to shorten to quickly revoke WHfB certs if needed, for security.

5. Address CA Capacity and Performance: WHfB could mean every user gets a certificate on each device they join. If you have thousands of users and they all start onboarding WHfB, your CA might see a surge in enrollment requests. Consider:

• Enabling certificate pooling or having multiple CAs issue the templates if load is high.
• Monitoring CA logs for any failures. Sometimes an old CA might have limits (like database size or transaction throughput). Windows Server CA’s are generally capable, but it’s good to verify. Also ensure your CA’s database backups, etc., are in place before large-scale enrollment.

6. Rollout and User Education: Once the PKI pieces are in place (new templates live, AD FS configured, DCs updated), you can roll out WHfB to users. From a certificate perspective, monitor that:

• Devices are successfully getting the WHfB auth cert during provisioning (look in a test user’s personal certificate store after WHfB setup).
• Domain logons with WHfB (PIN/biometric) succeed for those users – if there’s a misconfiguration, users may get errors falling back to password.
• Any failures in enrollment appear in the CA’s event logs or AD FS logs. Common missteps might be missing permissions on the template or the agent cert not being recognized.

Preparing an old PKI for Windows Hello for Business is largely about adopting modern best practices that may have been irrelevant when your PKI was first deployed. By planning the steps above, you ensure your infrastructure meets today’s standards:

• Upgrade cryptography (no SHA1, use KSP with strong keys),
• Update certificate templates (new versions, EKUs, flags),
• Implement strict issuance controls (ensuring only the intended process can get WHfB certs),
• Maintain revocation (so a lost device’s cert can be revoked and will be honored).

Conclusion

Deploying Windows Hello for Business with certificate trust in an enterprise with a legacy PKI is definitely feasible, but it requires careful updates to your PKI’s certificate templates and settings. In summary, certificate template requirements for WHfB include using Key Storage Providers, strong algorithms (RSA 2048+/SHA-256), including necessary EKUs (Smart Card Logon, KDC Authentication), and enabling new template features like Renew with same key and the Hello logon key flag. These requirements differ from older best practices that didn’t specify crypto providers or use these new flags – a direct response to today’s security needs and integration with technologies like TPM.

For companies with an old PKI, the onboarding plan should involve:

• Upgrading or reconfiguring the PKI (CA and templates) to meet modern standards.
• Replacing or superseding legacy certificate templates (especially for domain controllers and user auth certs) with updated ones that satisfy WHfB needs.
• Utilizing features that may be new to your org, such as enrollment agent-based issuance and possibly key attestation, to ensure only authorized issuance and robust protection for private keys.
• Verifying that the PKI’s trust chain (AIA, CRLs) and performance can support the WHfB rollout.

By addressing the “new vs legacy” gaps – particularly the “Keystore Provider” requirement which mandates moving to Key Storage Providers – and by planning the certificate deployment carefully, organizations can successfully implement Windows Hello for Business in a secure and seamless manner. This marries the convenience of passwordless authentication with the confidence of your enterprise PKI. In essence, modernizing your PKI becomes a foundational step in embracing a more secure, user-friendly authentication future.