
The TARA Arrives, Its References Don't
Why a TARA loses its references on the way from supplier to OEM, what openXSAM gets back, and why that takes a model.
Read Article
Jens Bühl
8 min readHolistic protection and seamless traceability for cybersecurity, functional safety, and the Cyber Resilience Act
OverviewMethodological excellence and tailored tools for model-based system and software engineering.
OverviewEnterprise software from a single source: AI integration, legacy migration and full-stack development — cost-efficiently and sovereignly hosted.
OverviewCybersecurity is no longer optional for connected products: it is a market access requirement. In the automotive sector, UNECE regulation R155 makes a Cybersecurity Management System (CSMS) a condition for type approval. In the industrial environment, IEC 62443 sets the benchmark for plants, controls and critical infrastructure. Both worlds share the same logic: systematically assess threats, demonstrate security across the entire lifecycle and document it in an audit-ready way. Anyone building products with software and interfaces cannot avoid one or both standards.
ISO/SAE 21434 «Road vehicles — Cybersecurity engineering» (published in August 2021) describes a continuous cybersecurity engineering process across the entire vehicle lifecycle: from concept and development through production and operation to decommissioning.
It applies to electrical and electronic systems in road vehicles, their components and interfaces. It is binding for OEMs as well as the entire supply chain: Tier-1 and Tier-2 suppliers must demonstrably fulfil their contribution to vehicle cybersecurity.
The Tier-1 inherits the OEM’s requirements and must fulfil them demonstrably, often for many variants in parallel. This is exactly where a consistent, reusable TARA becomes either a bottleneck or a competitive advantage.
The Threat Analysis and Risk Assessment (TARA) is the heart of ISO/SAE 21434. It identifies assets worth protecting, derives threat scenarios, assesses damage potential and attack probability, and prioritises the security measures from these.
In practice, TARA rarely fails at the concept level: it fails at scope and maintenance. Spreadsheet-based TARAs age quickly, quality varies depending on who carries them out, and every change effectively restarts the assessment from scratch.
itemis SECURE makes the TARA model-based: threats, attack paths and measures are anchored to a consistent model. AI Assistants propose threats and attack trees, and changes propagate through the model instead of being manually tracked. According to itemis, agentic automation reduces TARA effort by up to 80 %, with full human-in-the-loop control.
The same TARA methodology also underpins the Cyber Resilience Act: details in the spoke Cyber Resilience Act.
Cyber Risk Assessment for Beginners
Cyber risk assessment from first principles: the MoRA methodology in 4 steps, damage and threat scenarios with a single running example throughout, and a guide to building a TARA that stays current as your product evolves.
ISO/SAE 21434 is a standard; R155 is mandatory. UN Regulation No. 155 requires a demonstrated Cybersecurity Management System for type approval. ISO/SAE 21434 is the technical framework manufacturers use to provide this proof.
The deadlines
Without a robust CSMS and without documented TARA, there is no type approval, and therefore no market access. This shifts cybersecurity from a technical recommendation to a commercial prerequisite.
Where ISO/SAE 21434 addresses the vehicle, IEC 62443 covers operational technology: industrial controls, automation systems, energy supply and critical infrastructure. The standard series addresses all roles, from component manufacturer through system integrator to the asset owner who operates the plant.
The fundamental principle is segmentation. Assets with similar protection needs are grouped into zones; communication between zones runs via controlled conduits. This creates a defensible architecture instead of a flat network, often oriented around the Purdue model of manufacturing levels.
Important: the security level is not a single value but a vector across seven foundational requirements. Each zone and each conduit receives its own protection level, derived from the risk, not imposed uniformly.
The short answer: ISO/SAE 21434 for road vehicles and their components, IEC 62443 for industrial automation and OT. The longer answer is more interesting, because many manufacturers need both today.
A supplier building control units for vehicles and for industrial plants faces both standards simultaneously. The good news: the methodological basis is related. Both work risk-based, both require security across the lifecycle, both rely on structured threat analysis.
And both feed into the Cyber Resilience Act, which sits above both as a horizontal EU regulation. One exception is type-approved vehicles: for them, UN R155 governs cybersecurity instead of the CRA, while the CRA applies to products outside type approval and in industrial settings. Whoever sets up their TARA methodology cleanly once serves ISO/SAE 21434, IEC 62443 and CRA from one model, instead of maintaining three separate compliance worlds. For products that simultaneously require ISO 26262 and IEC 61508, HARA and TARA share the same system boundary: safety protects the environment from the system, security protects the system from the environment.
The Future Challenges of ISO/SAE 21434
A comprehensive guide to implementing ISO/SAE 21434 — from organizational cybersecurity governance through TARA, written by itemis and Deloitte.
itemis SECURE is the model-based platform for both standards. Instead of fragmented spreadsheets, a living security model is created: TARA, risk assessment, measure tracking and reporting in one tool, with AI support for threat intelligence and attack trees, and with documentation that passes an audit.
The lever is reuse and maintenance. A TARA modelled once can be scaled across variants, new vulnerabilities flow into the model, and the compliance evidence is a by-product of the work, not a separate effort before the audit.
The AI support is not a bolted-on add-on. The agentic capabilities sit on a deterministic model layer, so the AI does not work in a vacuum but uses the complete TARA context. Via the Cybersecurity Lifecycle Integration, the system connects requirements, architecture components and software vulnerabilities with end-to-end traceability directly in the security model. The heavy lifting runs automated, the expert retains control, and every conclusion is grounded in real engineering data.
| Pillar | Function | Benefit |
|---|---|---|
| Lifecycle Management | End-to-end security traceability across development and product lifecycle | Eliminates virtually all manual documentation work for audits |
| Model-Based Governance | Industry-specific rule sets, plausibility and consistency checks | AI suggestions comply with guidelines and regulatory requirements |
| Agentic Automation | Context-aware, automated generation of TARA elements with human-in-the-loop | Up to 80 % less TARA time |
| Live Vulnerability Sync | Continuous triage of SBOM components and CVEs | Living documents for ISO/SAE 21434, IEC 62443 and CRA |
According to itemis, agentic automation reduces TARA effort by up to 80 %, with full human-in-the-loop control. This way even small teams maintain a living security posture and serve ISO/SAE 21434, IEC 62443 and CRA from one model.
itemis SECURE is used by cybersecurity teams in automotive and industry, including ZF, AVL and Sygic.
A TARA doesn’t stop at the company boundary. The supplier hands its analysis to the OEM, the architecture comes from the modelling tool, and test teams need the risks for their test plans. ISO/SAE 21434 asks for the work products, but it doesn’t prescribe a format for passing them on.
That’s what openXSAM is for: an open, XML-based exchange format for security analyses. It carries item definition, assessment model, damage and threat scenarios, attack steps, risks and controls, along with the references between them. The Automotive Security Research Group (ASRG) maintains the specification and XML schemas publicly on GitHub.
itemis co-founded the format. openXSAM grew out of XSAM, the exchange format of itemis SECURE, in 2020 and has been an ASRG Technical Committee since 2022. itemis SECURE imports and exports the complete analysis and assessment model via XSAM. The article The TARA Arrives, Its References Don’t covers what openXSAM does today.

