A hardware root of trust is the component from which every other component in the system derives its trust. ETSI EN 303 645 describes it as one way to give strong attestation within secure boot. If your device verifies software at boot, something has to be believed without proof. That something is the root.
The definition, in plain words
The ETSI text says a hardware root of trust is reliable and resistant to both physical and logical tampering, because nothing exists that could tell you it had failed or been altered. That last point is the key. Every other check in the chain depends on it, and no later check can notice if it is wrong.
In practice the root is often a piece of immutable code in ROM plus a public key or key hash stored where it cannot be rewritten, such as one-time programmable memory. The exact mechanism varies by chip.
What it is used for
The ETSI provision 5.7-1 says consumer IoT devices should verify their software using secure boot mechanisms. The root starts the chain: it verifies the first bootloader, which verifies the next stage, and so on. Android's Verified Boot documentation uses the same shape, with a chain starting at a hardware-protected root of trust and extending through the bootloader and verified partitions.
A root of trust can also back secure storage of credentials. ETSI says a root can be backed by mechanisms used for secure storage, or by alternatives offering assurance proportionate to the device.
Does your device need one?
The standard itself uses "should" for secure boot, not "shall", and the wording about proportionate assurance leaves room. A reasonable way to decide:
- What could an attacker do with a modified firmware image? A door lock or a medical pump raises the stakes compared with a desk lamp.
- Can the attacker touch the device, or only reach it over a network?
- Would a compromise let them attack other devices, or only this one?
- Do you have a way to recover devices after a bad image?
If the answers are uncomfortable, choose silicon that supports secure boot with an immutable first stage and plan the key management that goes with it.
The weak spot is the key
A root of trust is only as good as the key it trusts. The U-Boot verified boot documentation says it is critical that the public key cannot be tampered with, and that if it can be changed, verification is ineffective. Protecting the signing private key matters just as much, and that is a build and release problem rather than a silicon one.
Quick check
Is secure boot the same as a hardware root of trust?
No. Secure boot is the process of verifying software at startup. The root of trust is the component that process ultimately depends on.
Does ETSI require secure boot?
Provision 5.7-1 says devices should verify their software using secure boot mechanisms. It is a recommendation, not a mandatory provision.
Where Safeguard fits
Safeguard does not replace a bootloader or a hardware root of trust. It covers the software side around them: SBOM and dependency scanning for the components that end up in your builds, policies and gates that block a risky release, and compliance evidence. You can try a free scan at gold.safeguard.sh/scan.
Sources
- ETSI EN 303 645 V2.1.1 (2020-06)
- Verified Boot, Android Open Source Project
- U-Boot verified boot with FIT images
Last reviewed: 19 October 2026.
