Can You Actually Trust the Silicon? The Hardware Root of Trust, Explained

Blog

August 21, 2026

MIN READ

Device security is now a regulatory mandate. Learn how a hardware root of trust prevents IoT botnets and ensures robust compliance starting right now!

Share this post

TABLE OF CONTENT

A hardware root of trust is the small, tamper-resistant part of a connected device that holds its keys and identity and runs first at power-on, so it can verify that everything loaded after it is genuine. Without one, every security control on the device is running on faith. PSA Certified is an independent scheme that grades how well a chip or device implements that root of trust — from a self-assessed questionnaire up to lab testing against physical attackers. For CISOs buying IoT and OT devices, it turns "trust us, it's secure" into evidence you can check, at exactly the moment regulators across the EU and US are making device security a condition of sale.

What is a hardware root of trust, and what is PSA Certified?

Think of a hardware root of trust as the one part of a device you decide to trust absolutely, because everything else is measured against it. It is a small, tamper-resistant block of silicon and its immutable firmware that stores the device's cryptographic keys and unique identity, and that runs first when the device powers on. Because it starts before the operating system and is built to resist tampering, it can check that the next piece of software is authentic before allowing it to run (secure boot), prove the device is genuine to a cloud service (attestation), and store secrets so malware in the main system cannot read or clone them. If the root is trustworthy, you have a foundation; if a device has no hardware root of trust, every control above it is a hope, not a guarantee.

PSA Certified is a security certification scheme that grades how well a chip, software component or device implements that foundation. It grew out of Arm's Platform Security Architecture and became a formal programme in 2019, backed by Arm and independent test labs; in September 2025 its governance moved to GlobalPlatform, the standards body behind the related SESIP evaluation method. The scheme is built around ten security goals — including unique device identity, secure boot, secure update, anti-rollback, secure storage and attestation — and offers tiered assurance levels so a buyer can match evidence to risk.

It is just as important to know what certification does not mean. PSA Certified gives independent, graded assurance that a specific chip or firmware version implements defined security functions to a stated level of attacker resistance. It does not certify the whole finished product end-to-end, does not promise the device is unhackable, and does not cover the cloud, app or network around it. A certificate is scoped to a named version — a later firmware build or a different integration falls outside it. Treat it as verified evidence about a foundation, not a blanket safety guarantee.

Why does this matter right now?

Because the devices without a real root of trust are being compromised at scale, and regulators have noticed. In June 2025 the FBI issued a public alert about the BADBOX 2.0 botnet, which had infected consumer devices — streaming boxes, projectors, digital picture frames, aftermarket car infotainment units — many of them arriving pre-loaded with malware straight from the factory. Google, in a lawsuit the following month, put the scale at more than ten million infected devices. A verified secure boot anchored in hardware is precisely the control that stops an unauthorised firmware image from ever running; its absence is what let this happen.

The everyday threat is just as telling. Zscaler's 2025 threat research found that the ageing Mirai, Mozi and Gafgyt botnet families still account for roughly three-quarters of all malicious IoT payloads — attacks that thrive on default passwords and unpatched firmware, the exact failures a hardware-backed identity and secure update are designed to prevent. On the industrial side, Nozomi Networks reported that close to half of newly disclosed OT and IoT vulnerabilities in the second half of 2025 carried high or critical severity ratings.

And compliance is turning device security into a condition of doing business. In the EU, cybersecurity requirements under the Radio Equipment Directive became mandatory on 1 August 2025, the Cyber Resilience Act's vulnerability-reporting duties begin in September 2026 with full requirements from December 2027, and in the US the voluntary Cyber Trust Mark label is rolling out. Independent device-security evidence — the kind PSA Certified and SESIP produce — is fast becoming the currency of market access.

What is the real cost of getting it wrong?

For a device maker, the cost is the market itself. Without demonstrable security you can lose CE marking and EU market access, face recalls of shipped units, and hand a competitor the compliance advantage. For an organisation buying and deploying devices, the cost is inheriting someone else's insecure design across your estate: cameras, sensors, routers and controllers that become the soft entry point into your network, or get conscripted into a botnet using your bandwidth and your reputation.

