TPM Key Attestation: What It Is, How It Works, and Why Enterprise PKI Needs It

Most enterprise public key infrastructure (PKI) teams spend considerable effort deciding which certificate templates to deploy, which key sizes to require, and which enrollment protocols to support. Far fewer spend time on a quieter question that sits underneath all of it: once a certificate is issued, how does the certificate authority (CA) actually know the private key behind it is where the organization believes it to be?

The usual answer is that there is no direct proof. The CA issues the certificate based on who authenticated and what template they requested. Whether the private key ended up locked inside a hardware security module (HSM), generated in a software crypto provider, or exported to a USB drive and taken home by a contractor is, from the CA’s perspective, invisible. Trusted Platform Module (TPM) Key Attestation is the mechanism that closes that gap. It gives the CA cryptographic evidence, not just an assertion, that a private key was generated by a real TPM and has never left it.

This blog covers what TPM Key Attestation actually is at a technical level, how it works inside Active Directory Certificate Services (AD CS), the three trust models available, and where it fits into a broader enterprise identity and PKI strategy.

What TPM Key Attestation Actually Proves

A TPM is a tamper-resistant microcontroller, built directly onto the motherboard of most modern PCs, laptops, and servers, that can generate cryptographic key pairs internally and enforce that the private key never leaves the chip in usable form. Keys generated this way are non-migratable and non-exportable: even an administrator with full operating system access cannot extract them.

The challenge before TPM Key Attestation existed was that while Windows could generate keys inside the TPM, there was no way for the issuing CA to verify this actually happened. A certificate request arrived looking identical whether the private key was in the TPM or in a software store. The CA had no mechanism to distinguish between them and no way to enforce hardware key protection at issuance time.

TPM Key Attestation solves this by adding a cryptographic proof step to the enrollment flow. The device uses an Attestation Identity Key (AIK), a separate TPM-resident key whose private half also never leaves the chip, to sign a statement about the certificate key’s properties, confirming it was generated inside the TPM and marked as non-exportable. The CA receives that signed statement alongside the certificate request and can independently verify both the AIK’s legitimacy and the key’s properties before deciding to issue.

The result is a qualitatively different kind of assurance. The issued certificate does not just represent authentication based on domain credentials. It represents hardware-bound, non-exportable key protection, verified by the CA before issuance, and recorded in the certificate itself via an Object Identifier (OID) in the issuance policies extension.

To understand why that proof is trustworthy, you need to follow the trust chain it depends on.

How the Trust Chain Works: EK, AIK, and the CA

Every TPM contains an Endorsement Primary Seed: a secret value generated during manufacturing that never leaves the chip. From this seed, the TPM deterministically generates the Endorsement Key (EK) pair on demand. In TPM 1.2, a single RSA-2048 EK was factory-provisioned as a persistent key; in TPM 2.0, the EK is recreated from the seed as needed and does not have to be stored persistently on the device. Manufacturers typically provision an EK Certificate covering the default EK public key (EKPub) at the factory. The essential property is the same regardless of TPM version: the EK private key is bound to that specific chip and can never be extracted from it.

The AIK is independently generated inside the TPM. The two keys are linked by a TCG-defined credential activation process: the CA encrypts a secret challenge using the device’s EK public key, which only the genuine TPM can decrypt using the EK private key. Successfully completing this challenge proves the AIK is resident in the same TPM as the EK, transferring trust from the EK to the AIK without exposing any private key material. When the device performs key attestation for a certificate request, it uses the AIK private key to sign the attestation statement. Because the AIK private key can only be used inside the TPM that generated it, and because the AIK’s legitimacy has been tied to the EK through activation, a CA that trusts the EK can trust that the AIK signature is genuine and that the key being attested is really TPM-resident.

The CA’s job is to verify this chain before issuing the certificate. It checks that:

• The AIK signature is valid
• The attested key has the claimed properties (non-exportable, TPM-generated)
• The EK traces back to a manufacturer or device the organization trusts, depending on the trust model in use

With that chain established, the question becomes which trust model your AD CS deployment should use.

Three Ways to Establish TPM Trust in AD CS

