A hardware root of trust is the component of a device from which every other component derives its cryptographic trust. Nothing can detect that it has failed or been altered, so it has to resist both physical and logical tampering. In secure boot, the root of trust is the immutable first stage, usually mask ROM plus key material held in fuses or other hardware-protected storage, and it checks the next bootloader before any mutable code runs.
Hardware root of trust vs TPM: what each scheme anchors
“TPM or hardware root of trust” sounds like a choice between two things, but a TPM is a standardised hardware root of trust, and it does a different job from the boot ROM that verifies firmware. The TCG’s TPM 2.0 Mobile Reference Architecture assigns these roles to different components. The Boot ROM is the Root of Trust for Verification and the start of a transitive chain of verification. The TPM provides confidentiality, integrity and reporting for keys and measurements.
A TPM protects keys, records platform measurements, supports attestation and gives the device an identity. Its Platform Configuration Registers hold measurements that cannot be changed or rolled back, and it signs them so that a verifier can confirm the device is in a known state. The TPM does not collect those measurements itself, though. Another component has to feed it. Under measured boot alone, each module runs whatever its measurement turns out to be. Enforcement, meaning the refusal to run unsigned code, comes from the SoC’s boot ROM checking signatures against a key it cannot be talked out of.
| Scheme | What it anchors | Fits when | Watch for |
|---|---|---|---|
| TPM 2.0 (discrete or firmware) beside SoC secure boot | Non-extractable keys, measured boot, signed attestation, factory-provisioned Endorsement Key and hardware-bound identity | You need remote attestation and per-device identity on a platform that can carry a standard stack | Its interface, latency, cost and integration complexity have limited its adoption in production automotive ECUs |
| Secure element | A separate, highly secure ASIC whose interfaces and security mechanisms are defined by ISO, ETSI and GlobalPlatform standards, Common Criteria certified and protected against hardware and software attacks | High-value keys in hostile physical settings, or when you want credentials provisioned by the part’s vendor so they never pass through the contract manufacturer | Interface limited to APDU messages of at most 256 bytes, so a TPM-style interface has to be mapped on top |
| SoC-integrated HSM (“security island”) | Protected signing keys that the boot ROM calls to verify each firmware stage | Cost-sensitive embedded parts where isolation sits inside the SoC | Isolation relies on firewalls and memory protection, and cryptographic blocks may be shared with the rest of the SoC |
| Silicon root of trust with DICE identity (Caliptra, OpenTitan) | Unique Device Secret in fuses, DICE-derived identity, and measurement of code and configuration bits | You need identity and measurements anchored in silicon you specify yourself | Caliptra is specified for cloud-platform SoCs, not small IoT parts |
Is TPM 2.0 plus secure boot enough for an IoT device line?
TPM 2.0 plus secure boot is enough when the threat model calls for attestation and device identity, and the SoC underneath has an immutable boot ROM that enforces signature checks. That combination covers verification (the boot ROM), measurement and reporting (the TPM), and a hardware-bound identity that resists cloning. A dedicated secure element is worth adding when keys must survive determined physical attack backed by certification, or when you want vendor pre-provisioning to keep keys out of the factory. If the use case only needs boot-time integrity and no runtime trust signal, an SoC-integrated HSM with a verification chain can meet it without either part. EN 303 645 treats a hardware root of trust as one route to strong attestation within secure boot, not the only one, and it lists trusted execution environments and secure elements as examples rather than requirements.
Published reference chains exist to check a vendor’s secure boot dossier against: the TCG mobile architecture traces verification from Boot ROM through initial firmware and the protected environment to the OS boot code, and the OCP hardware secure boot document sets out the ROM-to-mutable-bootloader flow against a fused key hash. NIST SP 800-193 supplies the test to apply at every link: each chain of trust must be anchored in a root of trust, and every root and chain must be immutable or kept intact by integrity protection.
Can one diagram show the chain from boot ROM to signed firmware as it ships?
Draw the single diagram only after engineering has confirmed on production units which secure boot features are enabled. A datasheet lists what a part can do, not how your units were configured. TechnoLynx maps the root-of-trust and secure boot implementation of an IoT or embedded device line against each chain-of-trust stage, checks on production hardware which features are enabled rather than merely available, and turns the result into a single diagram and narrative in the format the reviewer asks for.
Evidence each link of the chain needs
| Link | What it does | Evidence that counts |
|---|---|---|
| Boot ROM and fuses | The immutable first stage compares the firmware signer’s public key against a hash fused at provisioning, then verifies the first mutable bootloader | A readout of key slots and configuration registers from production parts, not only the dev board |
| First-stage bootloader (for example Nordic’s NSIB) | A small, ROM-anchored stage that verifies the next one with an ECDSA-P256 key | The signed image and the key slot it verifies against |
| Second-stage bootloader (for example MCUboot) | Handles A/B updates, rollback protection and image confirmation | Security version numbers in signed metadata and a monotonic anti-rollback store |
| Signed firmware | The executable plus a manifest (version, target, rollback counter) with one signature covering both | The manifest and the signature covering payload and metadata |
| OTA update path | The device checks each update’s authenticity and integrity before installing it | Signature verification, release authorisation and anti-rollback checks per release |
| Attestation | Immutable code measures the mutable code and relevant configuration before handing over control | Signed measurements appraised against reference values |
Nordic’s guidance for the nRF54L15 is to set the debug-lock registers from factory provisioning, not from first-boot firmware, because a bad first-boot image can ship parts with debug left open, while lockdown done by factory tooling can be verified on the test fixture. The OCP attestation specification goes further: configuration that could compromise security, such as fuses or straps enabling JTAG, must be discoverable from the device or make its measurements distinguishable from production measurements.
If the retailer or customer has not specified a format, a sound default is the chain diagram plus a written chain-of-custody narrative, cross-referenced line by line to the EN 303 645 implementation conformance statement, so the reviewer can find each claim where they expect it. Ask the reviewer for their template before drafting.
How do you inject unique device keys at mass-production volume without a factory bottleneck?
Separate the key from the firmware image. The line then programs one golden image and the identity arrives by another route. Device makers have to decide when each device creates its private key and receives its unique X.509 certificate, and the routes differ in who sees the key:
| Route | Who touches the key | Fits |
|---|---|---|
| Unique firmware image per device | The device maker builds each image; the contract manufacturer programs it | Low volumes where each unit is customised anyway |
| Golden image plus injection by the contract manufacturer | The contract manufacturer injects credentials before or after PCB assembly, so it must work in a secure environment with trusted staff | Manufacturers that offer injection and can show controlled custody |
| Pre-provisioned TPM or secure element | The part’s vendor generates keys and signs certificates in its own facility; the contract manufacturer only places the part | Volumes above the vendor’s minimum order quantity, which can make it cost-prohibitive at low volume |
| Provisioning appliance with an HSM on the factory floor | The appliance either injects device secrets or signs certificates for keys the device generates itself | Silicon whose ROM authenticates the appliance during personalisation |
| Two-stage provisioning | Common firmware at the factory; the unique key is issued at first power-up | Lines that must keep their existing production process unaltered |
A 2024 arXiv paper on the OTA-Key scheme cites Intel’s estimate of roughly 20 minutes per device for compiling and installing per-device firmware. The same paper measured about 1 second of key transmission per device for its two-stage approach, which it puts at about one-fortieth of the traditional time. Two caveats come with that result. The scheme is symmetric-key, and stage one shares a product key across the batch until each device swaps it for its own key.
Can your existing contract manufacturer do it? It can if it offers credential injection, but then the contract manufacturer is in the credential path, and the OCP attestation specification advises designing as if the manufacturing environment is hostile and its networks fully compromised. A TPM-generated IDevID or IAK key guarantees the OEM never held that private key.
For Nordic parts, the choice between the vendor’s own provisioning flow and an external HSM-backed injection service comes down to two tests: whether the vendor flow meets line throughput, and whether a customer or certification asks for HSM-grade custody records. One hardware detail should shape the factory plan. On the nRF54L15, KMU slots become effectively one-shot once push- and read-protection are set, so provisioning should be rehearsed on a dev board and the state dumped before production parts are touched.
What audit evidence proves each device got a unique key, and can it map to EN 303 645?
The evidence that each device holds its own key is a per-unit certificate signed by the manufacturer’s CA, which TCG calls definitive evidence that a key belongs to a specific device, alongside the provisioning CA’s audited count of certificates signed. Behind those records, the evidence pack should tie each key to hardware revision, firmware release, manufacturing batch and support period, and record provisioning failures, rework and scrap.
ETSI EN 303 645 V3.1.3 (September 2024) holds 78 provisions, 36 of them mandatory. Its provisions say what must be achieved, not which technology to use. Sensitive parameters in persistent storage must be stored securely (5.4-1), a hard-coded unique device identity must resist tampering (5.4-2), hard-coded critical parameters in source code are forbidden (5.4-3), and keys used for update integrity and for communication with associated services must be unique per device (5.4-4). Provisions 5.4-1, 5.4-2 and 5.4-4 are mandatory where the feature they cover exists on the device. Provision 5.5-8 extends this to secure management of critical security parameters across their whole lifecycle. Secure boot itself is a recommendation: provisions 5.7-1 and 5.7-2 are both marked R, the second conditional on secure boot or another mechanism to detect unauthorised software changes being supported.
A distinction worth getting right in the conformance statement: the manufacturer’s public key used to verify updates is a public security parameter and does not need to be unique per device. Uniqueness applies to the critical security parameters, the secret material.
| Provision | What it asks | Evidence to hand over |
|---|---|---|
| 5.4-1 | Secure storage of sensitive parameters | Key storage boundary and non-extractability |
| 5.4-2 | Tamper-resistant hard-coded identity | Where the identity lives and what protects it |
| 5.4-4 | Unique update and communication keys per device | Per-unit certificates and issuance logs |
| 5.5-8 | Lifecycle management of critical parameters | Rotation, revocation and compromise-handling plan |
The assessment method is ETSI TS 103 701 V2.1.1 (May 2025). The supplier fills in the implementation conformance statement (ICS) and the Implementation eXtra Information for Testing (IXIT); the lab validates the ICS, runs a test group for each claimed provision and gives an overall PASS, FAIL or INCONCLUSIVE, and the assessment can be first, second or third party. Every “N” or “N/A” in the ICS needs a justification. Existing certifications of parts of the device can serve as partial evidence if the lab finds their scope and depth adequate.
Check the version. The 2020 text, published as V2.1.1, had 68 provisions with 33 mandatory. In the V2.1.0 final draft, a physically accessible debug interface had to be “disabled in software”, while V3.1.3 accepts it being disabled or protected by best-practice authentication or access control. The V2.1.0 draft required an update mechanism when the device is not constrained; the current one requires a secure update mechanism unless a resource constraint set by the use case prevents it. The requirement for unique update and communication keys appears in both. Different markets expect different texts: V2.1.1 provisions for UK deemed compliance, V3.1.3 for a current TS 103 701 assessment, and EN 18031 for RED presumption in the EU. Confirming which baseline a retailer is attesting against is its own question, covered in linking the secure boot chain of trust to IoT baseline compliance.
Which supplier holds the key provisioning logs we have to hand over?
First establish who performed the key provisioning: the module vendor, the contract manufacturer or a third-party programmer. Where TPMs or secure elements are pre-provisioned, the module vendor generates the keys and signs the certificates in its own facility. In that case the vendor gives the device maker a manifest of the certificates. Where the contract manufacturer injects credentials into a golden image, the contract manufacturer is responsible for that injection. A distributor or third-party programming house can also provision at component level before assembly. Microchip’s Trust Platform flows for the ATECC608C, for instance, run customer credentials through a Secure Exchange Package deployed to an HSM-based provisioning system.
Whether a chip vendor will issue a standard attestation or compliance letter instead of raw logs is a commercial question, and our sources do not settle it. Treat such a letter as weaker evidence than per-unit records, acceptable to some reviewers and not to others.
For units already shipped without recoverable records, document the gap, assess the risk and gather compensating evidence rather than holding compliance open indefinitely. Compensating evidence can come from the devices themselves. If they carry a provisioned identity, a verifier can check each device’s attestation certificate chain back to the provisioner’s root, which proves provisioning by a trusted provisioner without the original log. Pulling every certificate and spreadsheet into one per-SKU, per-SoC store makes the gaps visible and traceable, but it does not fill them.
Is a pre-certification gap assessment against EN 303 645 worth commissioning?
Yes, for a first submission or a new SoC family: a dry run against the TS 103 701 test groups finds problems while they are still cheap to fix. The method allows first-, second- or third-party assessment. ETSI notes that the generic provisions cannot give specific criteria for every implementation, so the lab’s experience is needed to adapt the test cases. That is the main reason to have an outside reviewer look before the real lab does. A gap assessment is not certification, and passing one does not guarantee the formal verdict.
Several weak points in a boot chain are well documented. The first is a flaw in an immutable boot ROM, which cannot be patched in the field. The others are a missing anti-rollback mechanism for validly signed older firmware, debug lockdown left to first-boot firmware, and update authentication relying on firmware alone, which OCP warns lets exploits persist. Weak update validation or rollback enforcement has enabled persistent ECU compromise in prior automotive research.
Can one assessor cover two SoC families? We would accept one assessor if they show hands-on experience with both families’ secure boot implementations. Otherwise split the work, because a shallow review of an unfamiliar boot chain misses exactly the platform-specific flaws you are paying to find. Findings on one SoC may mean redesign work and a longer timeline.
The retailer wants fuse-level attestation records: firmware change or hardware respin?
We would base the answer on what the SoC’s root of trust exposes. Check that before committing to a remediation path. Some roots of trust measure configuration directly: the OCP attestation specification requires measurements to cover security state and configuration data, with security-compromising settings such as JTAG-enabling fuses made discoverable by pure hardware means. Caliptra is specified to measure and control changes to non-volatile configuration bits. The steps run in this order:
- Query a production unit and establish whether its attestation evidence includes per-fuse or configuration state, or only a pass/fail result.
- If per-fuse state is exposed, confirm the export format matches the retailer’s audit requirement, which may still need extra tooling.
- If only a coarse flag is exposed, record the fuse readout per unit at the test fixture during provisioning and add it to the per-device evidence record; that is a provisioning change, not a respin.
- If neither the SoC nor the provisioning flow can produce the required granularity, a respin with a root-of-trust block that measures configuration is the remaining route.
Microchip’s HSM-based Secure Provisioning System handles the credential flow for its secure elements. Confirm in writing that it can export per-unit records in an auditable format before relying on it. If the retailer wants live, in-field per-fuse verification, step 3 does not satisfy it.
One case forces a respin regardless. When the flaw is in the boot ROM itself, as with the Tegra boot ROM bug published in April 2018, which exposed fuse secrets and allowed arbitrary code execution, the ROM, according to the researcher who published it, accepts minor patches in the factory but cannot be updated afterwards, so the fix needs a hardware revision. Because a respin carries long lead times and high cost, pursue it only once firmware and provisioning options are exhausted.
How do you split one signing root into per-line keys without re-provisioning the fleet?
The tiered model works like this. Hardware holds the root key, or a hash of it, in immutable fuses. That root signs a key manifest, and keys inside the manifest sign the firmware. The fused root keys are used only to sign manifests, which change rarely, while the manifest keys handle frequent firmware signing. The signing HSMs can then be split: the one holding firmware-signing keys is reachable by secure build systems, and the one holding manifest-signing keys stays air-gapped. Automotive signing follows the same pattern, with an OEM root authorising intermediate keys that sign images.
Devices that already verify against a fused root and a manifest can take new per-line signing keys without re-provisioning, through a new manifest signed by the existing root; a leaked line key is confined to that line’s firmware only if the bootloader enforces the line scope as well as the issuing policy. Intermediates are the unit of revocation: a compromised one is revoked and replaced under the same offline root without touching the root.
For devices that hard-code a single key, NIST SP 800-193 lists updating the key store along with the rest of the image as one recovery technique. An immutable root key cannot be modified after manufacture, so for those units we would monitor for misuse and accelerate replacement.
Three details decide whether the hierarchy contains a breach. Set pathLenConstraint to 0 on issuing CAs, so a compromised intermediate cannot mint further sub-CAs. Use separate signing CAs per contract manufacturer or line, so one can be revoked without disturbing the rest. On silicon with OTP revocation, a key manifest ID checked against fused revocation areas lets a new signed manifest retire old keys. Uptane, an automotive update framework, recommends a delegated role per tier-1 supplier, specifically to limit the impact of a key compromise. Before committing, check that the existing HSM’s key slots and policies can hold several scoped intermediates; buy new hardware only if they cannot.
Ship a re-anchoring update before the shared key is suspected. Once it is, an attacker holding that key can push re-anchoring updates of their own. The OTA side of this, signing and attestation anchored to the hardware root, is covered in depth in anchoring OTA signing and attestation to a hardware root of trust.
Who can independently audit a key-provisioning pipeline?
The auditor should be organisationally separate from the team that built the pipeline: a security assessor or test lab with HSM and PKI expertise, reviewing key-ceremony design, HSM configuration, certificate issuance logic and behaviour under concurrent load. TechnoLynx documents the key hierarchy, uniqueness logic and HSM policy, instruments tamper-evident per-device logs, runs load tests with several production lines hitting a shared HSM at once, supports the auditor through the issuance code path, and fixes and re-validates whatever the audit finds.
Precedents for the method exist. TS 103 701 explicitly allows third-party assessment. For CA operations, audits such as WebTrust and eIDAS check scripted root ceremonies run under M-of-N quorum, with recordings and hashed artefacts archived for the lifetime of the certificates. Applied to device provisioning, the provisioner’s CA should be able to show an audited count of certificates signed. Provisioning logs, certificate records, supplier records, test evidence and exceptions should be retained.
Scope the audit deliberately. An HSM’s FIPS 140 or Common Criteria certificate covers the module, not the pipeline’s configuration or its per-device logic. We would use a paper review of configuration for the static question. Whether four lines hitting one HSM fixture can ever batch or reuse a key is a concurrency question that only a load test at peak multi-line throughput can answer. Without tamper-evident logging an auditor cannot fully certify correctness, and conclusions apply only to the configuration snapshot reviewed, so later changes need re-audit.
Decide the fuse map before the first wafer
Several options above depend on the immutable root of trust, which cannot be modified after manufacture. Boot ROM and root keys are often immutable, which sets strong hardware anchoring against future adaptability. Whether the ROM checks a revocable key manifest or a single fused key decides whether a leaked signing key costs you a manifest update or a fleet. Whether security-relevant fuses show up in attestation decides whether a retailer’s granularity request costs you a fixture change or a respin. Those are the questions to settle with the silicon team while the answer is still a design review rather than a recall.
