Software security is only as strong as whatever is running underneath it
Antivirus software, firewalls, OS security patches โ all of that runs on top of something.
But what if the thing underneath had already been tampered with before any of that software even started?
That question is exactly what a hardware root of trust is meant to answer. It tends to get mentioned in the same breath as PUF, TPM, secure boot, and Zero Trust, which makes it easy to mix up. Here are the seven questions people actually ask, in order from the basics to the harder stuff.
Q1. What is a hardware root of trust (HRoT)?
A hardware root of trust is the most basic point in a system that can be trusted without needing to verify it against something else. Software-based trust always depends on some other piece of software checking it โ and if you follow that chain of verification far enough down, there has to be a point where the guarantee comes from something physical instead.ย
NIST defines this foundation in SP 800-193 (Platform Firmware Resiliency Guidelines), breaking it into roles like measurement (RTM), update (RTU), and recovery (RTRec).
In short, a hardware root of trust isn't one specific part โ it's the requirement that trust has to start somewhere physical, plus the architecture built around that requirement.
Q2. Why isn't software security enough on its own?
Software is code, and code can be modified, rewritten, or patched โ including by attackers.
If malware gets into the boot process early enough (firmware, bootloader stage), everything running on top of it โ antivirus, OS security features, all of it โ is already operating in a compromised environment without knowing it.
Once the lowest layer that executes is broken, nothing you stack on top of it can fully undo that.
A hardware root of trust locks down that bottom layer in hardware, so tampering either gets caught immediately at boot or becomes far harder to pull off in the first place.
Q3. How does a hardware root of trust relate to a PUF?
A PUF (Physically Unclonable Function) is one of the main ways to implement a hardware root of trust.
If a root of trust is the requirement โ "trust has to start in hardware" โ a PUF is a technology that satisfies that requirement using the physical manufacturing variation that occurs naturally in semiconductors.
PUFs aren't the only way to do it, though. One-time-programmable (OTP) fuses and eFuse-based key storage are also common. What sets a PUF apart is that it never stores a key at all โ it regenerates one on demand instead.
Q4. What's the difference between a hardware root of trust and a TPM or HSM?
A TPM (Trusted Platform Module) or HSM (Hardware Security Module) is a specific product category that satisfies the hardware root of trust requirement. "Hardware root of trust" itself isn't a product โ it's the role: the point where trust begins.
TPMs traditionally shipped as a separate chip soldered onto the motherboard.
More recently, that role is increasingly built directly into the SoC (an embedded or integrated root of trust) instead of living on a discrete module. Fewer separate components means lower cost and a smaller footprint โ which is exactly why this trend is showing up more in small, low-power devices.
Q5. What real-world attacks does a hardware root of trust actually stop?
Three scenarios come up most often: firmware tampering (swapping out legitimate firmware for a malicious version), bootkit attacks (hijacking the boot process itself), and supply chain attacks (firmware quietly altered somewhere in manufacturing or distribution).
The boot-stage roles NIST SP 800-193 defines โ measurement, update, recovery โ map directly onto these scenarios. If verification fails at any stage, the system either blocks execution or rolls back to a known-good state.
Q6. Do we need to redesign our chip to add a hardware root of trust?
Not necessarily. Plenty of modern SoCs and MCUs already ship with secure boot and other root-of-trust features built in. Rather than a full redesign, licensing a security IP block โ like a PUF โ and integrating it into an existing chip design is a common path to meeting the same requirement.
Assuming it requires starting from scratch is one of the biggest reasons teams delay adopting this. In practice, layering a proven security IP onto an existing design is far more typical.
Q7. Can small IoT devices even fit a hardware root of trust?
Yes. PUF-based roots of trust in particular are often designed specifically for low-power, low-cost IoT chips. Since there's no key sitting in non-volatile memory to protect, you actually save on storage and power โ which works in favor of small devices rather than against them.
๐๐ป Learn More: For low-power, low-cost IoT chips
References
- NIST, "Platform Firmware Resiliency Guidelines" (SP 800-193): https://csrc.nist.gov/pubs/sp/800/193/final
- Trusted Computing Group, TPM Library Specification: https://trustedcomputinggroup.org/resource/tpm-library-specification/
See it in action
A hardware root of trust isn't a single part โ it's a requirement about where trust has to begin, and a PUF is one way to satisfy it. If you're curious how ICTK's VIA PUF meets hardware-root-of-trust requirements in practice, reach out to our team.
๐๐ป Learn More About VIA PUF โ Built to Meet HRoT Requirements
๐๐ป Contact Us
Software security is only as strong as whatever is running underneath it
Antivirus software, firewalls, OS security patches โ all of that runs on top of something.
But what if the thing underneath had already been tampered with before any of that software even started?
That question is exactly what a hardware root of trust is meant to answer. It tends to get mentioned in the same breath as PUF, TPM, secure boot, and Zero Trust, which makes it easy to mix up. Here are the seven questions people actually ask, in order from the basics to the harder stuff.
Q1. What is a hardware root of trust (HRoT)?
A hardware root of trust is the most basic point in a system that can be trusted without needing to verify it against something else. Software-based trust always depends on some other piece of software checking it โ and if you follow that chain of verification far enough down, there has to be a point where the guarantee comes from something physical instead.ย
NIST defines this foundation in SP 800-193 (Platform Firmware Resiliency Guidelines), breaking it into roles like measurement (RTM), update (RTU), and recovery (RTRec).
In short, a hardware root of trust isn't one specific part โ it's the requirement that trust has to start somewhere physical, plus the architecture built around that requirement.
Q2. Why isn't software security enough on its own?
Software is code, and code can be modified, rewritten, or patched โ including by attackers.
If malware gets into the boot process early enough (firmware, bootloader stage), everything running on top of it โ antivirus, OS security features, all of it โ is already operating in a compromised environment without knowing it.
Once the lowest layer that executes is broken, nothing you stack on top of it can fully undo that.
A hardware root of trust locks down that bottom layer in hardware, so tampering either gets caught immediately at boot or becomes far harder to pull off in the first place.
Q3. How does a hardware root of trust relate to a PUF?
A PUF (Physically Unclonable Function) is one of the main ways to implement a hardware root of trust.
If a root of trust is the requirement โ "trust has to start in hardware" โ a PUF is a technology that satisfies that requirement using the physical manufacturing variation that occurs naturally in semiconductors.
PUFs aren't the only way to do it, though. One-time-programmable (OTP) fuses and eFuse-based key storage are also common. What sets a PUF apart is that it never stores a key at all โ it regenerates one on demand instead.
Q4. What's the difference between a hardware root of trust and a TPM or HSM?
A TPM (Trusted Platform Module) or HSM (Hardware Security Module) is a specific product category that satisfies the hardware root of trust requirement. "Hardware root of trust" itself isn't a product โ it's the role: the point where trust begins.
TPMs traditionally shipped as a separate chip soldered onto the motherboard.
More recently, that role is increasingly built directly into the SoC (an embedded or integrated root of trust) instead of living on a discrete module. Fewer separate components means lower cost and a smaller footprint โ which is exactly why this trend is showing up more in small, low-power devices.
Q5. What real-world attacks does a hardware root of trust actually stop?
Three scenarios come up most often: firmware tampering (swapping out legitimate firmware for a malicious version), bootkit attacks (hijacking the boot process itself), and supply chain attacks (firmware quietly altered somewhere in manufacturing or distribution).
The boot-stage roles NIST SP 800-193 defines โ measurement, update, recovery โ map directly onto these scenarios. If verification fails at any stage, the system either blocks execution or rolls back to a known-good state.
Q6. Do we need to redesign our chip to add a hardware root of trust?
Not necessarily. Plenty of modern SoCs and MCUs already ship with secure boot and other root-of-trust features built in. Rather than a full redesign, licensing a security IP block โ like a PUF โ and integrating it into an existing chip design is a common path to meeting the same requirement.
Assuming it requires starting from scratch is one of the biggest reasons teams delay adopting this. In practice, layering a proven security IP onto an existing design is far more typical.
Q7. Can small IoT devices even fit a hardware root of trust?
Yes. PUF-based roots of trust in particular are often designed specifically for low-power, low-cost IoT chips. Since there's no key sitting in non-volatile memory to protect, you actually save on storage and power โ which works in favor of small devices rather than against them.
๐๐ป Learn More: For low-power, low-cost IoT chips
References
- NIST, "Platform Firmware Resiliency Guidelines" (SP 800-193): https://csrc.nist.gov/pubs/sp/800/193/final
- Trusted Computing Group, TPM Library Specification: https://trustedcomputinggroup.org/resource/tpm-library-specification/
See it in action
A hardware root of trust isn't a single part โ it's a requirement about where trust has to begin, and a PUF is one way to satisfy it. If you're curious how ICTK's VIA PUF meets hardware-root-of-trust requirements in practice, reach out to our team.
๐๐ป Learn More About VIA PUF โ Built to Meet HRoT Requirements
๐๐ป Contact Us