What is a root of trust?
Every system that verifies things has to start from something it doesn't verify. A root of trust is that starting point: a key, certificate or piece of hardware accepted as trustworthy by design, from which every later check draws its authority. Nothing above it can vouch for it, so it has to be protected by other means, such as physical security, hardware that can't be modified, strict procedures and very limited use. If a root of trust is compromised, everything that depends on it is compromised with it.
Roots of trust in PKI
In public key infrastructure, the roots of trust are the root CA certificates already present in a device's trust store. A browser accepts a website's certificate only because a chain of signatures runs from that certificate up to one of those preinstalled roots. The root certificate is self-signed, so its signature proves nothing by itself; it is trusted because the operating system or browser vendor decided in advance to include it, after audits under its root program. Standards documents call these trust anchors. On Windows, Get-ChildItem Cert:\LocalMachine\Root lists the computer's trusted roots, and Group Policy manages the same store across a domain. Because adding a root lets its owner issue a trusted certificate for any name, an unexpected entry in that store deserves investigation.
Hardware roots of trust
The same idea applies when a computer starts. The first code to run can't be checked by anything earlier, so it lives in hardware or read-only memory that can't be changed in the field. From there, each stage verifies or measures the next:
- Boot ROM and secure boot: immutable code in the processor or platform checks the signature on the firmware, and UEFI Secure Boot then checks the bootloader against keys held in firmware. A component that fails the check doesn't run.
- TPM and measured boot: the Trusted Computing Group defines roots of trust for measurement, storage and reporting. Early boot code records a hash of each later stage in the TPM's platform configuration registers, the TPM protects keys sealed to those values, and it can sign a report of them for remote attestation.
- Dedicated security chips: designs such as Apple's Secure Enclave, Google's Titan chips and Microsoft Pluton build the root of trust into silicon so that firmware attacks can't reach it.
- HSMs: in an organization's own PKI, the hardware security module holding the root CA's private key is the physical anchor of the whole hierarchy.
When the root itself fails
Because nothing checks the root, a weak one undermines every check built on it. In 2024 researchers disclosed PKfail: devices from several manufacturers had shipped with a test Secure Boot platform key, created by a firmware supplier and labeled as not to be trusted, whose private key had leaked. Anyone holding that key could sign malicious boot code that the affected machines would accept as genuine. Replacing a compromised root is slow and disruptive, because the new root has to reach every device, through firmware updates for hardware roots or trust store updates for root CAs.
Root of trust vs. chain of trust
The root of trust is the single anchor accepted without proof. The chain of trust is the series of signed, verifiable links that hang from it, such as root CA to intermediate CA to server certificate, or boot ROM to firmware to bootloader to operating system. A broken link produces an error at that point in the chain; a compromised root makes every chain beneath it look valid.
Root of trust on the CompTIA Security+ exam
Root of trust is part of SY0-801 objective 1.3, the objective on choosing appropriate cryptographic solutions, where it is taught with certificate authorities and PKI. Wording such as "the component every other certificate's trust depends on" or "why a device trusts a certificate it has never seen" points to the root of trust in the trust store. Hardware wording such as "an immutable component that starts the verified boot process" points to a hardware root of trust such as the boot ROM, and "a chip that stores boot measurements and protects keys" points to a TPM. Distractors include intermediate CAs, which are verified rather than trusted by default, ordinary self-signed certificates, and the chain of trust, which is the path rather than the anchor.