Compliance Intelligence for connected and safety- critical products

The HARA (Hazard Analysis and Risk Assessment per ISO 26262) assesses how system malfunctions can endanger people. The TARA (Threat Analysis and Risk Assessment per ISO 21434) assesses how attackers can compromise the system. Both analyse the same system — which is why they share the system boundary.

The key difference: safety protects the environment from the system (against unintended malfunctions), security protects the system from the environment (against deliberate attacks). Methodologically, both work risk-based and across the product lifecycle. A shared, model-based system architecture as the foundation for HARA and TARA significantly reduces redundancy — and is the approach itemis applies in projects with parallel safety and security requirements.

Yes — and it is even methodologically sound and the most efficient implementation. All three require end-to-end traceability from requirements through to verification. itemis ANALYZE implements a tool-agnostic traceability layer across existing tool landscapes — without migrating existing tools.

Safety requirements from the HARA, cybersecurity goals from the TARA and system architecture are linked in the same model. Changes propagate automatically; compliance evidence is generated as a by-product of development rather than as a separate documentation task before the audit. ASPICE mandates bidirectional traceability as a baseline practice — a well-implemented traceability system along these lines fulfils ASPICE requirements while simultaneously delivering the evidence chain for ISO 26262 and ISO 21434.

Excel TARAs age quickly: quality varies by contributor, every change requires manual updates across all linked documents, and consistency is structurally unenforceable. With short development cycles or OTA updates, this does not scale.

itemis SECURE makes the TARA model-based: threats, attack paths and measures are bound to a consistent model. AI assistants suggest threats and attack trees context-awaredly — based on the full TARA history and existing system architecture. Changes propagate through the model. According to itemis, agentic automation reduces TARA effort by up to 80% while maintaining full human-in-the-loop control. The result: a living security model rather than a PDF that is outdated three months after the audit.

Two deadlines are critical: From September 2026, vulnerability disclosure obligations apply for actively exploited vulnerabilities — 24-hour early warning, 72-hour full report to ENISA. From December 2027, all CRA requirements apply: security by design, SBOM obligation, lifecycle responsibility and CE marking with cybersecurity evidence.

Recommended sequence: initial check whether the product falls within scope → establish a vulnerability disclosure process → conduct TARA for all CRA-relevant products → build requirements traceability for the evidence trail → conformity assessment and CE marking. The CRAIG community (itemis is a founding member) offers free scope checks, templates and local networks. itemis SECURE covers the technical implementation — from TARA through to lifecycle management.

Traceability pays off when multiple disciplines are working on a single system, regulatory pressure exists from standards such as ISO 26262, ISO 21434, CRA or ASPICE, and requirements change dynamically. The ROI calculation tips quickly: ASPICE preparations that previously took weeks can be reduced to hours with end-to-end traceability.

It is too early when foundational processes are not yet defined — traceability then just digitalises existing chaos. Or when management commitment is absent: traceability is a cultural change, not a tool rollout. itemis states this clearly in the first conversation — and recommends where to start when traceability is not yet the right fit.

ASPICE (Automotive SPICE) is a process maturity model — it evaluates how well development processes are organised, not what is being built. ISO 26262 is a product-related safety standard for electrical and electronic systems in vehicles. ISO 21434 is the corresponding cybersecurity standard.

The connection: ASPICE mandates bidirectional traceability as a baseline practice for all engineering processes. This is the same foundation that ISO 26262 requires for the safety evidence chain and ISO 21434 for the security evidence chain. Implementing traceability properly once fulfils the process requirements of all three frameworks simultaneously — instead of maintaining three separate compliance worlds.