Why Hardware Root of Trust Matters

By Xiphera Ltd.

September 24, 2026

Trust is the foundation of any secure computing system, but that trust has to start somewhere. This article explores the role of a Hardware Root of Trust, why that starting point must be built into hardware, and why it matters more than ever as device lifecycles grow longer, the EU Cyber Resilience Act introduces new security requirements, and the transition to quantum-resistant cryptography moves forward.

1. Introduction: where does trust begin?

Modern computing systems rely on multiple layers of security. Encryption protects data, authentication verifies users, and applications enforce security policies. Yet before any of these mechanisms can be relied upon, the underlying platform itself must be trusted.

This raises a basic question: where does trust begin?

When a device powers on, something must be trusted without being verified, because there is nothing to verify it. This is the root of trust. To ensure its integrity, a strong root of trust is built directly into hardware, making it significantly harder for an attacker to alter or bypass its security functions.

NIST defines roots of trust as highly reliable hardware, firmware and software components that perform specific, critical security functions. Because they are inherently trusted, they must be secure by design, so that they can be trusted without verification.

A Hardware Root of Trust is where the trust chain starts. The root of trust checks the bootloader’s signature before letting it run. The bootloader checks the operating system the same way. The operating system can verify the components it loads next, such as drivers. If any check fails, the sequence stops. No stage trusts the next one blindly, so trust is passed forward rather than assumed. This is known as secure boot. Measured boot takes a different approach: it records measurements of components loaded during startup so that the device’s boot state can later be assessed through attestation.

2. The challenge: software cannot establish its own trust

Security software runs on top of the operating system. The operating system runs on top of firmware. Each layer trusts the one below it.

LoJax, discovered by ESET in 2018, was the first UEFI rootkit found in the wild. It was written into the UEFI firmware of Windows computers and survived operating system reinstalls and even hard drive replacement. This made it difficult to detect or remove with security tools running in the operating system. On every boot, it put the attacker’s malware back into the system. According to ESET, properly enabled Secure Boot would have blocked it, because its firmware module was not validly signed.

Controls in or above a compromised layer may be unable to establish independently whether the platform beneath them can be trusted. Hardware-based security mechanisms can provide a protected foundation for determining whether firmware has been modified and whether software loaded during startup is authentic.

3. What a resilient platform must do

A device without these protections cannot easily detect or recover from attacks. If its firmware is compromised, recovery usually requires manual, often physical, intervention, which is impractical across a large number of devices.

A secure platform exhibits the following capabilities:

• The firmware cannot be changed by unauthorised parties. A new version is installed only if its signature is valid, and the settings the firmware relies on are also protected against unauthorised changes. Older, vulnerable versions cannot be reinstalled either.
• The platform notices if the firmware has been changed without authorisation or corrupted. Protection is never 100% complete, and some parts of a system are harder to fully protect than others.
• The platform can repair itself. If the firmware in use has been altered, the device restores a known good copy, either from protected memory that software cannot write to or from another trusted source that the compromised firmware cannot interfere with. This enables recovery without requiring manual reprogramming of the device.

These capabilities depend on roots of trust that cannot themselves be modified or bypassed by the firmware they are intended to protect. NIST describes distinct roots of trust for functions such as update, detection and recovery.

4. What a Hardware Root of Trust enables

Once a trusted hardware foundation is in place, higher-level security services can be built on it. Many platform protections that look like separate features in fact rely on the same underlying root of trust. Which services are needed depends on the system and its requirements. Some common examples are:

• a unique and verifiable device identity
• protection of cryptographic keys against unauthorised access
• verification of firmware before execution through secure boot
• measurement of platform integrity during startup
• remote attestation

Together, these allow a system not only to start securely, but also to prove its integrity to a remote party.

5. Trust throughout the device lifecycle

Before a device reaches the customer, it has been assembled, shipped and handled by several companies. After that it stays in use for years. A component can be swapped during manufacturing. Firmware can be changed in transit. Both can be changed again during service.

The device needs an identity built into the hardware, and the buyer or operator needs a way to check that identity later: is this the device we ordered, and is it still running what it should be?

This matters most where one device with altered firmware affects a whole service. Cloud and edge infrastructure, industrial automation and telecommunications networks, satellite systems and defence technologies are security-critical environments where the integrity of core elements is crucial.

