Passwords and certificates only matter if you can trust where they started
Every System of Trust Has to Start Somewhere
We live layered on top of trust we rarely think about. Swipe a card, and you're trusting a bank. Hand over a passport at customs, and the officer isn't questioning its authenticity — countries have agreed to trust the issuing authority behind it, a point no longer up for debate. Trace any of these chains back far enough, and you land on a single point that can't be questioned any further. Follow the banking system back, and you hit a central bank. Follow identity verification back, and you hit the original record that first established who you are. If that one point gets compromised, everything built on top of it comes down with it.
The same is true for digital devices. Before a smartphone, a car's control unit, or a factory sensor can claim "I'm authentic and untampered with," there has to be a foundational point where that claim actually begins. In security, that point is called a Root of Trust. When that root lives in hardware instead of software, it's called a Hardware Root of Trust (HRoT).
What Exactly Is a Root of Trust
A Root of Trust is the point in a system that's trustworthy on its own — it doesn't depend on anything else to vouch for it. Every security check eventually raises the question, "but is the thing doing the checking itself trustworthy?" A Root of Trust is where that chain of questions ends. It's the one component you no longer need to ask "who vouches for this?" about — the starting line of the entire security model.
Another way to picture it: think about how trust gets passed down, step by step, every time a device powers on. A tiny piece of code runs first, checks that the next piece of code hasn't been tampered with, and only then hands off execution. That next piece does the same for the one after it. This handoff — each stage vouching for the next — is what's known as a Chain of Trust. The catch is the very first link: who vouches for it? There's nothing before it to check it, so that first link has to be trustworthy by its own nature. That's the Root of Trust.
Where Software Alone Reaches Its Limits
Building that first link entirely out of software introduces a structural limitation. Code is, at the end of the day, a file — and files can in principle be copied, reverse-engineered, or altered. If the very first code that runs when a device boots up (the bootloader) gets tampered with, everything that runs afterward inherits that same shaky starting point — the chain of trust needs re-checking from its very first link.
This isn't just theoretical. In 2020, security firm Eclypsium disclosed a structural flaw in a widely used open-source bootloader. The issue, publicly tracked as CVE-2020-10713 and known as "BootHole," involved a way to bypass Secure Boot — the mechanism designed to verify a device's very first boot stage (NVD, CVE-2020-10713). The affected projects shipped patches quickly, but the episode illustrates a structural point: when the first link in a chain of trust is software alone, it remains a viable target for bypass attempts. That's part of why the security industry moved toward reinforcing that first link with hardware that's physically difficult to alter — and HRoT is the approach that came out of that shift.
How a Hardware Root of Trust Actually Gets Built
This is exactly why the industry moved toward anchoring that first link in hardware. The idea is to build a structure physically embedded in the chip — one that can't be copied or rewritten the way software can — and have that structure verify everything that follows from the moment the device powers on.
In practice, trust gets established step by step:
- The instant power turns on: An immutable verification routine, physically built into the chip, runs first — before anything else can.
- First check: That routine verifies the signature of the bootloader that's about to run. If the signature doesn't match — meaning it's been altered — execution stops right there.
- Second check: Once the bootloader passes inspection, it verifies the operating system, which in turn verifies the applications running on top of it.
- The chain holds: Each stage vouches for the one above it, and because the very first stage is physically unchangeable hardware, the entire chain retains its integrity.
| Software-Based Trust | Hardware Root of Trust |
|---|
| Where trust originates | Stored code or key values | A physical characteristic embedded in the chip |
| Can it be cloned? | Yes — files can be copied | Effectively no — it's a physical structure |
| Can it be tampered with? | Yes — via hacking or firmware manipulation | No, short of physically damaging the hardware |
| A known example | Bootloader-layer bypass attempts (e.g., CVE-2020-10713, later patched) | This class of attack path is largely closed off at the physical layer |
This table is a simplified conceptual comparison — actual security depends on the specific implementation.
One of the core technologies that makes HRoT possible is the PUF (Physical Unclonable Function). A PUF exploits the microscopic, unintentional physical variations that occur during chip manufacturing — down to tiny differences between individual transistors — to generate a value that's unique to that one chip. No blueprint can reproduce it. Even chips stamped from the exact same design in the exact same factory come out with different values, because those manufacturing-level physical variations are essentially impossible to control or replicate. For a deeper look at what PUFs are and how the different types compare, see What Makes SRAM PUF, RO PUF, and VIA PUF™ Different?. An HRoT uses this kind of physical uniqueness as its anchor, physically realizing the "immutable first-stage verification" described above.
Where Hardware Roots of Trust Actually Show Up
This concept is already embedded in everyday technology. A smartphone's secure chip encrypts fingerprint, facial recognition, and payment data on top of an HRoT. A car's electronic control unit (ECU) relies on HRoT to verify the boot process and block unauthorized software from being quietly installed. Industrial IoT sensors, often deployed at massive scale in places no one can physically monitor, increasingly depend on HRoT to prove on their own whether they've been tampered with. In telecom, devices using eSIM — which handle subscriber credentials remotely instead of through a physical, swappable SIM card — lean even more heavily on HRoT to prove device authenticity. Payment terminals and smart cards have relied on this same principle for years.
NIST's guidelines on platform firmware resiliency also address the role of a Root of Trust in exactly this context (NIST SP 800-193). The document identifies an "immutable root of trust" as a core requirement for defending systems against firmware-level attacks — which is precisely the problem HRoT is built to solve.
For a closer look at how an HRoT actually gets implemented and operates inside a real chip, see How VIA PUF™-Based HRoT Actually Works Inside a Device.
Common Misconceptions About HRoT
"Isn't strong encryption enough on its own?" Encryption is a genuinely effective way to protect data, but where and how you store the keys used for that encryption is a separate question. If those keys live only in a software file, that file being stolen can weaken the protection encryption was meant to provide. HRoT adds a physical foundation for storing and handling those keys securely.
"Can't frequent security updates cover this?" Updates are an effective way to close known vulnerabilities, but verifying that an update file is genuine is, once again, a chain-of-trust question. If the logic that verifies updates can itself be tampered with, frequent updating alone can't fully guarantee that what you're installing is authentic. HRoT gives that verification a physical foundation to stand on.
Wrapping Up
A Root of Trust is the one point in a system trustworthy enough that nothing further needs to vouch for it — and a Hardware Root of Trust is what you get when that point lives in hardware instead of software. Software alone can't fully escape the risks of cloning and tampering, which is why real security ultimately comes down to one question: what did you build your foundation on?
If you want to know whether your devices and systems are truly secure, the first question worth asking is this: where does that trust actually begin?
Want to go deeper in Q&A form — including how HRoT compares to TPM/HSM, and alternative implementations like OTP or eFuse besides PUF? Continue with Hardware Root of Trust FAQ — Where Does the "First" Trust Actually Come From?
☑️ Curious how an HRoT architecture could apply to your product or service? Reach out to ICTK to talk through a VIA PUF-based solution. → Contact us
References
Passwords and certificates only matter if you can trust where they started
Every System of Trust Has to Start Somewhere
We live layered on top of trust we rarely think about. Swipe a card, and you're trusting a bank. Hand over a passport at customs, and the officer isn't questioning its authenticity — countries have agreed to trust the issuing authority behind it, a point no longer up for debate. Trace any of these chains back far enough, and you land on a single point that can't be questioned any further. Follow the banking system back, and you hit a central bank. Follow identity verification back, and you hit the original record that first established who you are. If that one point gets compromised, everything built on top of it comes down with it.
The same is true for digital devices. Before a smartphone, a car's control unit, or a factory sensor can claim "I'm authentic and untampered with," there has to be a foundational point where that claim actually begins. In security, that point is called a Root of Trust. When that root lives in hardware instead of software, it's called a Hardware Root of Trust (HRoT).
What Exactly Is a Root of Trust
A Root of Trust is the point in a system that's trustworthy on its own — it doesn't depend on anything else to vouch for it. Every security check eventually raises the question, "but is the thing doing the checking itself trustworthy?" A Root of Trust is where that chain of questions ends. It's the one component you no longer need to ask "who vouches for this?" about — the starting line of the entire security model.
Another way to picture it: think about how trust gets passed down, step by step, every time a device powers on. A tiny piece of code runs first, checks that the next piece of code hasn't been tampered with, and only then hands off execution. That next piece does the same for the one after it. This handoff — each stage vouching for the next — is what's known as a Chain of Trust. The catch is the very first link: who vouches for it? There's nothing before it to check it, so that first link has to be trustworthy by its own nature. That's the Root of Trust.
Where Software Alone Reaches Its Limits
Building that first link entirely out of software introduces a structural limitation. Code is, at the end of the day, a file — and files can in principle be copied, reverse-engineered, or altered. If the very first code that runs when a device boots up (the bootloader) gets tampered with, everything that runs afterward inherits that same shaky starting point — the chain of trust needs re-checking from its very first link.
This isn't just theoretical. In 2020, security firm Eclypsium disclosed a structural flaw in a widely used open-source bootloader. The issue, publicly tracked as CVE-2020-10713 and known as "BootHole," involved a way to bypass Secure Boot — the mechanism designed to verify a device's very first boot stage (NVD, CVE-2020-10713). The affected projects shipped patches quickly, but the episode illustrates a structural point: when the first link in a chain of trust is software alone, it remains a viable target for bypass attempts. That's part of why the security industry moved toward reinforcing that first link with hardware that's physically difficult to alter — and HRoT is the approach that came out of that shift.
How a Hardware Root of Trust Actually Gets Built
This is exactly why the industry moved toward anchoring that first link in hardware. The idea is to build a structure physically embedded in the chip — one that can't be copied or rewritten the way software can — and have that structure verify everything that follows from the moment the device powers on.
In practice, trust gets established step by step:
This table is a simplified conceptual comparison — actual security depends on the specific implementation.
One of the core technologies that makes HRoT possible is the PUF (Physical Unclonable Function). A PUF exploits the microscopic, unintentional physical variations that occur during chip manufacturing — down to tiny differences between individual transistors — to generate a value that's unique to that one chip. No blueprint can reproduce it. Even chips stamped from the exact same design in the exact same factory come out with different values, because those manufacturing-level physical variations are essentially impossible to control or replicate. For a deeper look at what PUFs are and how the different types compare, see What Makes SRAM PUF, RO PUF, and VIA PUF™ Different?. An HRoT uses this kind of physical uniqueness as its anchor, physically realizing the "immutable first-stage verification" described above.
Where Hardware Roots of Trust Actually Show Up
This concept is already embedded in everyday technology. A smartphone's secure chip encrypts fingerprint, facial recognition, and payment data on top of an HRoT. A car's electronic control unit (ECU) relies on HRoT to verify the boot process and block unauthorized software from being quietly installed. Industrial IoT sensors, often deployed at massive scale in places no one can physically monitor, increasingly depend on HRoT to prove on their own whether they've been tampered with. In telecom, devices using eSIM — which handle subscriber credentials remotely instead of through a physical, swappable SIM card — lean even more heavily on HRoT to prove device authenticity. Payment terminals and smart cards have relied on this same principle for years.
NIST's guidelines on platform firmware resiliency also address the role of a Root of Trust in exactly this context (NIST SP 800-193). The document identifies an "immutable root of trust" as a core requirement for defending systems against firmware-level attacks — which is precisely the problem HRoT is built to solve.
For a closer look at how an HRoT actually gets implemented and operates inside a real chip, see How VIA PUF™-Based HRoT Actually Works Inside a Device.
Common Misconceptions About HRoT
"Isn't strong encryption enough on its own?" Encryption is a genuinely effective way to protect data, but where and how you store the keys used for that encryption is a separate question. If those keys live only in a software file, that file being stolen can weaken the protection encryption was meant to provide. HRoT adds a physical foundation for storing and handling those keys securely.
"Can't frequent security updates cover this?" Updates are an effective way to close known vulnerabilities, but verifying that an update file is genuine is, once again, a chain-of-trust question. If the logic that verifies updates can itself be tampered with, frequent updating alone can't fully guarantee that what you're installing is authentic. HRoT gives that verification a physical foundation to stand on.
Wrapping Up
A Root of Trust is the one point in a system trustworthy enough that nothing further needs to vouch for it — and a Hardware Root of Trust is what you get when that point lives in hardware instead of software. Software alone can't fully escape the risks of cloning and tampering, which is why real security ultimately comes down to one question: what did you build your foundation on?
If you want to know whether your devices and systems are truly secure, the first question worth asking is this: where does that trust actually begin?
Want to go deeper in Q&A form — including how HRoT compares to TPM/HSM, and alternative implementations like OTP or eFuse besides PUF? Continue with Hardware Root of Trust FAQ — Where Does the "First" Trust Actually Come From?
☑️ Curious how an HRoT architecture could apply to your product or service? Reach out to ICTK to talk through a VIA PUF-based solution. → Contact us
References