Hardware Root of Trust Guide: TPM, Caliptra, OpenTitan

Every claim a device makes about its own identity and integrity is only as trustworthy as the first component that cannot be changed by software, and in most estates nobody knows which component that is or who holds its keys. A hardware root of trust (RoT) is that component: silicon and immutable code that measures what boots, protects keys and signs evidence a remote party can verify. The market now has several forms of it, from discrete TPM chips to firmware TPMs, CPU-integrated processors such as Microsoft Pluton, and open silicon designs such as Caliptra for datacentre chips and OpenTitan. This guide explains the root of trust roles, compares the main implementations, shows how DICE layered identity and attestation turn hardware into machine identity, and sets out how to choose, deploy and monitor them. It is written for endpoint, platform and cloud architects and for identity teams that rely on device or workload attestation. For UEFI Secure Boot, bootkits and BMC hardening, see the Firmware and Boot Security Guide; this page goes one layer lower.

Key takeaways

A root of trust is a set of roles, not a chip. Measurement, storage, reporting, update and recovery can sit in one component or several; know which part of your platform performs each.
Keys are the real root. The trust anchor is a key fused into silicon or a key that signs firmware; if that key leaks, as with the MSI Boot Guard keys, the hardware faithfully trusts the attacker.
DICE makes hardware identity renewable. Layered identities derived from a unique device secret and the measured firmware let owners rotate identity and revoke through ordinary PKI.
Attestation is only useful if something verifies it. Evidence from a TPM or Caliptra must reach a verifier that compares it with known-good values and changes access.
Hardware roots of trust anchor machine identity. TPM-resident keys and DevID certificates give servers, laptops and IoT devices identities that cannot be copied, which workload identity systems such as SPIRE can build on.

Root of trust roles

NIST SP 800-193, Platform Firmware Resiliency Guidelines (May 2018), frames platform firmware security as protecting against unauthorised change, detecting change and recovering securely. Roots of trust are the components that make those three possible, and current specifications name their roles explicitly.

Role	What it does	Typical implementation
Root of Trust for Measurement (RTM)	Measures the first mutable code and configuration before it runs	Immutable boot ROM; Caliptra Core in a datacentre SoC
Root of Trust for Storage (RTS)	Protects keys and measurement registers from software	TPM Platform Configuration Registers and protected key hierarchy
Root of Trust for Reporting (RTR)	Signs evidence of the measurements for a remote verifier	TPM attestation keys; DICE alias keys
Root of Trust for Identity (RTI)	Holds a unique, provisioned device identity	TPM endorsement key and certificate; Caliptra IDevID
Root of Trust for Update (RTU)	Authenticates firmware updates and critical data changes	Caliptra Subsystem; platform RoT controllers
Root of Trust for Recovery (RTRec)	Restores firmware when corruption is detected or on instruction	Caliptra Subsystem; dual-image flash with a recovery controller

The Caliptra 2.0 specification describes Caliptra Core as an RTM and Root of Trust for Identity, and the Caliptra Subsystem as adding the update and recovery roles. Using these names in architecture documents makes it obvious when a platform has measurement but no recovery, which is a common gap.

Implementations compared

Implementation	Where it sits	Strengths	Limits to plan for
Discrete TPM 2.0	Separate chip on the motherboard	Independent silicon with its own certification; widely supported by operating systems and attestation tools	The bus between CPU and TPM is a physical attack surface; firmware updates come through the platform vendor
Firmware TPM (fTPM)	Runs in the CPU's secure environment	No extra component; no exposed bus	Shares silicon and firmware with the processor, so processor flaws can affect it
Microsoft Pluton	Security processor integrated in the CPU (AMD Ryzen 6000 to 9000 and AI Series, Intel Core Ultra 200V and Series 3, Qualcomm Snapdragon 8cx Gen 3 and X Series, per Microsoft)	Can act as the system TPM; firmware updatable through Windows Update; Rust-based firmware foundation on 2024 AMD and Intel platforms	Platform and OS specific; check whether a given device is configured to use Pluton or another TPM
Caliptra	Open IP block integrated inside datacentre SoCs (CPUs, GPUs, DPUs, TPUs)	Open specification, RTL and firmware from the Open Compute Project and CHIPS Alliance; DICE identity; classic and post-quantum signing (ECDSA P-384 and ML-DSA-87 in 2.0)	A design you buy inside someone else's chip; ask silicon and server vendors which version and mode they integrate
OpenTitan	Open source silicon RoT, stewarded by lowRISC	Apache 2.0 licensed design; in production silicon and shipping in Chromebooks according to the project	Product availability depends on vendors that build chips from the design
Virtual TPM (vTPM)	Emulated by a hypervisor, one instance per VM	Gives cloud VMs measured boot and sealed keys; Google Shielded VM vTPMs are compatible with the TPM 2.0 library specification	Trust moves to the cloud provider's own hardware root of trust and hypervisor

