An IoT chain of trust is a sequence of checks. Immutable boot ROM code verifies a signed bootloader against a root public key (or its hash) stored permanently in the chip, the bootloader verifies the kernel, and no stage hands control to an image that fails verification. Having that chain working on your hardware is necessary, but it is not yet compliance evidence.

How the IoT chain of trust runs from boot ROM to kernel

The first stage runs from the boot ROM, the immutable code that acts as the hardware root of trust. It initialises the hardware, finds the next boot image in non-volatile memory, loads it and checks its integrity and authenticity with the Root of Trust Public Key, an OEM key stored immutably either as a hash or in full. Execution continues only if the image verifies, and each later stage runs the same check on the next image until the kernel is loaded. The Open Compute Project’s secure boot document states the same thing as a rule: the first stage must be an immutable source such as mask ROM that enforces authentication of the next, mutable bootloader.

The signer’s public key, or a hash of it, is fused into the processor at provisioning. At power-up the ROM checks that the public key shipped with the bootloader hashes to the fused value, then uses that key to verify the bootloader’s signature against a freshly computed hash. Multi-stage chains should carry security version numbers in their signed metadata. The device also has to refuse older firmware that is validly signed, using monotonic counters or fused anti-rollback values.

NIST SP 800-193 gives a formal definition of the term. A chain of trust is a sequence of cooperative elements anchored in a root of trust, each passing the same trust properties to the next as it hands over control, and the chain ends the moment control passes to code that is not or cannot be verified. The guideline splits the root into three logical roles: a Root of Trust for Update that authenticates firmware changes, one for Detection of corruption and one for Recovery. These need not be separate components. Measured boot is the complementary record: each stage measures the next and stores the result in tamper-resistant storage such as a TPM, so a verifier can later tell whether the software that started was authentic and current.

Verified boot and measured boot answer different questions. Verified boot shows whether the device refuses an image that fails verification. Measured boot records what software actually started on a given unit. For root-of-trust selection and key provisioning, see root-of-trust selection and provisioning at scale.

The artefacts a working chain gives you

• Fuse state: the root key hash and the revocation and anti-rollback values held in one-time-programmable storage.
• Signed images: the bootloader and the kernel or FIT image, each verified by the stage before it.
• Negative tests: a modified or older image presented to the device and rejected.
• Measured-boot quotes and event logs, where the device has a TPM or equivalent hardware.
• The silicon vendor’s boot sequence and, usually, its crypto libraries and security services.

Which baseline should IoT chain-of-trust evidence be traceable to?

Chain-of-trust evidence should trace to the baseline named by whoever is judging the product. For consumer IoT, the most widely used baseline is ETSI EN 303 645. For radio equipment sold in the EU, EN 18031 is the harmonised route under the Radio Equipment Directive. NIST SP 800-193 is a firmware resiliency guideline whose principles, NIST says, apply broadly to IoT and embedded devices with updatable firmware. The applicable one needs confirming in writing before any evidence is gathered.

TechnoLynx’s AI Governance and Trust work takes the confirmed baseline and maps your chip, secure boot chain and OTA signing evidence to it clause by clause. TechnoLynx then assembles the package and runs the gap assessment. The first step is pinning down which standard the retailer or authority actually means.

ETSI EN 303 645 is the consumer IoT baseline worth citing

Its current version, 3.1.3, was adopted on 11 September 2024. It is called the most widely used and referenced standard in this area, and 9 of the 14 countries in one study reference it. Its provisions describe outcomes rather than prescribing how to reach them, which leaves manufacturers room in how they meet them.

Provision 5.7 says the device should verify its software using secure boot, and names a hardware root of trust as one way to provide strong attestation, not the only way. In the conformance table, provision 5.7-1 is marked as a recommendation. Citing EN 303 645 therefore does not show a hardware root of trust. If the retailer’s requirement is specifically hardware-anchored, the evidence has to show the fused key and the ROM check, not just the standard’s name. Any recommendation judged not applicable or not fulfilled needs a recorded justification. Table B.1 gives the schema for recording it, so assessors and retailers can check the reasoning.

Signed OTA updates fall under provision 5.3, keep software updated. Where updates arrive over a network interface, the device shall verify the authenticity and integrity of each one through a trust relationship, using best practice cryptography.

Confirming which scheme the retailer is attesting against

A retailer asking for “a recognised baseline” may have any of several schemes in mind. PSA Certified, for example, builds its certification around root of trust, attestation, secure boot, isolation, secure update, storage and cryptography. Even a single baseline can sit at different assurance levels. According to the CSA’s 2025 report, Singapore’s labelling scheme accepts a developer’s declaration of conformance to ETSI EN 303 645 at Tier 1, while Tier 4 adds mandatory penetration testing by a CLS-approved third-party laboratory. For any other scheme, its own documents decide, because a crosswalk shows similarity, not equivalence.

The cheapest control in the whole exercise is a written reply from the retailer’s compliance contact naming the standard, its edition and whether self-declaration is acceptable.

EN 18031 for radio equipment under the RED delegated act