Microsoft’s AD CS implementation supports three distinct methods for establishing trust in the attesting TPM. Each offers a different trade-off between administrative effort and assurance level. All three insert an OID into the issued certificate recording which method passed.

Trust Method	How It Works	Admin Effort	Assurance Level
User / AIK Certificate	CA accepts any valid AIK, trust based on domain credentials alone	Low: no device lists required	Low: proves a key is in some TPM, not necessarily a verified one
EKCert (Endorsement Key Certificate)	CA validates the device’s EK Certificate against trusted TPM manufacturer root CAs imported into the CA	Medium: one-time import of manufacturer root CAs	High: proves the TPM is from a trusted manufacturer
EKPub (Endorsement Key Public Key)	CA validates the EK against an administrator-maintained list of specific, registered EKPub hashes	High: each device must be individually registered	Highest: proves the key is from a specific, known device

Most enterprises land on EKCert as the practical default. Importing manufacturer root CAs is a one-time operation that covers the entire managed fleet without per-device registration overhead. Note that not all TPM manufacturers provision EK Certificates on their chips, so EKCert availability should be verified against your specific device models before committing to this trust model. EKPub is the right choice for environments that need to explicitly control which individual devices can produce certificates, such as high-security government or financial infrastructure.

With the trust model chosen, the next step is configuring the certificate templates that enforce it.

Configuring Certificate Templates for Attestation

The attestation requirement lives at the template level inside the Certificate Templates console, which means it applies per certificate type rather than globally across all issuances. Before you touch the attestation setting, two pre-conditions must be in place:

Microsoft Platform Crypto Provider KSP

The template must use the Microsoft Platform Crypto Provider specifically, under the Key Storage Provider category. Third-party smart card KSPs are not supported for TPM Key Attestation, even if they are CNG-based. Additionally, the algorithm must be set to RSA: TPM Key Attestation in AD CS only works for RSA keys. ECC keys are not supported for attestation.

Signature Purpose

The Request Handling purpose must be set to Signature (or Signature and encryption), and the Allow private key to be exported and Archive subject’s encryption private key options must both be unchecked.

With those met, the Cryptography tab exposes the attestation setting with three options:

None:
No attestation required. The default on most templates. The CA issues without any hardware key proof.

Required, If Client Is Capable:
The CA accepts and records attestation if the device supports it, but still issues to devices that cannot attest (older TPMs, VMs without a vTPM, etc.). Useful as a transitional setting while you assess TPM coverage across the fleet. Attested certificates are distinguished by an issuance policy OID; non-attested ones are issued without it.

Required:
The CA refuses to issue if valid attestation is not present. This is the setting that actually enforces hardware key protection.

When a CNG-capable Windows device enrolls against a Required template, the enrollment stack handles the attestation flow automatically. The TPM generates the key, the AIK signs the statement, and everything is packaged into the certificate request with no action needed from the end user. If the device has no TPM or attestation fails, enrollment fails. That failure is the intended behavior: it prevents a device from obtaining a certificate that would misrepresent its key protection level.

The OID written into the issued certificate’s issuance policies extension is the audit artifact that records which trust level passed. Conditional access policies, downstream access rules, and auditing tools can all query that OID to distinguish hardware-attested certificates from software-stored ones.

With the mechanics understood, the next question is where this actually changes security outcomes in practice.

Where TPM Key Attestation Fits in the Enterprise

The practical value of TPM Key Attestation is most visible in four scenarios:

Zero Trust Device Access

Zero Trust architectures require that device identity be strongly verified, not assumed from network location. A certificate with a TPM-attested private key provides materially stronger assurance than a software-stored one: an attacker who compromises the OS still cannot export the key and impersonate the device from another machine. Requiring TPM-attested certificates for VPN, Wi-Fi (802.1x), and application access closes the most common credential-theft lateral-movement path.

Windows Hello for Business

WHfB replaces passwords with a PIN or biometric gesture backed by a cryptographic key pair. The security model depends entirely on the private key being hardware-bound. TPM Key Attestation is how the CA verifies that binding before issuing the WHfB credential certificate. WHfB certificate templates require CNG enrollment and are typically configured to enforce attestation, consistent with the hardware-binding guarantee that makes WHfB’s security model meaningful.

