Living TARA: Warum der Cyber Resilience Act Ihren Engineering-Prozess verändert, nicht Ihre Dokumentation

Die meisten Unternehmen bereiten sich falsch auf den Cyber Resilience Act vor. Sie behandeln ihn wie eine neue Dokumentationspflicht: ein Formular mehr, ein Audit mehr, ein Ordner mehr im Qualitätsmanagement.

Das ist ein teurer Irrtum. Der CRA verlangt keine einmalige Risikoanalyse und kein einzelnes Audit. Er verlangt, dass Hersteller Security by Design, Vulnerability Management und belastbare Sicherheitsnachweise dauerhaft über den gesamten Produktlebenszyklus etablieren. Damit wird Cybersecurity zu einer kontinuierlichen Engineering-Aufgabe.

Die eigentliche Leitfrage betrifft damit nicht die Unterlagen, sondern den Prozess dahinter: Wie bauen wir etwas, das jederzeit nachweisbar sicher ist, auch in zwei Jahren, auch nach dem zwölften Patch, auch wenn das Team gewechselt hat?

Die Ausgangssituation: Security lebt in zu vielen Werkzeugen

Sehen Sie sich an, wo Ihre sicherheitsrelevanten Informationen heute liegen. Die Risikoanalyse steckt in einer Excel-Tabelle. Die Anforderungen in DOORS oder Polarion. Die Architektur im Modellierungswerkzeug. Die offenen Schwachstellen im Ticketsystem. Die Testnachweise wieder woanders.

Für jedes Audit müssen diese Informationen erneut manuell zusammengeführt werden. Jemand exportiert, kopiert, gleicht ab und baut aus verteilten Ständen ein Bild, das schon beim nächsten CVE wieder veraltet ist.

Vergleich: heute liegen Security-Artefakte in getrennten Werkzeugen und werden vor jedem Audit manuell zusammengeführt; mit einer Living TARA hängen sie an einem durchgängigen Security Digital Thread und sind jederzeit auditfähig.

Das funktioniert, solange Security ein Projekt mit Anfang und Ende ist. Unter dem CRA ist es das nicht mehr. Die Meldepflichten greifen ab dem 11. September 2026, die volle Anwendung folgt am 11. Dezember 2027. Ab dann müssen Sie eine aktiv ausgenutzte Schwachstelle innerhalb von 24 Stunden an die ENISA melden, den vollständigen Bericht binnen 72 Stunden. Wer seinen Sicherheitsstand aus fünf Werkzeugen zusammensuchen muss, verliert diese Frist, bevor die Analyse überhaupt begonnen hat.

Der Paradigmenwechsel: vom Nachweis zum Prozess

Viele Unternehmen glauben, sie müssten lediglich den CRA erfüllen. Tatsächlich fordert der CRA etwas wesentlich Grundsätzlicheres: einen dauerhaft nachweisbaren Security-Engineering-Prozess.

Der Unterschied klingt akademisch, hat aber handfeste Folgen. Eine Dokumentation bildet einen Zustand ab. Ein Prozess erzeugt diesen Zustand fortlaufend neu. Der CRA fragt nicht, ob Ihr Produkt zum Zeitpunkt des Inverkehrbringens sicher war. Er fragt, ob es über seinen gesamten Lebenszyklus sicher bleibt und ob Sie das jederzeit belegen können.

Für die Engineering-Leitung heißt das: Security wird Bestandteil des gesamten Product Lifecycle, nicht ein vorgelagerter Freigabeschritt. Und das verändert, wie Sie Werkzeuge, Zuständigkeiten und Nachweise organisieren. Die Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes hängen nicht an einem fehlenden Dokument, sondern an einem Prozess, der den Sicherheitsstand nicht halten kann.

Das Leitkonzept: Living TARA

Hier setzt das Konzept der Living TARA an. Die TARA, also die Threat Analysis and Risk Assessment, wird nicht einmal erstellt und dann abgelegt. Sie lebt.

Living TARA als Kreislauf: neues CVE, neue Architektur, neue Anforderung und neuer Patch fließen kontinuierlich in ein zentrales Sicherheitsmodell zurück, statt in einer To-do-Liste vor dem Audit zu landen.

Ein neues CVE betrifft eine Komponente, die Sie verbaut haben. Die Architektur ändert sich, weil eine Baugruppe eine Variante bekommt. Eine neue Anforderung kommt aus dem Feld. Ein Patch schließt eine Lücke und öffnet vielleicht eine andere. In einer statischen TARA landet jede dieser Änderungen in einer To-do-Liste, die irgendwann vor dem nächsten Audit abgearbeitet wird. In einer Living TARA fließt sie kontinuierlich zurück in das Sicherheitsmodell.