The reason this is hard to see is that a device's security lives below the layer most buyers inspect. You can evaluate an app and a cloud console; you rarely open the firmware. That is where the hardcoded key, the missing signature check or the disabled secure boot hides — and it is why "the vendor said it's secure" is not the same as knowing it is. Certification exists to close exactly that visibility gap, by putting an accredited third party between the marketing claim and your purchase order.

There is also a lifecycle trap. A device you deploy today may run for a decade, and a security foundation that cannot be updated is a liability that compounds. Buying without asking about secure update, anti-rollback and a guaranteed support window means committing to a device you cannot fix in the field — precisely the condition the botnets feed on.

How does a CISO or procurement team actually use this?

Make a hardware root of trust a baseline requirement, not a bonus. In the RFP, require an immutable root of trust, verified secure boot, signed firmware updates with anti-rollback, unique per-device credentials, and secure on-chip key storage — and ban universal default or hardcoded passwords outright, because that single control neutralises the botnet pattern behind most IoT attacks.

Then ask for the certificate, not the brochure. Request PSA Certified or SESIP evidence — and, for industrial and OT components, IEC 62443-4-2 — and check the level, the scope and the exact firmware version, verifying it yourself on the public registry. Match the assurance level to physical exposure: for remote-software threats, a lab-evaluated level is a sensible floor; for devices an attacker can physically touch — meters, medical devices, field controllers, vehicles — insist on the higher levels that test resistance to side-channel and fault-injection attacks. Treat "PSA-ready" or "designed to PSA" as not certified.

Finally, do not outsource all your assurance to a label. A certificate covers a version; your supply chain may not ship that version. Independent firmware analysis and, for high-risk fleets, hardware and side-channel testing on the exact build you are deploying is how you confirm the security actually made it into the box. This is the work SISA's hardware security lab performs — firmware and IoT device testing, and hardware and side-channel assessment mapped to the standards buyers and regulators now expect.

Key takeaways

A hardware root of trust is the tamper-resistant foundation that holds a device's keys and identity and runs first, enabling secure boot, attestation and secure storage; without it, every other control is running on faith.

PSA Certified independently grades how well a chip or device implements that root of trust, across tiered assurance levels — from a self-assessed questionnaire to lab testing against physical, side-channel and fault-injection attacks.

It matters now: BADBOX 2.0 shipped malware on 10M+ devices from the factory (FBI/Google, 2025), and Mirai/Mozi/Gafgyt still drive ~75% of malicious IoT payloads (Zscaler, 2025).

Regulation is making device security a condition of sale — EU RED cybersecurity rules mandatory since Aug 2025, CRA obligations from 2026–2027, and the US Cyber Trust Mark.

For buyers: require root of trust, secure boot, secure update and unique credentials; demand PSA Certified / SESIP / IEC 62443-4-2 evidence with level, scope and firmware version; and independently test the exact build before deployment.

Frequently asked questions

What does a hardware root of trust actually do?

It runs first at power-on from tamper-resistant silicon, holds the device's keys and identity, and verifies that the software loading after it is authentic. That makes secure boot, device attestation and protected key storage possible — the base that everything else's trust depends on.

Does PSA Certified mean a device is unhackable?

No. It gives graded, independent assurance that a specific chip or firmware version implements defined security functions to a stated attacker-resistance level. It does not certify the whole product, the cloud or the app around it, and it is scoped to a named version.

What is the difference between PSA Certified Levels?

Level 1 is a lab-reviewed self-assessment questionnaire. Level 2 adds a time-boxed penetration test by an accredited lab against remote software attacks. Levels 3 and 4 add resistance to physical, side-channel and fault-injection attacks — for devices an attacker can touch.

How does this relate to the EU Cyber Resilience Act?

The CRA and the Radio Equipment Directive tell you what a secure device must do; schemes like PSA Certified and SESIP are how you generate the evidence. A single evaluation can be mapped toward EN 303 645, IEC 62443-4-2 and CRA obligations.

‍