Why a TARA loses its references on the way from supplier to OEM, what openXSAM gets back, and why that takes a model.
Read Article
Jens Bühl
8 min read
Threat scenario, attack path and attack feasibility belong together: what makes a scenario, why the path gets rated, and how the method shifts the result.
Read Article
Jens Bühl
13 min read
Asset identification and impact rating supply one half of the risk value: when an element of the item becomes an asset, whose damage a damage scenario describes, why the safety rating is not security's to set alone, and what keeps ratings comparable across projects.
Read Article
Jens Bühl
15 min read
The Item Definition sets the quality ceiling for the whole TARA — what abstraction level is right, why SBOM mapping forces a minimum resolution, and why a living model is the foundation for API and MCP integrations.
Read Article
Jens Bühl
9 min read
From risk definition to a living TARA: a 7-part guide to systematic cyber risk assessment, with direct mappings to CRA, ISO/SAE 21434, and IEC 62443.
Download Whitepaper
A TARA is not a threat catalogue — it is an auditable record of risk decisions: what it involves, how the process works, and when Excel reaches its limits.
Read Article
Jens Bühl
6 min readZF and itemis co-develop itemis SECURE, turning real-world automotive cybersecurity engineering challenges into reusable capabilities for catalog-based reuse, versioning, and dependency management.
View Project