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
6 min read
The Cyber Resilience Act (CRA) is not an automotive regulation, but the requirement it introduces is familiar from the automotive world: manufacturers of connected products must systematically identify, assess, and document cybersecurity risks before the product reaches the EU market, and keep that knowledge current across the product lifecycle.
What I hear more and more often: “We already have something. A spreadsheet, a few threat scenarios, a list of measures. But we don’t know if it’s enough, how to keep it maintained, or what happens when the model grows.”
This article is for exactly that situation. Not how to understand risk analysis as a concept — I’ve covered that elsewhere — but: how to start with what’s already there, how to begin methodically when nothing exists yet, and when a spreadsheet starts creating more problems than it solves.
The CRA requires manufacturers to conduct a cybersecurity risk analysis, document the results, and maintain the analysis across the product lifecycle. The assessment must be traceable — reproducible, versioned, and auditable when challenged.
In the automotive world, this requirement is well-known from ISO/SAE 21434. The standard for cybersecurity engineering in vehicles mandates a Threat Analysis and Risk Assessment (TARA): a structured analysis that identifies assets, derives threat scenarios, assesses attack paths, and documents the resulting risk decisions. For each identified risk, Impact Level (IL) and Attack Feasibility Level (AFL) yield a Risk Level (RL), which drives the treatment decision.
Those working in industrial environments will be more familiar with IEC 62443: the standard family for cybersecurity in industrial automation and control systems. There too, a risk analysis is the starting point, with similar concepts and a similar expectation of traceability. The CRA reaches both worlds — automotive and industrial — and itemis SECURE supports both standards.
This methodology maps directly onto what the CRA requires. The difference lies in the normative framework, not in the analytical discipline itself. Those coming from the automotive or industrial world can apply the method directly. Those who are new to both frameworks will find in ISO 21434 and IEC 62443 mature foundations to build on.
Most teams start from scratch. Some, however, bring something with them: a spreadsheet containing threat scenarios, impact ratings, and planned measures — sometimes structured around an internal template, sometimes grown organically from early analysis rounds.
The good news: it can be imported.
itemis SECURE supports importing all TARA-relevant data: Assets, Damage Scenarios, Threat Scenarios, Cybersecurity Goals, Claims, and Security Concepts. The itemis SECURE Excel template is recognised directly and can be imported without any mapping. Those working with a custom Excel format can also load their data — after a semantic mapping that aligns their columns to the TARA structure.
This does not replace the analysis itself, and it assumes the existing data matches the template structure. But it means you do not have to start from zero. What has already been thought through is preserved. What is missing or not yet assessed can be added in the tool.
Those starting from nothing can begin methodically with the itemis SECURE Excel template. The template supports the full TARA process: from asset identification through Damage Scenarios, Threat Catalog, Attack Steps, and Controls to Threat Scenarios, Risks, and Cybersecurity Goals. It is structured so that you can work through it systematically and then import the results into itemis SECURE.
I recommend the template as a starting point, not a permanent solution. It helps you learn the methodology, structure your first analysis model, and capture results in a format that can be reused later. For a first TARA or a first CRA risk analysis, it is a reasonable place to begin. The template automatically calculates key assessment criteria — AFL, IL, and the resulting RL — based on the assessment model. It is, however, a deliberate simplification. What it does not support:
Those who outgrow these limits need more than a spreadsheet.
The limit is rarely the first analysis. It is usually the second change.
Once attack paths propagate across multiple components, once a newly discovered CVE triggers reassessment in five places simultaneously, once two people work on the same analysis and one of them revises a decision — the spreadsheet becomes a source of errors. Maintaining consistency by hand across hundreds of rows is exactly the work that tools do well and people do poorly. And traceability — who decided what, when, and on what basis — is practically impossible to keep clean in a spreadsheet.
This is not an academic critique. CRA audits look precisely at that traceability. An analysis that looks solid but cannot show how a decision was reached will raise questions.
For larger threat models, I recommend tool support. itemis SECURE guides you through the analysis steps, keeps damage assessments, attack vectors, and risks consistent, computes risk propagation across attack paths, and maintains the decision history.
Attack Trees in itemis SECURE
It does not do the analysis for you — nor should it — but it keeps the accounting clean so you can focus on the decisions that actually matter. The model-driven approach also pays off for AI assistance: structured TARA data demonstrably helps large language models more than unstructured text. itemis SECURE provides an MCP server for this — AI tools can read the model directly and work from it, rather than reconstructing its meaning from unstructured documents.
The template is available here for download. It is the easiest way to start a structured analysis without having to adopt a tool immediately. If you first want to know where you stand on the CRA overall, you can check your implementation status with the free CRA gap analysis.
For questions — on the methodology, the tool, or support with the analysis itself — feel free to reach out directly on LinkedIn or via itemis.com.
Cyber Security at itemis — Systematic security engineering for automotive, IoT and Industry 4.0: Cyber Security →
Product Owner
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