Remote attestation addresses a fundamental infrastructure problem: verifying that a host joining your network actually runs the expected software stack. The article explains how a TPM enables cryptographic proof of hardware, firmware, kernel, init image, and root filesystem integrity through measured boot — distinct from secure boot because it relies on signed measurements rather than signed artifacts, catching even malicious signed drivers and rootkits at the cost of considerable complexity.

The mechanism centers on PCRs (Platform Configuration Registers) that irreversibly accumulate hashes during each boot phase. A three-key hierarchy establishes trust: the manufacturer-burned EK (Endorsement Key) proves TPM authenticity, a derived AK (Attestation Key) signs quotes restricted to PCR values, and an LDev ID (Locally-scoped Device ID) child of the AK signs arbitrary data — sealed to golden PCR values so compromised boots cannot use it. The verifier challenges the EK to prove possession of the private key never leaving the TPM.

Upgrade handling uses TPM2_PolicyAuthorize with an Auth Key policy to accept new PCR values, either validated on-device or by a central authority. In production, an RA (Remote Attester) refuses mTLS certificates to hosts failing attestation, while schedulers can demand cryptographic proof before placing workloads. TPM-backed certificates mean tampered hosts naturally lose production access.

This provides bedrock guarantees for initial host state but not runtime security — that requires EDR and LSM policies. Physical attacks like memory taps remain out of scope. The operational burden is substantial: every firmware, init image, and kernel build must be measured and distributed consistently, though the process often reveals hidden supply chain issues and legacy cruft.