A device can present a valid user session while its boot state has changed, a security control has been disabled, or an attacker has modified a component that runs before the operating system. Device health attestation gives a management service evidence about the device's boot and security state. Windows exposes this through the Health Attestation service and TPM-backed measurements. The value is not the existence of a TPM; it is the decision a verifier makes from a fresh, validated report.
Windows device health attestation collects boot logs, TPM audit trails, and a TPM certificate from a managed device. The report is protected by the TPM and sent to a remote service for evaluation. Microsoft's documentation describes how MDM and conditional access can use the result to assess whether a device meets the organization's health policy.
Treat the report as evidence
A TPM provides a hardware root for measurements, but the verifier still needs to trust the TPM vendor roots, the attestation service, and the policy that interprets the measurements. Microsoft's Device Health Attestation documentation includes management of trusted TPM roots and certificate packages. A device with a valid TPM report is not automatically healthy if the report describes a state the organization has not approved.
Define the measurements and security settings that matter. A report can include boot state, secure boot, code integrity, and other health signals depending on the platform and configuration. Map those values to a policy with an owner and a documented reason. Do not publish a new baseline simply because an endpoint management dashboard shows a different result.
Record the time of the report, the challenge or nonce used by the verifier, the device identity, the TPM certificate, and the policy version. Reject stale evidence. A signed report from last month may describe a device that has since been reimaged or compromised.
Separate attestation from authorization
The health service returns an assessment. The access control system decides whether the device can use a resource. These are different functions. A device may be healthy enough for email but not for an administrative console that can change production data.
Create policies that map device health, user role, resource sensitivity, network location, and session age to an allowed action. If a device fails attestation, the response might be to block access, allow self-service remediation, require a managed device, or route the user to a support process. The policy should state which action applies and who can approve an exception.
Conditional access can be a useful enforcement point, but it depends on identity and device registration. Test what happens when the device is not enrolled, the TPM is disabled, the attestation service is unavailable, or the device is in a recovery state. A fail-open policy can defeat the control during the exact incident it is meant to handle.
Plan for TPM and recovery operations
TPM ownership, clearing, firmware updates, and hardware replacement can change the evidence a device provides. A TPM clear may remove keys or reset measurements, and a device reimage may create a new TPM endorsement identity. The operations team needs a process for re-enrollment that does not leave an old device certificate trusted indefinitely.
Maintain an inventory of TPM vendors and firmware versions. Review trusted roots and revoke certificates that are no longer accepted. Test attestation after firmware updates and after restoring a system from backup. A device that returns to service with an unexpected boot state should be visible to the monitoring team.
Protect the management service that evaluates health reports. An attacker who can change the policy or mark a device healthy without a valid report can bypass the control. Use strong administrator authentication, change logs, and a separation between the team that manages endpoints and the team that approves access policy.
Investigate failed or changed health
When a device fails attestation, collect the report, the policy decision, and the relevant endpoint logs before remediation. Determine whether the failure is caused by a legitimate update, a configuration change, a TPM issue, or malicious activity. Compare the boot measurements with the expected build and the time of the last approved change.
Check whether the user has a new device, a repaired device, or a virtual machine whose TPM is backed differently from the expected model. Do not assume that a failed measurement means malware. The evidence should support the conclusion.
If a device is compromised, revoke its sessions and credentials, isolate it from sensitive resources, and preserve evidence according to policy. Reimaging may be necessary, but it should not erase the records needed to understand the access that occurred while the device was unhealthy.
Use attestation as one durable signal
TPM-backed health attestation helps a zero-trust program distinguish a managed, measured device from a machine that merely has a valid user password. It does not prove that the user is trustworthy, that the application is free of vulnerabilities, or that the device remains healthy after the report. Those questions require identity, application, and runtime controls.
The useful implementation is a chain: a hardware-backed report, a verifier with a current trust policy, an access decision tied to resource sensitivity, and an operational process for remediation and recovery. Each link needs an owner and a test.