Intune-Managed Device Authentication

SCEP and PKCS certificate profiles deployed through Intune can require TPM enrollment. Combined with CA-side attestation requirements, this gives device certificates issued through Intune the same hardware-bound guarantee as those from traditional AD CS auto-enrollment, even on cloud-only, non-domain-joined devices.

Regulated Environments and Compliance

FIPS 140-3 requirements in US federal and contractor environments, and NIST SP 800-157 guidelines for derived PIV credentials, align directly with what TPM Key Attestation provides. The OID in the issued certificate gives auditors a verifiable record of the hardware protection claim rather than an unverifiable policy assertion.

There is also an important boundary to understand: TPM Key Attestation is not a complete device health signal.

What TPM Key Attestation Does Not Cover

TPM Key Attestation is scoped specifically to the moment of certificate issuance and the protection of the private key. It does not measure or attest to the software state of the device, the integrity of the boot chain, or whether the operating system has been tampered with after provisioning. Those concerns belong to other hardware attestation mechanisms:

• Platform Configuration Register (PCR) measurements capture boot-time firmware and OS state inside the TPM
• Remote attestation via SPDM allows runtime hardware identity verification between components
• DICE-based hardware identity frameworks (a TCG specification) provide factory-rooted layered identity across hardware classes including endpoints, servers, and embedded devices

A TPM Key Attestation on a certificate means “this key is genuinely in hardware.” It does not mean “this device is in a known-good state.” Both claims matter in a mature Zero Trust architecture, and they come from different places. Treating attestation as a complete device health check is one of the most common misunderstandings of what the feature actually provides.

There are also two important scope constraints worth knowing before you deploy. First, TPM Key Attestation in AD CS only works for RSA keys: ECC-based certificate templates cannot use attestation, regardless of how they are configured. Second, TPM Key Attestation is not supported on standalone CAs: it requires an enterprise CA integrated with Active Directory. If your issuing CA is a standalone CA, attestation is not available to it at all.

How Encryption Consulting Can Help

Deploying TPM Key Attestation effectively sits at the intersection of PKI design, device management, and identity governance: three disciplines that rarely share a roadmap in most enterprise organizations.

Getting it right involves several moving parts:

• Certificate templates correctly configured for CNG and the appropriate attestation level
• AD CS infrastructure loaded with the right TPM manufacturer root CAs for EKCert trust
• Intune or Group Policy enrollment profiles aligned with the CA-side attestation requirements
• Conditional access and downstream access policies that actually consume the attestation OID

Encryption Consulting’s PKI services team works across the full stack, from CA hierarchy design and certificate template hardening through to Intune integration and Zero Trust policy alignment. Whether you are building a new PKI environment with TPM Attestation designed in from the start, or hardening an existing AD CS deployment where hardware key protection was previously optional, our team brings the depth of experience that comes from running enterprise PKI programs across financial services, healthcare, government, and technology organizations.

If you are assessing your current PKI posture or planning a modernization that includes Windows Hello for Business, conditional access, or Zero Trust device identity, reach out to understand what a structured PKI health assessment would look like for your environment.

Conclusion

TPM Key Attestation is one of the most underused capabilities in enterprise PKI. Most organizations already have the hardware and software infrastructure to use it. Windows 11 mandates TPM 2.0 as a system requirement, AD CS has supported attestation since Windows Server 2012 R2, and enabling it is a certificate template configuration change rather than a major infrastructure project. What is missing, more often than not, is awareness of what the feature actually does and the operational confidence to set it to Required rather than leaving it at Required if the client is capable or None.

A certificate issued under a Required attestation policy is a categorically different security artifact. The private key behind it cannot be extracted and replicated by an attacker who compromises the operating system. That is a meaningful guarantee in a world where credential theft drives most lateral movement and where Zero Trust frameworks demand that device identity claims be verifiable rather than assumed. If your organization is not yet using TPM Key Attestation on high-value certificate templates, that is worth putting on the PKI modernization roadmap.