Does a certificate with a TPM-stored key prove to the CA that the key is hardware-bound?

No. A key stored in a TPM by device configuration proves nothing to the CA by itself, and the certificate it produces carries no indicator of where the key lives. What does prove it is an issuance path in which the CA verifies an attestation statement before signing and records the result: AD CS templates with TPM key attestation do this for RSA keys on devices that enroll from an enterprise CA, and mark the certificate with an issuance policy OID the relying party can demand; agent-based enrollment that completes an ACME device-attest-01 challenge against an attestation CA does this for cloud-native and Linux devices, with the Windows Wi-Fi tier of the documented example currently held at partial. Intune's own SCEP and PKCS profiles, with AD CS, Cloud PKI or a third-party CA behind them, do not document attestation and should be treated as device-selected storage, not CA-verified binding.

Answer: negative · Last reviewed 2026-10-29

Who this applies to

Security architects and PKI administrators who are asked whether 'the key is in the TPM' can be relied on by a RADIUS server, VPN gateway or identity provider.

The problem

Device management tools let an administrator choose where a key is generated, and a certificate issued against that key is commonly called hardware-bound. The certificate authority that signed it saw a certificate signing request, which looks the same whether the key was created in a TPM or in software. Unless the issuance path included a cryptographic proof of key residency that the CA verified, the certificate carries no such proof, and a relying party that assumes it is trusting the device configuration rather than the CA.

Decision rule

What does the relying party need to trust: that the device was told to use the TPM, or that the CA verified the key is TPM-resident?
Does the issuance path carry an attestation statement to the CA (TPM key attestation, ACME device-attest-01), or only a CSR?
Is the proof visible in the issued certificate, for example as an issuance policy OID, so the relying party can require it?
Which populations can use a path that attests: domain-joined with AD CS, cloud-native with an agent, or neither?

Options

Options and documented limits
Option	How it works	Limits	When it fits	Evidence type
Intune SCEP profile with the key storage provider set to TPM	The device generates the key in the TPM KSP if the profile says so and submits a CSR; the issuer validates the Intune SCEP challenge to confirm the request came from an enrolled device.	Microsoft documents the KSP choice and the challenge validation and documents no verification of TPM key attestation by the connector, NDES, the Cloud PKI validation service or the CA. The resulting certificate carries no indicator of key residency.	Where TPM storage selected by the device is the requirement and the CA need not verify it.	vendor_documented, inferred, vendor_documented, inferred, vendor_documented
Intune PKCS profile	The private key is generated on the connector server, exported in a PFX, delivered to the device and marked not exportable.	The key never originates in device hardware, so no attestation of the key is possible; the Windows PKCS KSP setting decides only where the imported key is kept.	It does not fit this question; it is listed because PKCS certificates on Windows are sometimes described as TPM-protected after import.	vendor_documented, vendor_documented, vendor_documented, inferred
AD CS template with TPM key attestation	The requester proves to the CA that the RSA key is protected by a TPM the CA trusts; the CA trusts the TPM through its Endorsement Key public portion or Endorsement Key certificate, and issues the certificate with an issuance policy OID (1.3.6.1.4.1.311.21.30 for endorsement key, .31 for endorsement certificate, .32 for user credentials) that a relying party can require.	RSA only, Microsoft Platform Crypto Provider required, enterprise CA only; the page frames the feature around template-based enrollment and does not name Group Policy autoenrollment or Intune; the user credentials trust model validates the user, not the TPM.	Domain-joined or hybrid-joined Windows devices enrolling from AD CS where the relying party can check the issuance policy.	vendor_documented, vendor_documented, vendor_documented, vendor_documented, vendor_documented, vendor_documented, vendor_documented, vendor_documented
Agent-based enrollment with TPM attestation to the CA	The agent creates an attestation key pair in the TPM, the vendor's attestation CA verifies that the Endorsement Key is resident in an inventoried device, and the agent completes an ACME device-attest-01 challenge; the vendor describes the issued device certificate as proving both device identity and hardware binding of the key. On Linux the keys are TPM-bound and non-exportable, exposed through PKCS#11.	An agent on every device; TPM 2.0; Windows 10 or later, not Home; Windows Server not mentioned. For Windows Wi-Fi the documented example's own Core Concepts page states both device attested and the lower vendor-attested tier only, filed as a conflict and held at partial.	Cloud-native or non-domain devices, including Linux, where an agent is acceptable and the CA must verify residency.	vendor_documented, vendor_documented, vendor_documented, vendor_documented, vendor_documented, vendor_documented, vendor_documented

Strongest alternative

The Intune SCEP profile with TPM KSP otherwise fail came closest, because on a device with a TPM the key really is generated there and a device without one fails to enroll. It still fails the second criterion: nothing in the documented flow carries proof of residency to the CA, so the certificate is indistinguishable from one backed by a software key, and a relying party cannot require what the certificate does not assert.

Recommended approach

When another option is the better choice

Where the fleet is domain-joined and enrolls from AD CS, the AD CS template path answers the question without any third-party component. Where the relying party only needs to know that enrollment was restricted to Intune-managed devices, the Intune SCEP challenge validation already provides that, and no attestation path is needed.

Recommended tools

Microsoft: Active Directory Certificate Services, TPM key attestation: CA-verified TPM residency with an issuance policy OID the relying party can require, for devices that enroll from an enterprise CA.
Smallstep: Smallstep Agent: The documented agent path in which an attestation CA verifies the TPM Endorsement Key and the device completes device-attest-01, for Windows and Linux outside AD CS; Windows Wi-Fi tier held at partial.

Platforms and workflow records covered

Changes that affected this answer

No published changes linked.

What remains unverified

Whether any Intune certificate profile path conveys TPM attestation to the issuer: not documented on any Microsoft page fetched.
The attestation tier of the agent-based issuer's credentials for Windows Wi-Fi, pending resolution of the vendor's conflicting statements.

Evidence for the options

In the user credential trust model the CA trusts the user-provided EKPub and validates only the user domain credentials.

vendor_documented Evidence status: supported

Trust based on user credential: The enterprise CA trusts the user-provided EKPub as part of the certificate request and no validation is performed other than the user's domain credentials.Microsoft Learn: TPM Key Attestation; Deployment overview

Windows 8.1 or later client enrolling against a Windows Server 2012 R2 or later enterprise CA using a certificate template with the Key Attestation tab configured; purpose Wi-Fi EAP-TLS (the page names VPN or wireless access point as example resources); enrollment method Group Policy certificate autoenrollment (template-based enrollment); enrollment service none; issuer Active Directory Certificate Services enterprise CA.