TPM and Device Attestation for Enterprise Endpoints

Most "require a compliant device" policies trust whatever the endpoint says about itself, so the real question is which of those signals are rooted in the TPM or Secure Enclave and which are simply self-reported. This guide follows device evidence from the hardware to the access decision: how the TPM protects device identity keys, how Windows device health attestation and Apple Managed Device Attestation produce signed claims, how those claims become compliance state, and where conditional access actually consumes them. It is for endpoint, identity and zero trust engineers who already run compliance policies and want them to rest on hardware evidence. Boot chain internals, Secure Boot databases and PCR basics are in the Firmware and Boot Security Guide, and verifying key attestation statements (Android, AD CS trust models, WebAuthn) is in Hardware key attestation. This page does not repeat either.

Key takeaways

Two different things get called "device attestation". Key attestation proves where a credential's private key lives; health attestation reports how the device booted. Access policy needs both, and they fail in different ways.
The device identity key is the anchor. In Microsoft Entra ID the device key, transport key and PRT session key are TPM-protected on devices with a working TPM 2.0, which is what makes a "compliant device" claim hard to replay from another machine.
Health claims are point in time. Intune measures BitLocker state only at boot, Apple limits fresh attestations to one per device every seven days, and Windows 11 attestation tokens carry an expiry. Design for staleness.
Conditional access sees a verdict, not the evidence. The policy engine reads "compliant: yes or no", so the quality of the attestation depends entirely on which settings your compliance policy requires.
Software fallbacks quietly undo the design. TPM-if-present certificate profiles, Windows Hello without "Use a hardware security device" and non-TPM devices exempted from health checks all produce credentials that look identical in sign-in logs.

What the TPM contributes to an access decision

A TPM gives an endpoint three properties that software cannot: keys that are generated inside the chip and cannot be exported, a signed record of how the device booted, and a manufacturer-certified identity. Microsoft's description of how Windows uses the TPM states that "if a TPM creates a key, the key is unique and resides only in that TPM", and that the TPM's dictionary attack protection returns an error after too many guesses. Each property feeds a different part of the access chain.

TPM capability	Enterprise artefact	What access policy gains	What it does not prove
Endorsement key (EK) and EK certificate	Device inventory identifier; input to identity CAs	The device has a genuine TPM from a known manufacturer, not malware imitating one	Who uses the device or whether it is healthy
Attestation identity key (AIK, AK)	Signs quotes of PCR values for remote verifiers	A verifier can trust a boot measurement without trusting the operating system	Anything that happened after boot
Non-exportable keys via the Platform Crypto Provider	Entra device key, PRT session key, WHfB keys, TPM KSP certificates	A stolen token or certificate cannot be signed for from another machine	That the logged-in user or local malware is benign
Measured boot	DHA-Report or attestation JWT	BitLocker, Secure Boot, code integrity and VBS state at boot, signed by an attestation service	Runtime compromise; Microsoft notes measured boot stops at the initial starting state of Windows
Anti-hammering	PIN protection for WHfB and TPM-backed smart card style credentials	A short PIN is acceptable because guessing is rate limited in hardware	Resistance to phishing of other factors

NSA's November 2024 information sheet on TPM use cases recommends acquiring TPM 2.0 or later and integrating the TPM into infrastructure "for use cases achievable today". It lists asset management using the EK, Platform Certificate or Identity Key as a unique device identifier, and notes that on Windows Get-TpmEndorsementKeyInfo returns the EK's SHA-256 thumbprint, which can serve as that identifier. On Red Hat Enterprise Linux, tpm2_getekcertificate retrieves the EK certificate.

Device identity keys and the Primary Refresh Token

In Microsoft Entra ID, device registration creates a device key, and the Primary Refresh Token (PRT) issued to that device carries device and user claims that Conditional Access evaluates. According to the Entra PRT documentation:

Device key: signs the initial PRT request and, "on a device with a valid and functioning TPM", is secured by the TPM.
Transport key: Entra encrypts the PRT session key to it, and the private half is TPM-secured, so only that device can unwrap the session key.
Session key: the proof-of-possession key for the PRT; token and renewal requests are signed by it through the TPM, and Entra rejects requests not signed with it.
TPM version: TPM 2.0 is recommended, and after Windows 10 version 1903 Entra ID no longer uses TPM 1.2 for these keys.