The TPM 2.0 Library Specification is maintained by the Trusted Computing Group; the latest listed version at the time of checking was Version 185 (March 2026), and an earlier edition was published as ISO/IEC 11889:2015. For identity on constrained devices that cannot carry a TPM, see the IoT Device Identity with TPM and DICE Guide.

DICE layered identity and Caliptra in practice

The Device Identifier Composition Engine (DICE), from the Trusted Computing Group, derives each boot layer's secret from the previous layer's secret and a measurement of the next layer. If any firmware changes, the derived identity changes too. TCG publishes the DICE Attestation Architecture, DICE Certificate Profiles, the DICE Protection Environment Command Response Buffer and DICE Concise Evidence Binding for SPDM, among others.

Unique Device Secret (UDS): in Caliptra the UDS seed is stored as ciphertext in fuses, deobfuscated only on cold boot by hardware, used to derive the identity and then cleared.
IDevID: the manufacturer identity, generated in manufacturing and endorsed by the vendor's provisioning CA, which the specification says is implemented with an HSM connected to high-volume manufacturing flows.
LDevID: a locally significant identity derived with field-programmable entropy (four 8-byte slots in Caliptra), so a new owner can create a fresh identity and validate it using the IDevID.
Alias keys: per-layer keys (FMC alias and runtime alias in Caliptra) that sign attestation for the code actually running.
DICE Protection Environment (DPE): lets Caliptra derive and use DICE identities on behalf of other SoC components, for example as a signing oracle for an SPDM responder or to authenticate to a discrete TPM.

The Caliptra 2.0 specification notes that DICE identities are renewable and fully compatible with PKI, including certificate revocation lists, so a new owner is not burdened with the previous owner's identity. It also records a lesson for buyers: Caliptra 1.0 alone did not protect the IDevID certificate signing request, so a supply chain adversary between the chip and the provisioning HSM could submit its own CSR; 2.0 adds integrity over IDevID CSRs. Ask your vendor which generation they ship and how provisioning is protected. See the Hardware Trojans and Chip Supply Chain Guide.

Where identity fits: hardware-anchored machine identity

A key that is generated inside a TPM and marked non-exportable cannot be copied to another machine; Microsoft's TPM documentation notes this blocks reuse of a stolen key elsewhere. That property turns a root of trust into a strong non-human identity.

Use	Mechanism	Identity benefit
Device certificates for Wi-Fi, VPN and mTLS	Private key bound to the TPM; certificate enrolled through the MDM or EST	Certificate cannot be exported with the user profile
Conditional access on device health	Device health attestation, which Microsoft says requires TPM 2.0 and UEFI firmware	Access depends on proven boot state, not a claim by the agent
Workload identity bootstrap	SPIRE `tpm_devid` node attestor: proof of possession of the DevID key and proof of residency in a TPM whose endorsement certificate chains to the manufacturer CA	Nodes receive SPIFFE identities only if they hold a genuine TPM-resident key
Cloud VM integrity	vTPM measured boot with an integrity policy baseline	Workload credentials can be issued only to VMs that pass integrity checks
Component authentication in servers	SPDM with DICE evidence from Caliptra	The host can verify accelerators and NICs before trusting them

See the Device and IoT Identity Guide and the SPIFFE and SPIRE Guide for the identity side.

Threats a root of trust must withstand

Software reaching secrets: the Caliptra threat model lists software reading UDS, CDIs and private keys as a primary attack, mitigated by key vault isolation in hardware.
Fault injection and probing: clock, voltage, electromagnetic and optical fault injection and microprobing aim to alter early boot decisions; mitigations include environmental monitoring and redundant checks.
Debug and test paths: design-for-test and design-for-debug flows can expose secrets unless debug unlock is managed. See the Debug Interfaces Security Guide.
Firmware signing key compromise: the hardware trusts whatever the vendor key signs. The MSI signing keys leak exposed Intel Boot Guard keys for 116 MSI products, and such keys cannot easily be revoked on devices in use.
Rollback: loading an older, vulnerable but validly signed firmware. Caliptra versions mutable firmware with security version numbers (SVNs) for this reason; check that your platform enforces anti-rollback.
Measurement gaps: code that runs before or outside the RTM is not measured. Caliptra's subsystem mode allows at most eight stashed measurements before its runtime starts and requires attestation to be disabled until the next cold reset if the MCU exceeds that capacity.

Decision guidance