EU market-surveillance authorities judge radio equipment against the Radio Equipment Directive (RED), not against EN 303 645. Commission Delegated Regulation (EU) 2022/30 switches on the cybersecurity requirements in Article 3(3)(d), (e) and (f) of the RED, and those requirements have applied since 1 August 2025. The three parts of EN 18031 split those requirements between them:

• EN 18031-1: network protection, Article 3(3)(d).
• EN 18031-2: data protection and privacy, Article 3(3)(e).
• EN 18031-3: fraud protection where the equipment handles money or virtual currency, Article 3(3)(f).

Their references were published in the Official Journal on 30 January 2025 under Implementing Decision (EU) 2025/138. That gives a presumption of conformity from 1 August 2025, in some cases with restrictions.

ETSI EN 303 645 gives no presumption of conformity for those RED articles, because it is not cited in the Official Journal for them. EN 18031 includes informative mappings to ETSI EN 303 645, so a product that already meets it starts ahead, but the mappings do not close the gap. Module A (internal production control, with no notified body) is available only when the relevant EN 18031 part is applied in full and no Official Journal restriction is triggered. A manufacturer that applies it partly, or not at all, must involve a notified body. One restriction applies regardless of design: the Part 3 secure-update assessment criteria give no presumption, so a device handling monetary value has to demonstrate secure update another way.

Under Regulation (EU) 2019/1020, inspections and fines come from a national authority, which can demand technical documentation, access embedded software and take samples. Penalties are set in national law, so exposure differs by country. The authorities’ first question will be for the technical file. The realistic target is therefore a file that covers the selected EN 18031 parts, the conformity route and the evidence behind each decision.

Does the existing chip and secure boot design already meet the baseline?

Only a gap assessment can answer that. SESIP guidance gives a first sort. For each provision, decide whether you developed it fully, developed it while relying heavily on other parties’ capabilities, or depend entirely on third-party IP. For secure boot, silicon manufacturers deliver the hardware and the boot sequence.

Certified component evidence covers the security guarantee the component provides. SESIP is explicit that this is not conformance to the EN 303 645 provisions as such, because the device application meets the provisions by using those guarantees. A datasheet describing a ROM signature check does not show that your product burned the key-hash fuses, enabled enforcement or locked the debug interface.

Mapping chain-of-trust evidence to EN 303 645 and NIST SP 800-193

The table maps each artefact to the clauses it most directly serves. EN 18031 is not in the table: which part applies depends on product facts (radio, internet, personal data, monetary value), and the standards have to be bought.

Fused root key hash and ROM check of the bootloader	Provision 5.7: secure boot, with a hardware root of trust as one means	Security mechanisms founded in a root of trust that anchors the chain
Bootloader and kernel signature checks, tampered image rejected	Provision 5.7 test cases on secure boot design and implementation	Detection: integrity verification of firmware before execution
Signed OTA verification on the device	Provision 5.3: verify authenticity and integrity of each network update	Protection: update root with a FIPS 186-4 signature check and a key store
Signing key strength and signer authority	Provision 5.3: best practice cryptography for updates	Images signed by an authorised entity at 112-bit security strength or more
Anti-rollback counters or fuses	Update-misuse tests include installing an older vulnerable version	Authenticated update must be able to prevent unauthorised rollback

NIST SP 800-193 says its principles should be broadly applicable to IoT, embedded and mobile devices with updatable firmware. A platform counts as Protected when its critical devices meet the guidelines in Sections 4.1 and 4.2. It counts as Recoverable when they detect corruption under Sections 4.1 and 4.3 and recover under Sections 4.1 and 4.4.

Is an internal evidence pack enough, or do we need an independent lab?

That depends on who is accepting the evidence and through which route. For EN 303 645, the conformance assessment specification ETSI TS 103 701 is written to support three kinds of assessment: first-party self-assessment, second-party assessment by user organisations, and third-party assessment by independent testing organisations. Germany’s BSI says the same thing more plainly: manufacturers can use the specification for a self-assessment or have a test laboratory evaluate the product. EN 303 645 itself notes that third-party assessment is likely to need architectural design documentation, threat models, lifecycle and supply-chain policies and component certificates, as the test regime defines.

When a lab is involved, the mechanics follow TS 103 701. The manufacturer claims provisions in the Implementation Conformance Statement and supplies design detail in the Implementation eXtra Information for Testing (IXIT). The lab then runs the test group for every provision claimed “Yes”. It gives a test group a pass only when every test case passes or when adequate external evidence substitutes for them. For provision 5.7, the IXIT describes each secure boot mechanism by ID, description, security guarantee, detection mechanisms and user notification. The test cases assess the design of those guarantees first, then the implementation against them.

Under the RED, Module A self-declaration is open only under the full-application conditions above. Where EN 18031-3 clause 6.3.2.4 applies, third-party conformity assessment is mandatory. How to structure an internal pack so it holds up is covered in building a defensible evidence pack for audit and procurement review.

How do you link each requirement to the exact test report and firmware build?

Each secure-boot or root-of-trust requirement should carry a machine-readable key that pairs the requirement ID, the test report ID and the hash of the firmware build the test ran on. That way a script, not a person, can say whether the evidence still describes what ships.

