A TPM endorsement key is often described as a device identity. That description is incomplete. The private key is designed never to leave the TPM, but a verifier must still establish that the public key belongs to a genuine TPM and that the certificate chain reaches a manufacturer trust anchor it recognizes. A certificate request can contain an endorsement key public value without proving that relationship. For a Windows enterprise CA, that distinction determines whether attestation is a hardware claim or merely a user-provided assertion.
What the endorsement key proves
Microsoft documentation describes the endorsement key as an identity card for the TPM and says its private portion is not exposed to software, processes, or users. The manufacturer can issue a certificate over the public endorsement key. Windows exposes those certificates through Get-TpmEndorsementKeyInfo. An attestation identity key can then report platform state while limiting how often the endorsement key itself is disclosed.
The endorsement key is unique enough to link a device across identity providers. Privacy design therefore separates it from the key used for routine attestation. That separation does not remove the need to validate the certificate issuer, signature, revocation status, and key match.
The dangerous CA shortcut
Microsoft's TPM key attestation guidance distinguishes trust based on a user credential from validation of the endorsement key. A CA that accepts a user-provided endorsement public key without checking a manufacturer certificate is trusting the requester, not the TPM. Confirm-CAEndorsementKeyInfo lets administrators verify whether a device's endorsement key is trusted for attestation.
Inventory the CA policy before trusting device certificates for conditional access, certificate enrollment, or device health. Record which vendor roots are allowed, how intermediate certificates are pinned, whether revocation is checked, and what happens when a vendor certificate expires. A permissive fallback that accepts an unvalidated endorsement key for compatibility should have a named owner and a retirement date.
Operational checks
Start with a sample of managed devices from each hardware vendor. Export the endorsement key certificate chain and confirm the leaf key matches the TPM key. Validate the chain against the approved roots. Check certificate expiry and any revocation signal the CA consumes. Run the same test after a motherboard replacement, TPM clear, or firmware update.
Separate lab and production CA templates. A lab template that accepts synthetic endorsement keys can be useful for testing, but its issuance policy must not be reachable by production clients. Alert on certificate requests that omit a vendor chain when the production template requires one.
For high-value workloads, bind the issued certificate to the attestation key policy and record which TPM PCR measurements are required. Endorsement key validation identifies the hardware; it does not prove that the operating system is healthy. The two questions need separate evidence.
Review the failure path
Test what the CA does when the certificate chain is unknown, the signature is invalid, or the endorsement key does not match. A clear rejection is preferable to silent issuance under a fallback profile. Also test whether an administrator can override the policy without a second approver or durable audit record.
TPM attestation becomes useful when the verifier can explain the chain of trust from the hardware key to the enrolled device. That requires more than reading a public key from a request. It requires a certificate policy that validates the vendor chain, limits the trust anchors, and fails closed when the evidence is incomplete.