A root of trust is the component everything else depends on and which nothing below can verify. Putting it in silicon means device identity and boot integrity derive from the physical part rather than from software that could be replaced — described here at property level, with the threat model and its boundary stated explicitly.
Every security argument terminates somewhere. Software verifies software, which verifies more software, and at the bottom of that chain is something that verifies nothing because there is nothing beneath it. That thing is the root of trust, and the whole edifice is worth exactly what it is worth.
If the root is software, it can be replaced — and an attacker who replaces it inherits every guarantee that depended on it. If the root is in silicon, replacing it means replacing the part, which changes the economics of attack entirely.
Hardware-rooted identity goes one step further than hardware-stored identity. A key written into fuses is in hardware but it is stored, which means it exists at rest and can in principle be read. An identity derived from physical properties of the die is re-derived at each verification and does not sit anywhere waiting to be extracted. That difference is the substance of the distinction, and further detail belongs under a non-disclosure agreement.
| Property | What it means in practice |
|---|---|
| Hardware-anchored identity | The device's identity derives from the physical part, not from software or a provisioned file |
| Verified boot | Each stage from immutable first-stage code onward is verified before it executes |
| Cryptographic subsystem | Symmetric and asymmetric primitives, entropy sourcing and key handling integrated against the power and timing budget |
| Secure provisioning | Credentials applied during manufacture in a flow that is auditable end to end |
| Anti-cloning | Resistance to duplicating a device identity onto other hardware |
| Attestation | The device can produce evidence of what it is and what it is running, verifiable by a remote party |
| Tamper evidence | Physical interference leaves detectable indication |
| Low-power operation | Designed to work inside a coin cell or a contactless field, not only on mains |
Stating the boundary is part of the engineering. A mechanism sold as covering everything covers nothing reliably.
| Threat | Addressed |
|---|---|
| Cloning a device identity onto other hardware | Yes — this is the primary property |
| Forging attestation evidence | Yes |
| Extracting a key that is not stored at rest | Yes, by construction |
| Running unsigned or modified firmware | Yes, via the verified boot chain |
| Downgrade to a vulnerable firmware version | Yes, with a monotonic security counter |
| Application-layer vulnerabilities in signed code | No. A verified boot chain proves the code is the code that was signed, not that the code is correct |
| Information disclosure across a badly drawn authorisation boundary | No. This is an application design problem |
| Supply-chain substitution of the whole assembly | Partially. Identity is verifiable; whether anyone checks it is a system question |
| A determined, well-funded invasive physical attack | Raises cost; does not make it impossible. Assurance is a matter of degree |
No system is described here as impossible to attack. A tamper-evident design is described as tamper-evident, and the assurance level appropriate to an application is established during engagement.
The component a system's security ultimately depends on, placed in hardware so that device identity and boot integrity derive from the physical part rather than from software that could be replaced. Everything above it inherits its assurance.
A key written into fuses is in hardware but exists at rest, so in principle it can be read. An identity derived from physical properties of the die is re-derived at each verification and does not sit anywhere waiting to be extracted. Further detail is discussed under NDA.
No, and claiming otherwise is the common error. It establishes that the running code is the code that was signed and that the device is the device it claims to be. It says nothing about whether that signed code contains an application-layer vulnerability.
Because mechanism, circuit architecture and implementation detail belong under a non-disclosure agreement, and no useful buyer decision depends on their publication. Public material covers properties, threat model, integration and assurance.
Tell us the specification, the constraint and the deadline. Programmes that cross silicon, radio, embedded and AI are where Faststream is strongest.