TechnoLynx builds that traceability under its AI Governance and Trust offer. TechnoLynx defines the key schema and connects it to the HSM or TPM log store and the chain-of-trust verification tooling, so build hashes are captured with every build. TechnoLynx then runs the staleness check inside the release pipeline. The first step is agreeing the requirement-to-evidence schema with whoever owns the compliance checklist.

With that key in place, finding the lab report behind line 14 of the checklist takes one lookup instead of a search through shared drives. Screenshot-based capture breaks the link: a pasted image of a boot log cannot be tied to a build hash or re-checked by a machine.

A report with the right title can still describe the wrong build

QIMA’s comparison of EN 18031 and EN 303 645 sets out three tests that reused evidence has to pass:

• Claim: what conclusion must this evidence support?
• Boundary: which device, app, service, interface and dependency did the assessment cover?
• Traceability: does it match the hardware, software, configuration, market variant and standard edition under review?

The same source makes the point that matters for secure boot. A mapping can show that two clauses both discuss secure updates, but it cannot show that the same update mechanism, signing key, failure behaviour and firmware version were assessed. It concludes that evidence reuse is a configuration-control problem before it is a standards-mapping problem: a test report produced on a development build does not cover a later release. PSA Certified certificates record the evaluation date and the specific hardware and software versions evaluated.

Reusing existing TPM or HSM attestation data

TPM attestation data can be reused as chain-of-trust evidence if it carries three things: a signed quote, an event log, and reference values for the build. In TPM-based attestation, platform configuration registers, quotes and logs give cryptographically authenticated evidence of what software started during the boot cycle. The verifier recomputes the composite hash from the event log and compares it with the quote signed by the TPM’s attestation key. It then checks each logged measurement against expected reference values. The IETF draft is clear that a device should not be trusted if the signature, nonce, PCR-to-log match or reference values fail. It also stresses that signed evidence is of little value without cryptographic proof of which device produced it. The reference values themselves must reach the verifier signed by the software authority, often the manufacturer.

Two limits decide whether new instrumentation is needed. First, the first measurement into PCR[0] is made by the Root of Trust for Measurement, which by definition cannot be verified by measurement. Second, an attestation log reports what software started, not that the boot chain rejects a bad image. The enforcement test (a tampered image presented and refused) still has to be run and linked separately. Other hardware roots of trust include ARM TrustZone and secure elements such as NXP’s EdgeLock SE05x.

When shipping firmware is newer than the tested build

A requirement whose only evidence relates to an older firmware revision is unverified for the build that ships. We would treat it that way until an impact analysis or a re-test says otherwise. Common Criteria’s assurance continuity rules handle this case formally. The developer records an impact analysis covering which evidence the change affects and the regression testing done. The evaluation authority then classifies the change as minor or major. A major change needs re-evaluation by an independent evaluator, reusing earlier results that still apply. PSA Certified advises that a design change be analysed for its potential to affect security, and that a potential effect trigger a review of whether the certificate should be renewed. Maintenance of this kind covers the effect of your own changes, not new attack methods discovered since certification.

Decision table: evidence state versus shipping firmware

Evidence state	Treatment
Linked report exists and its firmware hash matches the shipping build	Mark the requirement verified
Hash differs; the change touches no boot-chain, key or update component under a written equivalence policy	Record the impact analysis; re-test not required
Hash differs; the change touches the bootloader, kernel signing, keys or the update path	Re-test, re-link, and review any certificate built on the old build
No linked evidence	Block submission until the test is run and linked

A firmware re-spin that leaves the boot chain unchanged may not need re-testing, but only if a written policy defines in advance what counts as equivalent. Without that policy, every re-spin becomes an argument.

Who can map our secure boot evidence to EN 303 645 or EN 18031?

TechnoLynx, under AI Governance and Trust, confirms which baseline applies, maps the fuses, boot chain and OTA signing to its clauses, closes the gaps left by supplier documentation, and wires requirement-to-build traceability into the release pipeline. Whether to do it in-house depends mainly on whether your team has firmware security engineers who know the silicon’s boot ROM, plus someone who has worked closely with TS 103 701 and EN 18031. A useful test of any partner is whether they can trace one requirement to one build hash on your own hardware before any scoping document is signed. The engagement starts with a written scope of the applicable baseline.

The work produces evidence artefacts as an engineering output. It is not certification or policy advice. Under TS 103 701, existing certifications or third-party evaluations of parts of the device can be offered as evidence, and the lab verifies whether they are adequate. Where silicon ships with a SESIP-certified secure boot component, the testing party can trust its evidence and focus on verifying the mechanism. Where the same devices also run on-device models, see our AI engineering for IoT and embedded devices.

FAQ

What is a notified body in the EU?

Under the Radio Equipment Directive, a notified body examines the product type (Module B+C) or supervises a full quality-assurance system (Module H). For the cybersecurity requirements, a manufacturer needs one whenever EN 18031 is not applied in full.

What is the difference between an HSM and a TPM?

A TPM is a security coprocessor in the device that stores keys and platform measurements and can attest to the system’s state. In a secure boot flow, an HSM is where the manufacturer keeps the private signing keys, ideally offline and with restricted use.