For an i.MX-based TCU, secure boot and OTA attestation evidence should reach the OEM as one mapped package, not a set of loose files. In that package, each artefact (signed boot containers, the SRK hash and its fuse record, the closed-chip lifecycle state, rollback configuration, attestation logs) should point at a clause of a recognised baseline and trace back to production units. Secure boot work products map directly onto ISO/SAE 21434 Clause 10 and UNECE R155 Annex 5, which gives the mapping its spine. That package is something engineers build, not a certificate: an auditor reads it, defends it and signs against it.
TechnoLynx assembles this evidence for i.MX-based TCUs under its AI Governance and Trust offer. The work selects the baseline to map evidence against, instruments attestation logging on the target i.MX SoC, and packages the evidence through a repeatable pipeline for OEM submission. The first step is framing the problem: identifying the OEM baseline and PPAP evidence requirements for your TCU.
What the OEM expects to see as secure boot attestation evidence before PPAP
ISO/SAE 21434 requires security assurance cases to prove security conformance. Such a case is a structured argument: a high-level claim broken down into sub-claims, each one backed by evidence. On the supplier side, a cybersecurity interface matrix lists the cybersecurity case as a supplier deliverable. It summarises the evidence that the measures the customer required are in place, and it gives the reasoning for why the item carries no unreasonable risk. The same matrix lists integration and verification reports, including requirements tests, penetration tests, a vulnerability report and hardware and software BOM information.
Confirm your OEM’s PPAP evidence requirements before you assemble anything.
Which baseline the root-of-trust evidence should be mapped against
Map against a stack:
- ISO/SAE 21434 and UNECE R155 for the threat-to-mitigation argument. R155 requires the risk assessment to consider the firmware-modification threats in Annex 5 and to show evidence that they are mitigated. The regulation is technology-neutral, so the evidence has to show your mechanism, not just name secure boot.
- UNECE R156 for the update path. It requires configuration control that records hardware and software versions together with integrity validation data, a protected update delivery mechanism, a protected RxSWIN, and processes that are documented and available for inspection at audit.
- AUTOSAR Secure Hardware Extensions for key storage and the boot-status semantics. The SHE status register exposes SECURE_BOOT, BOOT_INIT and BOOT_FINISHED bits that state whether secure boot was active and whether it finished.
AUTOSAR SHE gives baseline guidance, but HSM capabilities and provisioning workflows still vary considerably across SoC vendors, and the OEM is left to reconcile the differences. In practice, that means your mapping has to state which baseline requirement each i.MX mechanism satisfies, in words that a reviewer who does not know NXP silicon can follow. Teams that also answer to IoT-style baselines can find the chain-of-trust baselines and evidence staleness checks covered separately.
What the i.MX boot chain actually leaves behind as evidence
The authentication scheme depends on the SoC family. The i.MX 8QuadMax, 8QuadXPlus and 8ULP use AHAB, while the i.MX 8M Quad, Mini, Nano and Plus use HABv4. On the i.MX 8 and 8X families, the Security Controller (SECO) and System Control Unit are heavily involved in secure boot. Under HABv4, the BootROM is fully responsible. In both schemes, the hash of the SRK table is fused into OTP eFuse as the secure root key and used to check the SRK table embedded in each signed container.
What shapes the evidence pack is that a chip in the open state keeps booting when verification fails. That makes the SECO or HAB event log (read with ahab_status or hab_status) the check that images were correctly signed against the fused hash. Two SECO codes matter here: 0x0087EE00 means the container is not signed, and 0x0087FA00 means it was signed with a key that does not match the OTP SRK hashes. Closing the chip (ahab_close on AHAB parts) cannot be undone, and after that a closed chip will not boot if verification fails. So the evidence pack should include both the clean event log taken before closure and the lifecycle state read back afterwards. The ahab_status output reports the lifecycle alongside the events.
Two traps catch teams here. A secure boot implementation checklist lists, among common gaps, enabling secure boot in development without recording the production fuse, OTP or configuration state, and treating vendor hardware features as evidence without product-level configuration and test records. NXP also describes its Trusty OS as enablement software rather than a secure production-ready implementation, so that layer needs your own configuration evidence. Then there is silicon revision. CISA advisory ICSA-17-152-02 covered older i.MX families, mitigated in new silicon revisions with an updated ROM. A boot-chain claim that does not name the silicon revision is incomplete.
Evidence map for an i.MX TCU
| Evidence item | Where it comes from | What it shows | Baseline hook |
|---|---|---|---|
| Signed containers and CSF | CST or SPSDK signing output | Boot containers are signed and verified at boot | ISO/SAE 21434 Clause 10, R155 Annex 5 |
| SRK hash and fuse record per unit | CM provisioning record | Root of trust is fused, not a dev key | Secure boot checklist: provisioning evidence |
| Pre-closure event log | ahab_status / hab_status |
No signature or key mismatch events | Open-chip failures do not block boot |
| Lifecycle state after closure | ahab_status lifecycle field |
Device enforces verification | Irreversible closure |
| Rollback configuration | Fuse or counter values, boot manager check | Old signed images are refused | Rollback protection |
| Silicon revision | Device marking or readout | Whether the revision has NXP’s updated ROM | ICSA-17-152-02 |
| Debug lockdown | Fuse and configuration record | JTAG and similar interfaces closed or authenticated | Secure boot checklist |
| Attestation logs | Verifier records | Nonce sent and nonce received matched | RATS freshness |
Rollback deserves a sentence of its own, because it is where manifests mislead. Rollback protection needs a monotonic counter in fused storage plus a minimum-version check enforced by the secure boot manager itself. A design that relies only on the manifest declaring a minimum version can be bypassed by reusing an older, legitimately signed manifest. In NXP’s Secure Provisioning Tool, firmware versions for SB files or AHAB images are configured and checked against fuse or CFPA values, and an uploaded version must be equal to or greater than the stored value.
Reusing a template from an earlier audit
A pack that already passed an OEM audit for a similar i.MX TCU is worth adapting rather than rebuilding, but treat it as a starting structure and not as proof of acceptance. Acceptance under one OEM’s reading of the baseline may not carry to yours, and a template built on a lab prototype may not reflect your production provisioning flow. A pack that passed another audit does not show that your OEM will accept yours.
Linking the NXP datasheet, CM provisioning report and signing logs into one record
The three sources fit together only if one linking document gives every claim a pointer to the artefact that proves it, and a pipeline regenerates that document whenever firmware changes. TechnoLynx’s manufacturing and automotive team builds both parts. It catalogues the three sources and their gaps against the OEM’s or ISO/SAE 21434’s traceability expectations, defines the linking schema and mapping rules, and builds the assembly pipeline that pulls datasheet certification data, provisioning records and OTA signing logs into the document on each release.
One linking document across three suppliers’ evidence
Assurance case research has found that traceability links between the case and the product artefacts are needed but rarely made, even though GSN can reference external artefacts through context and assumption nodes. The same work recommends building supplier cases in an exchangeable format so they can be merged into the product’s case. Where a supplier must keep evidence private, it suggests a black box with meta-information so the overall case still holds. At the silicon layer, part of NXP’s provisioning data, including trust provisioning firmware, is released only under NDA.
We recommend a chain with one row per evidence link. The silicon vendor’s root-of-trust mechanism leads to the SRK hash fused on each unit, then to the signed container that hash verifies, then to the OTA signing event that produced the release, and finally to the attestation record from the field. In RATS terms, claims about an initial layer are typically asserted by an Endorser such as a manufacturer, and each previous layer acts as the Attesting Environment for the next. The linking document is no more trustworthy than the artefacts it links. It does not independently verify the silicon vendor’s root-of-trust claims, and it should say so.
Regenerating the pack on every firmware release
R156 already expects configuration control with integrity validation data per software version. A majority of participants in assurance-case research named traceability and change analysis as main challenges. Regeneration is how both get answered.
The NXP provisioning tool keeps its configuration in a JSON settings file. The provisioning tool’s settings.sptjson stores paths relative to the workspace root so the scripts can be regenerated on another machine, and every field is described in a JSON schema shipped with the tool. A workspace can be exported with its log files and generated scripts. A manufacturing package import requires the tool and package versions to match, so the pipeline has to record the tool version too. The open-source SPSDK library is available for fully customised provisioning workflows, and its signature-provider plugin routes signing to a remote HSM through a simple REST API. That signing service is the natural place to capture the signing log the pipeline consumes.
When to automate depends on the horizon. A single submission can be assembled by the person who owns cross-supplier evidence, mapping each source by hand, while a programme shipping many releases needs the pipeline. If the CM provisioning report arrives only as an unstructured PDF, the honest design is partial automation plus a recorded manual reconciliation step, not a parser that pretends otherwise.
Telling an attestation that never ran from one that failed silently
The difference shows in the protocol records. If no nonce was issued and no quote was returned, attestation never ran, or the logging never captured it. If a quote exists but the verifier never compared its nonce, a replayed or stale quote still appraises as affirming. In the RATS architecture, the appraising party sends an unpredictable nonce, the attester signs it together with its claims, and the appraiser confirms the nonce sent and the nonce received are the same before trusting the claims. One TPM-based implementation follows this pattern, running tpm2_quote over the PCRs with a server-issued nonce. An Entity Attestation Token under RFC 9711 carries the nonce as a claim, alongside UEID, hardware version, OEM boot and debug status. On the i.MX 8ULP, the S400 enclave provides attestation among its platform security services.
Diagnostic checks on attestation logs
| What the logs show | Reading |
|---|---|
| No nonce issuance, no quote | Attestation never ran, or logging never captured it |
| Nonce issued, no quote returned | Attester failed or timed out; ran but incomplete |
| Quote returned, appraisal contraindicated, device carried on | Ran, failed, failure not acted on |
| Quote returned, affirming, no nonce comparison recorded | Cannot be told apart from a replay |
| Open-chip boot with 0x0087FA00 SECO event | Boot verification ran and failed without blocking boot |
The fourth row has a documented instance in a reference verifier. A 2026 study of Project Veraison’s tpm-enacttrust reference scheme found that it appraises the signature and PCR digest but never compares the quote’s qualifying data with the session nonce, so a replayed or stale quote still appraises as affirming. With a fix in place, the same valid quote flipped to contraindicated when replayed into a fresh session. The authors report that every platform-attestation scheme they audited enforces the freshness check in-scheme, while both Veraison TPM schemes, as deployed, skipped it. The lesson for an evidence pack is that “attestation passed” without a logged nonce comparison is not evidence of present state.
Which details show nonce freshness and replay resistance
Check three things in the records. First, the nonce itself: an IETF LAMPS draft requires at least 64 bits of entropy and says nonces must be unique and never reused. Second, the binding: the nonce should be signed inside the evidence, as in a TPM quote’s ExtraData field where the attester binds it. Third, the comparison: the verifier’s record should show the expected and received nonce matching, or a rejection when they differ. Freshness through nonces gives only a rough epoch and needs no trustworthy clock. Epoch IDs from a distributor are an alternative when nonces do not fit the topology. For the signing side of this chain, see how OTA signing and attestation are anchored to a hardware root of trust.
Logs have limits. If the attestation key provisioning or the attesting environment is compromised, attackers can forge evidence and the intended assurance is lost. Fault injection research makes the point concretely. After a glitching attack on AMD’s secure processor let researchers extract endorsement keys, attestation reports validated even though the firmware was not genuine. That work was on AMD Epyc silicon, not i.MX, but it shows why fault-injection results on the TCU’s root of trust matter to the pack.
Should the evidence package get an independent review before it goes to the OEM?
Yes, when this is the first pack for a given OEM or when the engineers who brought up the boot chain also wrote the evidence. Assurance-case quality has two checkable parts: completeness of the claims at each level, and confidence that the evidence actually justifies each claim. A reviewer from outside the team is better placed to test the second part. The OEM will run its own validation of security goals and may do its own penetration testing, so a review before submission is cheaper than finding the gap there. Treat this as a judgement call based on risk and schedule.
Who can assemble and keep our TCU security evidence pack current before PPAP?
TechnoLynx assembles OEM-mapped secure boot and attestation evidence packs for i.MX-based TCUs under AI Governance and Trust, starting by identifying your OEM’s baseline and PPAP evidence requirements. The engagement covers baseline mapping, boot-chain and attestation instrumentation on the target SoC, validation against the mapping, and the regeneration pipeline.
The engagement produces the evidence pack for OEM submission. It is not legal advice, certification or regulatory sign-off, and it does not vouch for the silicon vendor’s own root-of-trust claims. Whether to build in-house or bring someone in depends on whether you already have an engineer who owns evidence across all three suppliers and the time to automate it. A team with an in-house security engineer and a single submission ahead may be better served doing the mapping itself. When choosing a partner, ask to see the inventory and mapping before any tooling, and check that the partner can read SECO events and fuse records, not only write documents. What no template settles is how your particular OEM reads the baseline, so confirm that early.