Two details matter for policy design. First, Conditional Access is not evaluated when a PRT is issued or renewed; it is evaluated when the PRT is used to get access tokens for an application. Second, if a user has two accounts from the same tenant in one browser, the device authentication from the primary account's PRT also satisfies device-based policy for the second account. Protecting the PRT itself is covered in the Entra ID Primary Refresh Token (PRT) Security Guide.

On Apple platforms, Microsoft notes that Entra ID is moving device identity key storage to the Secure Enclave, and that some browsers then need extra configuration to present the device certificate. Platform SSO's Platform Credential for macOS provisions a Secure Enclave backed, hardware-bound key used for single sign-on, which can also act as a phishing-resistant WebAuthn credential (AAGUID 7FD635B3-2EF9-4542-8D9D-164F2C771EFC if you restrict AAGUIDs). Setting enable_se_key_biometric_policy to true requires Touch ID each time the user Secure Enclave key is used. See the macOS Platform SSO and Directory Binding Guide.

Windows device health attestation: the evidence chain

The HealthAttestation configuration service provider (CSP) documents two generations of the service. The difference matters because the fields you can enforce depend on which one your management platform calls.

Aspect	Windows 10: DHA-Service	Windows 11: Microsoft Azure Attestation (MAA)
Trigger	MDM runs `VerifyHealth`, polls `Status`, sets a `Nonce` (8 to 32 bytes, hex), then reads `Certificate`	MDM runs `TriggerAttestation` with relying party ID, endpoint, nonce and token, then checks `AttestStatus` and reads `GetAttestReport`
Verifier	Device Health Attestation service at `has.spserv.microsoft.com`, reached over TCP 443	An MAA instance with an attestation policy the organisation authors
Output	DHA-Report (XML) returned to the MDM	Signed JWT with `nbf`, `iat` and `exp`; claims depend on the policy
Typical fields	`BitlockerStatus`, `SecureBootEnabled`, `CodeIntegrityEnabled`, `ELAMDriverLoaded`, `VSMEnabled`, `BootManagerSVN`, `PCR0`, `TestSigningEnabled`	`bitlockerEnabled`, `secureBootEnabled`, `codeIntegrityEnabled`, `vbsEnabled`, `hvciEnabled`, `iommuEnabled`, `testSigningDisabled`, `bootDebuggingDisabled`
Freshness control	`ForceRetrieve`, intended only where the MDM enforces a certificate freshness policy	Token `exp`; `GetAttestReport` returns the cached token
TPM	TPM 1.2 or 2.0 (`TpmVersion` 1 or 2); reset and restart counts only on TPM 2.0	Not separately stated in the CSP documentation

The CSP documentation describes the MDM's options after evaluation as allow, allow with investigation, or block. Several DHA-Report fields are useful beyond a pass or fail: HealthStatusMismatchFlags appears only when the service detects a mismatch, BootManagerRevListVersion and BootManagerSVN show whether boot manager revocations have reached the device, and BootDebuggingEnabled or TestSigningEnabled set to true suggests a development machine that should not be treated as a production endpoint.

How Intune turns this into compliance

Intune's Windows compliance policy exposes three Device Health settings, each "Not configured" by default, which means not evaluated:

Require BitLocker: only measured at boot, so a device that finishes encrypting stays non-compliant until it reboots.
Require Secure Boot to be enabled on the device: devices without TPM 2.0 or later show as Not Compliant.
Require code integrity: detects an unsigned driver or system file loading into the kernel, or a system file changed by malware.

The separate "Trusted Platform Module (TPM)" setting under Device security only checks that a TPM specification version greater than zero is reported. It is a presence check, not attestation, so do not treat it as evidence of health.

Apple Managed Device Attestation in access policy

Apple's deployment guide lists the threats Managed Device Attestation (MDA) addresses: a compromised device misreporting its properties, presenting an outdated attestation, sending another device's identifiers, extraction of a private key for use on a rogue device, and hijacking of a certificate request. It is supported on iOS 16, iPadOS 16.1, macOS 14 and tvOS 16 or later, on A11 Bionic or later and Apple silicon. The access-relevant design points:

