ISO 21434 + UNECE R155 compliance with AI — from the TARA to SOP, without rebuilding the file for every audit.

The problem

The TARA lives in a Word file, the controls in an Excel sheet, the production evidence in another system.

The cyber lead of a tier-1 knows the situation: the TARA was done properly at concept and development, the controls were designed, the firmware is signed, the ECUs pass secure boot. But when the OEM's auditor asks “show me that control X was applied to batch Y produced on this line with this firmware version” — the cyber team disappears for three weeks into a reconstruction sprint, cross-referencing design Word documents, validation Excel sheets and production system logs.

1. The TARA — the threat analysis and risk assessment per cyber-relevant asset — lives in design tools and is updated every time a component changes. It is almost never in sync with the firmware coming off the production line.
2. The controls — cryptographic signing, hardening, segmentation, secure boot — are described in project documentation and verified on the bench. The evidence that they were applied to this specific batch is scattered across logs.
3. The tier-2 chain — suppliers delivering electronic components with their own TARA and their own evidence pack — sends signed PDFs, emails, assorted portals. Reconciling the chain down to the final component is manual work.

The result: every audit is a sprint, every OEM complaint is a scare, and responding to a post-SOP vulnerability (an OTA patch for a new CVE in the telematics module) takes weeks to cross-reference against the deployed fleet. The system complies. Complying is expensive, yes. But the real cost is in the late nights before every audit.

How it fits the IRIS system

iLEAN does not write your TARA — it keeps it alive all the way to the production line.

The problem is not a lack of cyber tools (there are plenty, and good ones for design). The problem is that the TARA → controls → production evidence → fleet chain breaks at every jump between systems. iLEAN acts as the putty that fills those cracks, without replacing your cybersecurity suite, your PLM or your MES.

Tracer keeps the TARA ↔ control ↔ batch ↔ firmware link alive. The Agent cross-references it with line data continuously. Writer prepares the 21434 dossier ready per batch. The three rings protect what is critical — OT accepts nothing without a human signature.

The three iLEAN pieces applied to ISO 21434 + UNECE R155:

• iLEAN Tracer — maintains traceability from asset ↔ TARA ↔ control ↔ series production evidence. Every cyber-relevant component coming off the line stays linked to its threat analysis, to the applied control, to the exact signed firmware, to the batch and to the shift. No manual reconstruction.
• iLEAN Writer — prepares the 21434 dossier per batch (or per program, depending on what the OEM customer needs) already formatted against the work products the standard demands. The cyber lead reviews and signs; Writer drafts. The audit sprint disappears.
• iLEAN Agent — cross-references the signals from Edge and the MES (what was produced, with which firmware) against the live TARA and the up-to-date CVE database. When a new vulnerability appears in a component, the Agent identifies which batches/VINs are affected and prepares the response so the cyber team can decide the action (OTA patch, recall, temporary mitigation). It proposes; the person signs. The three rings guarantee that critical OT accepts nothing without human validation.

See the full IRIS architecture →

Before and after

Manual 21434 compliance vs. compliance with iLEAN

Aspect	21434 with documents + sprints	With iLEAN Tracer + Writer + Agent
TARA	Word/design tool, frozen	Live, linked to the batch produced
Evidence per batch	Rebuilt by cross-referencing logs	Dossier ready at every SOP
Tier-2 chain	Signed PDFs, assorted portals	Captured and validated in ring 2
OEM audit	A 2-3 week sprint	Pack prepared, human review
Post-SOP vulnerability response	Cross-reference the fleet by hand against CVEs	Affected batches/VINs identified
R155 type approval	Recurring effort per model	Continuously auditable CSMS

Impact estimate

Impact estimate for your plant — to be validated with your numbers.

The block below is an estimate to be validated with the specific data of your program. We put it forward so the committee has an order of magnitude; we refine it during the diagnostic.

• Tier-1 with a cyber-relevant program for a European OEM under ISO 21434, a heterogeneous tier-2 chain and an R155 obligation in the type-approval cycle.
• Tracer + Writer + Agent pilot on the program's critical cyber-relevant component (typically the central ECU, the telematics module or the gateway). First value expected within a few weeks.
• Reduction in audit preparation effort: ≥30% in the first 6 months (the sprint becomes a review).
• Indicative payback between 4 and 9 months, driven by the current cost of the cyber team dedicated to collecting evidence and by the avoided risk of a delay in R155 type approval.

And the IT cyber director's reasonable doubt

“What if the AI claims a control was applied when it was not, or overlooks a real vulnerability?” — hallucination is a problem of free generation, not of anchored tasks. When the AI merely cross-references the real TARA data, the signed firmware log and the CVE database (pure recontextualization), the best models brought error below 1.5% ^[1]. And even so, the system is protected by the three rings: critical OT (ring 1) never accepts anything without a human signature; ring 2 validates; ring 3 proposes. It is the formalization of what industry already did informally, now with AI as the accelerator.

^[1] OpenAI paper “Why Language Models Hallucinate”, 2025 — on the reliability of AI in anchored tasks.