Living TARA: Why the Cyber Resilience Act Changes Your Engineering Process, Not Your Documentation

Most companies prepare for the Cyber Resilience Act the wrong way. They treat it like a new documentation duty: one more form, one more audit, one more folder in the quality management system.

That’s an expensive mistake. The CRA doesn’t ask for a one-time risk analysis or a single audit. It requires manufacturers to establish security by design, vulnerability management, and defensible security evidence permanently, across the entire product lifecycle. Cybersecurity becomes a continuous engineering task.

So the guiding question isn’t how you produce the required paperwork. It’s about the process behind it: how do you build something that stays provably secure in two years, after the twelfth patch, and even after the team has changed?

The starting point: security lives in too many tools

Look at where your security-relevant information sits today. The risk analysis is in an Excel sheet. The requirements are in DOORS or Polarion. The architecture is in the modeling tool. The open vulnerabilities are in the ticket system. The test evidence is somewhere else again.

For every audit, someone has to merge all of it by hand. They export, copy, reconcile, and assemble a picture from scattered states that’s already outdated by the next CVE.

Comparison: today, security artifacts sit in separate tools and are merged by hand before every audit; with a Living TARA they hang on one continuous Security Digital Thread and stay audit-ready at any time.

That works as long as security is a project with a beginning and an end. Under the CRA it isn’t one anymore. Reporting obligations apply from 11 September 2026, and full application follows on 11 December 2027. From then on, an actively exploited vulnerability has to reach ENISA within 24 hours, with the full report due within 72 hours. Anyone who first has to gather their security status from five tools loses that deadline before the analysis has even begun.

The paradigm shift: from evidence to process

Many companies believe they simply have to comply with the CRA. In reality it demands something far more fundamental: a permanently demonstrable security engineering process.

The difference sounds academic but has concrete consequences. Documentation captures a state. A process keeps producing that state. The CRA doesn’t ask whether your product was secure at the moment you placed it on the market. It asks whether it stays secure across its full lifecycle, and whether you can prove that at any time.

For engineering leadership, that means security becomes part of the entire product lifecycle instead of a gate you pass once. And that changes how you organize tools, responsibilities, and evidence. The fines of up to €15M or 2.5% of global annual turnover don’t hang on a missing document. They hang on a process that can’t hold the security state.

The core concept: Living TARA

This is where the idea of a Living TARA comes in. The TARA, the Threat Analysis and Risk Assessment, isn’t created once and filed away. It lives.

Living TARA as a cycle: a new CVE, new architecture, a new requirement, and a new patch flow continuously back into a central security model instead of piling up in a pre-audit to-do list.

A new CVE affects a component you’ve built in. The architecture changes because an assembly gains a variant. A new requirement comes back from the field. A patch closes one gap and maybe opens another. In a static TARA, each of these lands on a to-do list that gets worked off at some point before the next audit. In a Living TARA, it flows continuously back into the security model.

The practical value for you as the person responsible lies in currency. Your risk picture is only as good as your last change, not as good as your last analysis workshop. When a CVE appears, you see immediately which products and which variants are affected, instead of having to work that out by hand. That’s the difference between a 24-hour reporting deadline you hold and one you miss.

Security lifecycle integration: the Security Digital Thread

A Living TARA only works when the information behind it stays connected for good. Not as documents someone has to keep in sync, but as one continuous chain of relationships from the first identified risk to the audit.

We call this the Security Digital Thread. Every risk hangs on a requirement, every requirement on an architecture decision, every decision on a control, every control on a test result. Change one element and you see what still depends on it. The audit trail then isn’t a scavenger hunt, it’s a state you maintain anyway.

Security Digital Thread as a chain: risk, requirement, architecture decision, control, test evidence, and audit are connected; dashed back-links show the dependencies that keep the audit trail current automatically.

For variant-rich, long-grown product lines, this is the real lever. When three tools each claim to be the single source of truth, reliability comes from the connections between them, not from adding one more tool on top.

Why itemis

Plenty of companies advise on cybersecurity. Plenty sell security tools. itemis combines both.

Our strength is the mix of security engineering, model-based development, toolchain integration, and deep engineering competence. itemis SECURE provides the model-based, audit-ready TARA. It’s the central building block, though not the whole approach. The approach is the continuous security engineering process that itemis ANALYZE spans across your existing tools like Jira, DOORS, or Enterprise Architect, without forcing you to migrate.

We’ve walked this path with more than 40 automotive customers, there under the pressure of ISO/SAE 21434. The regulatory logic of the CRA is the same: continuous risk assessment, demonstrable lifecycle responsibility, defensible documentation. For manufacturers of cyber-physical systems in mechanical and plant engineering, that means the method is proven, even where the industry is still building the regulatory maturity that automotive already has.

What this means for you

Set up the CRA as a documentation project and you produce evidence that’s outdated the day you create it. Set it up as an engineering process and you produce a state that’s verifiable at any time, one that later carries over to IEC 62443, ISO/SAE 21434, or functional safety.

CRA timeline: in force since 10 December 2024, reporting obligations from 11 September 2026 with 24h/72h/14-day deadlines to ENISA, full application from 11 December 2027; penalties up to €15M or 2.5% of annual turnover.

The 11 September 2026 deadline won’t move. The process behind it needs lead time. If you’d like to see what a Living TARA looks like in your specific tool landscape, talk to us about a baseline assessment. We’ll show you the fastest defensible path from where you are today to an audit-ready security engineering process.

EU Cyber Resilience Act at itemis — Deadlines, applicability and the path to conformity with itemis SECURE and the CRAIG community: EU Cyber Resilience Act →