Attested enrolment: with ACME device-attest-01, the CA's ACME service requests an attestation and the OS generates a Secure Enclave key for the certificate request. The issued certificate then authenticates to the management service, Exchange, Kerberos, 802.1X and the built-in VPN client. See the 802.1X and EAP-TLS Enterprise Wi-Fi Guide.
Freshness: including DeviceAttestationNonce in a DevicePropertiesAttestation query forces a fresh attestation, limited to one per device every seven days; otherwise a cached result is returned. Apple suggests refreshing after property changes such as OS updates, with occasional random requests.
Failure is silent: a failed attestation may omit an expected OID, value or the whole attestation, and the cause is not reported. Treat missing as failed, not as unknown.
Trust scoring: Apple describes a failed or stale attestation lowering a zero trust score, leading to denied access, manual investigation, or wipe and certificate revocation.

Linux endpoints and servers

The Entra Conditional Access grant "Require device to be marked as compliant" supports Linux Ubuntu among its platforms, but Linux health attestation is typically run separately. Keylime, a TPM-based remote boot attestation and runtime integrity project, uses four components: an agent on the attested host, a registrar that records the EK, EK certificate and attestation key and checks the AK belongs to the EK with MakeCredential and ActivateCredential, a verifier that pulls or receives evidence, and a tenant tool for management. When an agent leaves the trusted state the verifier sends revocation messages, which can change local policy on peer systems. Keylime's design notes recommend validating the UEFI event log with a policy engine rather than static PCR values, because golden values break whenever firmware, bootloader or kernel change. Wiring a revocation into an access decision (network admission, certificate revocation, a SIEM-driven block) is the integrator's job.

Binding credentials to hardware

Health attestation is only worth as much as the credential it is attached to. If the device certificate or sign-in key can be copied, an attacker replays it from a machine that never attested.

Credential	Setting that forces hardware	Fallback to avoid
Intune SCEP or PKCS device certificate (Windows)	Key storage provider "Enroll to Trusted Platform Module (TPM) KSP, otherwise fail"	"Enroll to Trusted Platform Module (TPM) KSP if present, otherwise Software KSP" and "Enroll to Software KSP". Note 4096-bit keys work only in the Software KSP, so a 4096-bit profile silently forces software keys
Windows Hello for Business	"Use a hardware security device" (RequireSecurityDevice)	Default behaviour, which prefers the TPM but falls back to software keys. See the Windows Hello for Business Guide
Apple device certificate	ACME payload with hardware-bound key and attestation	SCEP profiles where the key is generated without attestation
Entra device identity	TPM 2.0 present and functioning at registration	Registering devices whose TPM is disabled in firmware, then enabling it later without re-registering
Virtual smart cards	Microsoft now recommends moving to Windows Hello for Business or FIDO2	New virtual smart card deployments

Where you need cryptographic proof that a certificate key was generated in a TPM, rather than a configuration promise, use AD CS key attestation as described in Hardware key attestation.

Choosing how much attestation to require

Small organisation, cloud managed: require BitLocker, Secure Boot and code integrity in compliance, use "Require device to be marked as compliant" for all cloud apps, and set WHfB to require a hardware security device. This gives hardware-rooted signals with no attestation infrastructure to run.
Regulated or high-value access: add TPM-only certificate profiles and ACME attested certificates for network and VPN access, so the network path also depends on hardware keys, and pair them with phishing-resistant sign-in such as hardware-bound Windows Hello for Business.
Mixed estates with third-party MDM: Microsoft documents that non-Microsoft compliance partners can mark Windows devices compliant only; plan Apple and Android compliance through the platform that can actually ingest their attestation.
Servers and Linux fleets: conditional access rarely applies; use Keylime or an equivalent verifier and feed failures into certificate revocation or network quarantine.
Older hardware: devices without TPM 2.0 will fail Secure Boot compliance. Put them in a named exception group with an expiry date rather than relaxing the policy for everyone.

How to implement