Der praktische Wert für Sie als Verantwortliche liegt in der Aktualität. Ihr Risikobild ist nicht so gut wie Ihr letzter Analyse-Workshop, sondern so gut wie Ihre letzte Änderung. Wenn ein CVE auftaucht, sehen Sie sofort, welche Produkte und welche Varianten betroffen sind, statt das erst manuell zu ermitteln. Das ist der Unterschied zwischen einer 24-Stunden-Meldefrist, die Sie halten, und einer, die Sie reißen.

Security Lifecycle Integration: der Security Digital Thread

Eine Living TARA funktioniert nur, wenn die Informationen dahinter dauerhaft miteinander verbunden bleiben. Diese Verbindung darf nicht in Dokumenten liegen, die jemand von Hand synchron hält, sondern in einem durchgängigen Zusammenhang vom ersten identifizierten Risiko bis zum Audit.

Wir nennen das den Security Digital Thread. Jedes Risiko hängt an einer Anforderung, jede Anforderung an einer Architekturentscheidung, jede Entscheidung an einer Maßnahme, jede Maßnahme an einem Testnachweis.

Security Digital Thread als Kette: Risiko, Anforderung, Architekturentscheidung, Maßnahme, Testnachweis und Audit sind verbunden; gestrichelte Rückverbindungen zeigen die Abhängigkeiten, die den Auditnachweis automatisch aktuell halten.

Ändert sich ein Element, wird sichtbar, was noch davon abhängt. Der Auditnachweis ist dann kein Zusammensuchen mehr, sondern ein Zustand, der ohnehin gepflegt wird.

Für variantenreiche, langgewachsene Produktlandschaften ist das der eigentliche Hebel. Wenn drei Werkzeuge jeweils beanspruchen, die einzige verlässliche Quelle zu sein, entsteht die Verlässlichkeit erst durch die Verbindungen zwischen ihnen, nicht durch ein weiteres Werkzeug obendrauf.

Warum itemis

Viele Unternehmen beraten zu Cybersecurity. Viele verkaufen Security-Tools. itemis verbindet beides.

Unsere Stärke liegt in der Kombination aus Security Engineering, modellbasierter Entwicklung, Toolchain-Integration und tiefer Engineering-Kompetenz. itemis SECURE liefert dabei die modellbasierte, auditfähige TARA. Es ist der zentrale Baustein, aber nicht der ganze Ansatz. Der Ansatz ist der durchgängige Security-Engineering-Prozess, den itemis ANALYZE über bestehende Werkzeuge wie Jira, DOORS oder Enterprise Architect spannt, ohne dass Sie migrieren müssen.

Diesen Weg sind wir mit über 40 Kunden im Automotive-Umfeld gegangen, dort unter dem Druck von ISO/SAE 21434. Die regulatorische Logik des CRA ist dieselbe: kontinuierliche Risikobewertung, nachweisbare Lifecycle-Verantwortung, belastbare Dokumentation. Für Hersteller cyber-physischer Systeme im Maschinen- und Anlagenbau bedeutet das, dass die Methode erprobt ist, auch wenn die Branche die regulatorische Reife des Automobilsektors erst aufbaut.

Was das für Sie heißt

Wenn Sie den CRA als Dokumentationsprojekt aufsetzen, produzieren Sie einen Nachweis, der ab dem Tag seiner Erstellung veraltet. Wenn Sie ihn als Engineering-Prozess aufsetzen, produzieren Sie einen Zustand, der jederzeit prüfbar ist und der sich später auf IEC 62443, ISO/SAE 21434 oder Functional Safety übertragen lässt.

CRA-Zeitstrahl: in Kraft seit 10.12.2024, Meldepflichten ab 11.09.2026 mit 24h/72h/14-Tage-Fristen an die ENISA, volle Anwendung ab 11.12.2027; Bußgelder bis 15 Mio. Euro oder 2,5 Prozent des Jahresumsatzes.

Die Frist am 11. September 2026 lässt sich nicht verschieben. Der Prozess dahinter braucht Vorlauf. Wenn Sie wissen möchten, wie eine Living TARA in Ihrer konkreten Werkzeuglandschaft aussieht, sprechen Sie mit uns über eine Standortbestimmung. Wir zeigen Ihnen den schnellsten belastbaren Weg von Ihrem heutigen Stand zu einem auditfähigen Security-Engineering-Prozess.

EU Cyber Resilience Act bei itemis — Fristen, Betroffenheit und der Weg zur Konformität mit itemis SECURE und der CRAIG-Community: EU Cyber Resilience Act →