Laptops and desktops: require TPM 2.0 (discrete, firmware or Pluton) and use it for disk encryption keys, device certificates and health attestation. Choose discrete TPMs where physical attacks by a skilled adversary are in scope, and add a pre-boot PIN; choose integrated options where bus exposure is the bigger concern.
Servers you buy: ask whether the platform has a RoT that covers update and recovery as well as measurement, which Caliptra version and mode it integrates, whether attestation uses SPDM and DICE, and how ownership transfer works.
Cloud workloads: you cannot inspect the provider's silicon; use shielded or confidential VM features, monitor integrity reports and tie credential issuance to them.
IoT and embedded products you build: a TPM is not always affordable; DICE with a protected UDS gives a renewable identity on modest hardware.
Small organisations: focus on buying hardware with TPM 2.0 and turning on the features that use it. Large organisations should build a verifier pipeline and record RoT type and firmware version in the asset inventory.

Post-quantum readiness

Identity keys fused or derived in silicon live as long as the hardware, often ten years or more in a datacentre or factory. That is why Caliptra 2.0 endorses its IDevID and LDevID with both ECDSA secp384r1 and the post-quantum ML-DSA-87 algorithm. When you buy long-lived hardware, ask which signature algorithms the root of trust supports for identity and firmware verification, whether hybrid certificates are possible, and whether the algorithm can be changed by a firmware update or is fixed in ROM. See the Post-Quantum Cryptography Migration Guide.

Implementation roadmap

Inventory: record RoT type, TPM manufacturer and firmware version, and attestation capability for every device class.
Baseline: make TPM 2.0 with UEFI firmware mandatory in procurement; for servers add RoT update and recovery and signed, versioned firmware.
Bind keys: move device certificates and disk encryption keys into the TPM, non-exportable.
Pilot attestation: enable health attestation or vTPM integrity monitoring in report-only mode on a pilot ring; tune known-good values after updates.
Enforce: make conditional access or workload credential issuance depend on attestation, with a documented exception route. Rollback is reverting the access policy to report-only, not disabling the TPM.
Operate: track RoT firmware advisories, update baselines after planned changes and investigate unplanned measurement changes.

Detection and measurement

Monitor attestation failures and integrity events rather than RoT health alone. In Google Cloud Shielded VM, for example, integrity monitoring compares each boot with the baseline in separate early boot and late boot checks and writes earlyBootReportEvent and lateBootReportEvent records to Cloud Logging; an unexpected mismatch means stop the VM and investigate.

Coverage: percentage of devices with an enabled TPM 2.0 or equivalent RoT.
Bound keys: percentage of device certificates with non-exportable, TPM-resident keys.
Attestation enforcement: percentage of access decisions or workload credentials gated on attestation.
Unexplained integrity failures: count per month, and median time to resolution.
RoT firmware currency: percentage of devices on the latest TPM or RoT firmware within 60 days of release.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	SC-51 Hardware-based Protection; SI-7(9) Verify Boot Process; SI-7(10) Protection of Boot Firmware; SR-11 Component Authenticity	Hardware protection, boot verification and authentic components
NIST SP 800-193	Protect, detect, recover	Platform firmware resiliency
NIST CSF 2.0	PR.AA-04, PR.PS-02, ID.AM-08	Protected identity assertions, firmware maintenance, life cycle management
MITRE ATT&CK	T1542.001 System Firmware; T1542.003 Bootkit; T1495 Firmware Corruption	Attacks a RoT should detect or prevent
MITRE D3FEND	D3-TBI TPM Boot Integrity; D3-BA Bootloader Authentication	Defensive techniques built on the RoT

Common failure patterns

TPM present, unused: the chip is enabled but no keys are bound to it and no verifier checks its evidence.
Trusting the vendor key without a plan: no process exists for a firmware or Boot Guard key leak, as the MSI case showed.
Attestation with no reference values: evidence is collected but there is no list of known-good measurements, so every update causes alerts and teams turn checks off.
Software-held machine keys: service and device certificates generated in software and exportable, so a backup or image copy clones the identity.
Ignoring ownership transfer: refurbished or redeployed servers keep the previous owner's identity and configuration.
Measurement without recovery: the platform can say firmware changed but cannot restore a good image without manual reflashing.

Practitioner checklist

Document which component performs each RoT role on every device class.
Require TPM 2.0 and UEFI in procurement, and RoT update and recovery for servers.
Ask server and silicon vendors about Caliptra or equivalent integration, SPDM support and ownership transfer.
Bind device certificates and encryption keys to the TPM as non-exportable.
Enable attestation in report-only mode, then gate access and workload credentials on it.
Maintain reference measurements and update them as part of change management.
Track RoT and TPM firmware advisories and enforce anti-rollback.
Plan for firmware signing key compromise, including vendor contact and replacement.

Hardware Root of Trust Guide: TPM, Caliptra, OpenTitan and Device Attestation