Regulation is moving in the same direction. From 11 December 2027, products with digital elements placed on the EU market will have to meet the cybersecurity requirements of the Cyber Resilience Act. Manufacturers’ obligations to report actively exploited vulnerabilities and severe incidents have already applied since 11 September 2026. The requirements cover design, development and maintenance, and manufacturers have to handle vulnerabilities throughout the product’s support period. They also include protecting the integrity of software and configuration against unauthorised changes. A Hardware Root of Trust is one way to meet these integrity requirements.

6. Why is Hardware Root of Trust becoming more important now?

Three things have changed.

There are far more devices. A system that once ran on a few machines in a locked room now runs on thousands, spread across geographically distant sites and unsecured environments. Physical security no longer covers them, so each device has to be able to prove its integrity.

Devices stay in service for a long time. A device sold today may still be receiving firmware updates many years from now. The component that verifies those updates has to remain trustworthy for as long as the device is in use.

There is an ongoing transition in the public-key cryptographic algorithms used for functions such as digital signatures. A sufficiently powerful quantum computer could break widely used public-key algorithms such as RSA and elliptic-curve cryptography. The timeline for such a computer remains uncertain, but long-lived devices deployed today may still be in service when current public-key algorithms are no longer considered secure.

This matters for Hardware Root of Trust implementations that rely on digital signatures to authenticate firmware. Long-lifecycle systems therefore need to plan for quantum-resistant algorithms from the start. One way to do this is to support both classical and quantum-resistant signatures in the hardware, allowing the system to transition to quantum-resistant signatures when needed without replacing the platform.

7. Conclusion

A Hardware Root of Trust is not one more security feature added to a platform. It is the foundation that lets every other security mechanism do its job in a trusted manner.

Depending on its implementation, a Hardware Root of Trust can anchor firmware verification, protect cryptographic keys, establish device identity and support platform integrity measurement and attestation.

Firmware attacks keep improving and systems keep getting more connected. Building trust into the hardware needs to be a foundational design decision, not an afterthought.

Explore Xiphera IP:

• nQrux Secure Boot
• xQlave® PQC ML-DSA (Dilithium)
• xQlave® ML-KEM (Kyber) Key Encapsulation Mechanism IP core
• High-Speed Versatile Core for SHA-3-224/256/384/512 and (c)SHAKE-128/256

Sources:

1. NIST, Roots of Trust project. https://csrc.nist.gov/projects/hardware-roots-of-trust
2. NIST SP 800-193, Platform Firmware Resiliency Guidelines, May 2018. https://doi.org/10.6028/NIST.SP.800-193
3. ESET Research, LoJax: First UEFI rootkit found in the wild, courtesy of the Sednit group, September 2018. https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-found-wild-courtesy-sednit-group/
4. NIST CSWP 36B, Using Hardware-Enabled Security to Ensure 5G System Platform Integrity, March 2026. https://www.nccoe.nist.gov/5g-cybersecurity
5. NIST IR 8320, Hardware-Enabled Security: Enabling a Layered Approach to Platform Security for Cloud and Edge Computing Use Cases, May 2022. https://doi.org/10.6028/NIST.IR.8320
6. Trusted Computing Group, TPM 2.0 Library Specification. https://trustedcomputinggroup.org/resource/tpm-library-specification/
7. Trusted Computing Group, DICE Layering Architecture, Version 1.0, Revision 0.19, 2020. https://trustedcomputinggroup.org/wp-content/uploads/DICE-Layering-Architecture-r19_pub.pdf
8. Trusted Computing Group, DICE Attestation Architecture, Version 1.0, Revision 0.22, December 2020. https://trustedcomputinggroup.org/resource/dice-attestation-architecture/
9. NIST SP 1800-34, Validating the Integrity of Computing Devices, December 2022. https://doi.org/10.6028/NIST.SP.1800-34
10. Regulation (EU) 2024/2847 (Cyber Resilience Act). https://eur-lex.europa.eu/eli/reg/2024/2847/oj
11. NIST IR 8547, Transition to Post-Quantum Cryptography Standards, Initial Public Draft, November 2024. https://doi.org/10.6028/NIST.IR.8547.ipd