Inventory TPM state: report TPM version, readiness (TpmReadyStatus in the CSP), EK thumbprint and registration join type per device. Find devices registered without a functioning TPM.
Fix credentials first: move certificate profiles to "TPM KSP, otherwise fail" for a pilot ring, set WHfB to require a hardware security device, and confirm no profiles use 4096-bit keys where TPM storage is intended.
Turn on health settings in a separate policy: apply BitLocker, Secure Boot and code integrity requirements to a pilot group, with a grace period, and watch the non-compliance reasons for two to four weeks.
Run Conditional Access in report-only: scope "Require device to be marked as compliant" to pilot users and review the report-only results in sign-in logs before enforcing.
Enforce in rings: IT, then early adopters, then broad, then privileged access paths last because they need the strictest exception handling.
Add Apple attestation: deploy ACME attested certificates and schedule fresh MDA requests after OS updates.
Roll back cleanly: rollback means removing the grant from the Conditional Access policy or moving the group to report-only, not deleting compliance settings, so evidence keeps being collected.

Detection and measurement

Hardware-key coverage: percentage of device certificates and WHfB registrations whose keys are TPM or Secure Enclave backed. Target close to 100 per cent of managed endpoints.
Health attestation pass rate: devices passing all Device Health settings divided by devices evaluated, trended weekly, with failure reasons broken out.
Attestation freshness: median age of the latest health result or Apple attestation per device; alert when it exceeds your freshness budget.
Exception population: count and age of devices in TPM or health exception groups; every entry needs an owner and expiry.
Sign-ins without device claims: successful sign-ins to sensitive apps where no compliant or joined device was presented, which should trend to zero once enforcement is complete.
Integrity regressions: devices whose TestSigningEnabled, BootDebuggingEnabled or code integrity state changes between attestations should go to the SOC, not just the compliance dashboard.

Common failure patterns

Presence check mistaken for attestation: requiring "Trusted Platform Module (TPM)" in compliance only confirms a TPM version is reported. It says nothing about boot state.
Quiet software fallback: TPM-if-present profiles and default WHfB settings let devices with disabled TPMs enrol software keys that are exportable and indistinguishable in logs.
Device-code and unmanaged flows left open: device state is not carried in the device-code OAuth flow, so the compliant-device grant cannot apply there; block device-code flow or require phishing-resistant MFA for it.
Trusting a stale verdict: BitLocker state that is only measured at boot and cached attestations mean a device can stay compliant long after its state changed. Pair attestation with EDR signals.
Management plane compromise: whoever controls the MDM controls the compliance verdict. The Stryker Intune wiper attack shows how one hijacked admin account in the management platform reaches every enrolled device. Protect it as tier 0; see the MDM and UEM platform health check.

Framework mapping

Framework	Reference	How this guide applies
NIST SP 800-53 Rev 5	IA-3 Device Identification and Authentication; IA-3(4) Device Attestation	TPM-bound device keys and health attestation before connection
NIST SP 800-53 Rev 5	SI-7(9) Verify Boot Process; SC-51 Hardware-based Protection	Measured boot claims and hardware key storage
NIST SP 800-53 Rev 5	AC-19 Access Control for Mobile Devices	Apple MDA and compliance-gated mobile access
NIST CSF 2.0	PR.AA-03; DE.CM-09	Hardware is authenticated; device state is monitored for adverse changes
MITRE D3FEND	D3-TBI TPM Boot Integrity	Remote verification of boot measurements; see the D3-TBI TPM Boot Integrity card
MITRE ATT&CK v20	T1550 Use Alternate Authentication Material; T1539 Steal Web Session Cookie; T1542.003 Bootkit	Hardware-bound tokens limit replay from other devices; health attestation can surface bootkit conditions

Practitioner checklist

Report TPM version, readiness and EK thumbprint for every managed Windows device.
Set Windows certificate profiles to "Enroll to Trusted Platform Module (TPM) KSP, otherwise fail" and avoid 4096-bit keys on them.
Require a hardware security device for Windows Hello for Business.
Require BitLocker, Secure Boot and code integrity in Windows compliance, and remember BitLocker is measured at boot.
Use ACME attested certificates on Apple devices and request fresh MDA after OS updates.
Enforce "Require device to be marked as compliant" after a report-only pilot, ring by ring.
Block or separately control the device-code flow.
Keep an expiring, owned exception group for hardware without TPM 2.0.
Send attestation regressions to the SOC as well as the compliance dashboard.

TPM and device attestation for enterprise endpoints