Holistic protection and seamless traceability for cybersecurity, functional safety, and the Cyber Resilience Act
Overview
Methodological excellence and tailored tools for model-based system and software engineering.
Overview
Enterprise software from a single source: AI integration, legacy migration and full-stack development — cost-efficiently and sovereignly hosted.
Overview
Jens Bühl
9 min read
The Item Definition is the step of a Threat Analysis and Risk Assessment (TARA) under ISO/SAE 21434 that I see underestimated most often in practice. The standard names exactly one prerequisite for the actual risk analysis: the Item Definition as a work product. Yet many projects spend only a few hours on it and weeks on the threat analysis instead. In my experience, this is exactly where the ceiling on how good a TARA can become gets set, long before the first threat scenario is written down.
The standard asks for exactly three things at this point: the item boundary, the item’s functions, and a preliminary architecture. Item boundary means the line that separates the item, the system or assembly of components that realizes a function at vehicle level, from its environment, described through the interfaces to other items in the vehicle and to systems outside it. The preliminary architecture is the item’s provisional internal structure: which components it consists of, how they are connected, what data flows and is stored, and which interfaces lead outward. Modeled properly, it is described through five element types: functions, components, channels, data flows, and data.
Then there’s the description of the cybersecurity-relevant circumstances and the assumptions you rely on. I find the standard’s own example telling: that every PKI certificate authority the item depends on is properly operated. Where these assumptions end up living matters less to me; in practice they often don’t hang off the item itself but off the place where they take effect, meaning the scenarios and ratings of the analysis. What matters is that they’re documented and linked to the analysis.
The standard doesn’t put this step first by accident: every following step builds on it. Assets are elements of the item. Threat scenarios violate security properties of those assets. Attack paths run along the channels and interfaces the architecture describes. And the verification step explicitly checks the analysis’s completeness against the Item Definition. Completeness can only be measured against a defined item. Measured against a fuzzy item, every analysis is “complete”, and that’s exactly the problem.
The standard has a back door, by the way, and it comes at a price. If information is missing from the Item Definition, the analysis is allowed to work with assumptions. But if the decision to accept a risk rests on such an assumption, the standard requires a documented cybersecurity claim. An assumption that isn’t recorded anywhere is an unauditable claim that just hasn’t been caught yet.
Scoping the subject of analysis isn’t an automotive quirk. IEC 62443-3-2 opens its risk assessment for industrial automation systems with the same step: first bound the system under consideration, then break it into zones and conduits and assess those. In rail, the same zone-and-conduit thinking gets applied to security architectures. And anyone setting up a risk analysis for the Cyber Resilience Act needs the same scoping before the first threat can be named in any meaningful way: which product, which interfaces, which environment. And the pattern itself isn’t even new: threat modeling tools like the Microsoft Threat Modeling Tool have been drawing data flow diagrams with trust boundaries since the early 2000s, long before ISO 21434 or IEC 62443 made this step a normative requirement.
I’m sticking to ISO 21434 in this article because it describes the step very clearly. The thinking still carries over: what comes next about abstraction level, resolution, and the living model applies just as much to an IEC 62443 analysis or a CRA risk analysis.
I hear this question a lot, and the answer is: yes, you’re allowed to. You have to, in fact. The Item Definition isn’t a copy of the E/E architecture, and anyone who tries to fold in every detail ends up analyzing the documentation instead of the risk.
I haven’t found a universal rule for this. In practice, I check it this way: a detail belongs in the Item Definition if it can change an asset, a threat scenario, an attack path, or a rating. If it can’t change any of those, it’s architecture documentation, not Item Definition.
The catch: every omission is a silent assumption. And wrong assumptions let real threats quietly fall out of the analysis. I’m not the only one saying so: Katja Tuma and Mathias Widman call this out as its own problem area in their IEEE article on the seven pain points of TARA practice, because the abstraction level and the assumptions behind it are among the hardest decisions in the whole method.
This is exactly where the first advantage of a model-based approach shows up. In a model, the abstraction decision is explicit: the boundary is an element, assumptions are their own objects attached to the analysis, and a reviewer can see what was left out. In a diagram pasted into a document as an image, the omissions are invisible.
The abstraction test above gives you a ceiling. Vulnerability management gives you a floor, and that side gets talked about less often.
When a CVE lands tomorrow, the question is: which component of my item runs the affected package, and which threat scenarios and attack paths does that touch? Answering it requires a chain you can actually follow: the CVE affects a software package. The package runs on a component of the item. The component hangs off channels that attack paths run along. And at the end of those paths sit the threat scenarios whose risk now needs reassessing. The Item Definition either establishes each of these links, or it doesn’t. If it models the ECU as a single box, the chain breaks at the very first link: the package finds no component to attach to, or the details needed to actually rate the potential damage are missing.
That gives a practical rule of thumb: not every library belongs in the Item Definition, but the components need to be cut fine enough that entries from the SBOM, the Software Bill of Materials, the parts list of the software packages installed, can attach to them. The SBOM stays in its own tool; the item model just needs to offer it stable anchor points. That’s the minimum resolution at which the path from CVE to risk can be traced at all.
A vehicle item changes: architecture iterations during development, then software updates across a vehicle lifetime of roughly 25 years in the field. The preliminary architecture from the Item Definition is exactly that: preliminary. Over the course of development it gets replaced by the actual architecture, often more than once, and each of those replacements touches the same assets, threat scenarios, and attack paths that were built on top of it. ISO 21434’s continuous cybersecurity activities (Clause 8) and the CSMS under UNECE R155 both assume that new events get assessed against the current item, not against the snapshot from the concept phase.
A static Item Definition, the Visio diagram in a PDF, decouples from engineering reality within months. The insidious part: every downstream TARA result silently inherits that drift. The analysis keeps looking tidy; it just describes an item that no longer exists in that form.
In concrete terms: the Item Definition should stay in sync with the leading engineering sources, meaning the architecture models and the requirements, and a change there should automatically raise the question of whether the TARA needs to change, instead of that question surfacing only at the next audit. In practice it often looks different: the synchronization happens manually, irregularly, or not at all, and that’s exactly where the drift described above comes from. This doesn’t need to run perfectly from day one: a model that reviews cleanly is the starting point, and the synchronization grows with the process.
Pull the threads together and three things remain that a model can do and a document can’t:
The point that matters most to me comes last, because it carries all the others: a machine-readable Item Definition isn’t better bookkeeping, it’s the prerequisite for everything that follows.
Through an API, the architecture can be imported from systems-engineering tools instead of rebuilt by hand. SBOM and vulnerability feeds attach to the components, and requirements link to the cybersecurity goals that come out of the TARA.
Where that clean tooling source doesn’t exist, because the item predates your own systems-engineering toolchain, the same AI connection helps in a different way: from existing legacy data such as PDF specifications or Visio diagrams, MCP and an LLM can generate a first draft of the Item Definition, one you then review and refine instead of starting from zero.
And through an MCP server, MCP stands for Model Context Protocol, an interface AI assistants use to access tool data in a structured way, the model becomes queryable for AI assistants. AI assistance is only as good as the context it can query. The question “which channels cross the item boundary and carry personal data?” is one an assistant can answer against a model. What role AI ends up playing in TARA work will show itself over time. What seems clear to me: only the item model ties its answers to the actual system. Without a model, they stay merely plausible.
An Item Definition is quick to summarize: boundary, functions, preliminary architecture. At the abstraction level the analysis needs. At the resolution SBOM mapping needs. And, looking ahead, as a living model instead of a diagram in an appendix.
If you want to put this into practice as a model: itemis SECURE is built around exactly this approach, from the item model with its element types through the calculated risk rating to the MCP server for AI assistance. If you’d like to see what an Item Definition looks like in it, reach me directly on LinkedIn or through itemis.com.
The next part covers Asset Identification: at what point does an element of the item become an asset, and whose damage actually counts? And if you want the overview of the whole method before diving into the depths, you’ll find it in my introductory article What Is a TARA?.
I’d be curious how you handle this: does your Item Definition survive the next TARA revision, or do you start over with a blank diagram every time?
Product Owner
Excel template for CRA risk analysis: TARA in line with ISO 21434 and IEC 62443 — how to start methodically, what you can import, and when Excel becomes the bottleneck.
Read Article
Jens Bühl
6 min read
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 read