Cyber Resilience Act (CRA): Was Hersteller digitaler Produkte jetzt wissen müssen 

Ein Router, der nach zwei Jahren keine Sicherheitsupdates mehr bekommt. Eine vernetzte Maschinensteuerung, bei der niemand mehr genau sagen kann, welche Open-Source-Bibliotheken darin stecken. Solche Fälle waren lange ein Ärgernis, aber kein Rechtsverstoß. Das ändert sich gerade: Mit dem Cyber Resilience Act (CRA) hat die EU erstmals verbindliche Cybersicherheitsanforderungen für vernetzte Produkte festgelegt. Die erste harte Frist ist der 11. September 2026 gewesen. 

Was ist der Cyber Resilience Act? 

Der Cyber Resilience Act (CRA) ist eine EU-Verordnung, die einheitliche Cybersicherheitsanforderungen für sogenannte „Produkte mit digitalen Elementen“ einführt. Gemeint sind Hardware und Software, die direkt oder indirekt mit anderen Geräten oder Netzwerken verbunden sind. Die Verordnung wurde am 20. November 2024 im Amtsblatt der EU veröffentlicht und trat am 10. Dezember 2024 in Kraft. 

Der Grundgedanke: Cybersicherheit soll nicht länger etwas sein, das nach einem Vorfall nachgerüstet wird, sondern ein Merkmal, das über den gesamten Produktlebenszyklus hinweg mitgedacht wird – von der Konzeption über die Entwicklung und Produktion bis in die Nutzungsphase hinein. Als EU-Verordnung gilt der CRA unmittelbar in allen Mitgliedstaaten; es braucht keine nationale Umsetzung. 

Damit reiht sich der CRA in eine Logik ein, die aus dem Produktsicherheitsrecht vertraut ist: Wer ein Produkt auf den europäischen Markt bringt, muss nachweisen können, dass es bestimmte Anforderungen erfüllt. Neu ist, dass Cybersicherheit nun ausdrücklich dazugehört. 

Wen betrifft der CRA? 

Betroffen sind Hersteller, Importeure und Händler von Produkten mit digitalen Elementen, die in der EU auf den Markt gebracht werden. Der Anwendungsbereich ist bewusst breit gefasst und reicht von Consumer-Geräten wie Smartwatches und Babyphonen bis hin zu Industriekomponenten, IoT-Sensorik, Firewalls und Routern. Auch reine Softwareprodukte fallen darunter. 

Der CRA differenziert dabei risikobasiert: Neben der Grundkategorie gibt es „wichtige“ und „kritische“ Produkte mit digitalen Elementen, für die strengere Anforderungen an die Konformitätsbewertung gelten. Für Hersteller heißt das zunächst: Es lohnt sich, das eigene Portfolio früh daraufhin zu prüfen, welche Produkte überhaupt in den Anwendungsbereich fallen und in welcher Kategorie sie liegen. 

Wichtig ist auch ein Punkt, der leicht übersehen wird: Die Meldepflichten ab September 2026 gelten nicht nur für Produkte, die nach diesem Datum neu auf den Markt kommen. Sie erfassen auch Produkte, die bereits seit Jahren im Feld sind. Für viele Unternehmen bedeutet das, sich mit einem Bestand auseinanderzusetzen, dessen Softwarestände nicht durchgängig dokumentiert sind. 

Hinzu kommt die Lieferkette. Kaum ein vernetztes Produkt besteht heute nur aus eigenem Code – Open-Source-Bibliotheken, zugekaufte Module und Firmware von Zulieferern sind die Regel. Die Verantwortung gegenüber dem Markt bleibt beim Hersteller, unabhängig davon, wo eine Schwachstelle ihren Ursprung hat. 

Zeitplan und Fristen 

Der CRA wird gestaffelt wirksam. Diese Daten sollten Sie im Kalender haben: 

Die Meldefristen sind der Teil, der Organisationen erfahrungsgemäß zuerst unter Druck setzt. 24 Stunden sind keine Zeitspanne, in der sich eine Meldekette noch improvisieren lässt – die Prozesse, Zuständigkeiten und Kontaktwege müssen vorher stehen. 

Die zentralen Pflichten für Hersteller 

Inhaltlich lassen sich die Anforderungen des CRA auf einige Kernpunkte verdichten: 

Risikobewertung über den Lebenszyklus. Hersteller müssen Cybersicherheitsrisiken bewerten, dokumentieren und angemessene Schutzmaßnahmen umsetzen – und zwar nicht einmalig, sondern begleitend über Design, Entwicklung, Produktion und Nutzung. 

Software Bill of Materials (SBOM). Für jedes betroffene Produkt muss eine maschinenlesbare Stückliste der enthaltenen Softwarekomponenten geführt werden, mindestens auf Ebene der direkten Abhängigkeiten. Gängige Formate sind SPDX und CycloneDX. Die SBOM muss nicht veröffentlicht werden, aber sie gehört in die technische Dokumentation und muss den Marktüberwachungsbehörden auf Verlangen vorgelegt werden. Und sie muss aktuell bleiben: Jedes Update verändert potenziell den Softwarestand. 

Schwachstellen- und Patch-Management. Sicherheitsupdates müssen über einen angemessenen Unterstützungszeitraum bereitgestellt werden. Das setzt voraus, dass ein Hersteller überhaupt weiß, welcher Softwarestand in welchem ausgelieferten Produkt steckt. 

Technische Dokumentation und CE-Kennzeichnung. Ab Dezember 2027 ist die CE-Kennzeichnung Voraussetzung für den Marktzugang. Sie basiert auf einer Dokumentation, die die Konformität belegbar macht. 

Die Sanktionen sind erheblich: Verstöße können mit bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes geahndet werden. 

Was Unternehmen jetzt tun sollten 

Unternehmen, die noch nicht vollständig für das Reporting gerüstet sind, sollten dies mit sofortiger Priorität operativ angehen. Vier Schritte sind ein sinnvoller Einstieg: 

  1. Betroffenheit klären. Welche Produkte fallen in den Anwendungsbereich und welche Risikoklasse trifft zu? 
  1. Meldeprozess aufsetzen. Die 24-Stunden-Frist ab September 2026 ist die nächstliegende Hürde. Wer meldet, an wen, auf welchem Weg – und wer entscheidet, ob eine Schwachstelle „aktiv ausgenutzt“ wird? 
  1. SBOM-Fähigkeit aufbauen. Dies sollte nicht als einmaliges Projekt, sondern als Teil des Entwicklungs- und Release-Prozesses verstanden werden. 
  1. Verantwortlichkeiten klären. Der CRA betrifft Security, Produktentwicklung, Qualitätssicherung und Compliance gleichzeitig. Ohne eine klare Zuordnung bleibt die Aufgabe zwischen den Bereichen liegen. 

Es lohnt sich, diese Schritte nicht als Compliance-Projekt neben der Produktentwicklung zu führen, sondern in bestehende Entwicklungs- und Freigabeprozesse einzubetten. Anforderungen, die nur in einer separaten Nachweisakte leben, veralten schnell – solche, die im Release-Prozess verankert sind, bleiben aktuell. 

Wo eine durchgängige Produktdatenbasis hilft 

Die meisten CRA-Anforderungen laufen auf dieselbe Frage hinaus: Können Sie zu einem konkreten Produkt – auch fünf Jahre nach Auslieferung – sagen, aus welchen Komponenten es besteht, welche Anforderungen dafür galten und welcher Softwarestand ausgeliefert wurde? 

Genau an dieser Stelle setzt eine PLM-Plattform an. CONTACT Elements bildet den Produktlebenszyklus durchgängig ab und verknüpft Anforderungen, Komponenten, Dokumente und Änderungsstände miteinander. Diese Nachvollziehbarkeit ist keine CRA-Konformität an sich – sie ist aber die Grundlage, auf der sich SBOM-Pflege, technische Dokumentation und Nachweisführung gegenüber Behörden praktikabel organisieren lassen, statt sie im Ernstfall aus verstreuten Quellen zusammenzusuchen. 

Wenn Sie überlegen, wie sich die CRA-Anforderungen in Ihre bestehenden Entwicklungsprozesse einfügen lassen, sprechen Sie uns gerne an. 

Fazit 

Der Cyber Resilience Act verschiebt Cybersicherheit von einer freiwilligen Qualitätsfrage zu einer Marktzugangsvoraussetzung. Die Fristen im September 2026 und Dezember 2027 wirken auf den ersten Blick komfortabel, betreffen aber Prozesse, die sich nicht kurzfristig aufbauen lassen – insbesondere Meldeketten und eine belastbare Dokumentation des eigenen Softwarebestands. Der beste Zeitpunkt, damit anzufangen, ist deutlich vor der Frist. 

Schiffbau trifft Digitalisierung: Zwei Jahre im Forschungsprojekt SEUS

Zwei intensive Jahre im europäischen Forschungsprojekt SEUS liegen hinter mir. Unser gemeinsames Ziel: die Digitalisierung des Schiffbaus in Europa maßgeblich voranzutreiben. Und die Notwendigkeit dafür ist nach wie vor immens. Die EU schreibt kontinuierlich Forschungs- und Entwicklungsprojekte im Schiffbausektor aus, um Europas Position im globalen Wettbewerb zu stärken.

Angesichts von Niedriglohnländern und weitreichenden Subventionen auf dem außereuropäischen Markt ist das überlebenswichtig. Obwohl europäische Qualität in der maritimen Industrie hochgeschätzt wird, zwingt der Kostendruck auch diese traditionsreiche Branche zu massiven Effizienzsteigerungen und optimierten Prozessen.

Genau hier haben wir als CONTACT angesetzt: Als fester Bestandteil der Forschung und treibende Kraft der Transformation, den entscheidenden Daten-Backbone für eine erfolgreiche Digitalisierung bereitzustellen.

Eine schwimmende Stadt – und was sie mit PLM zu tun hat

Zunächst galt es, tief in die komplexen Anforderungen und Prozesse des Schiffbaus einzutauchen und sie zu verstehen. Durch intensive Gespräche mit Werften, fundierte Analysen und der Auseinandersetzung mit dem aktuellen Stand der Wissenschaft, konnten wir ein umfassendes Wissen aufbauen. Was uns dabei wirklich beeindruckt hat, ist die akribische Sorgfalt, mit der die Werften in diesem Projekt die gigantischen Informationsmengen verarbeiten, sicher gewerkeübergreifend kollaborieren und dabei souverän den strengen „Schiff-TÜV“, die sogenannte Klassifikation, meistern. Das umfasst Zehntausende Seiten an Prüfberichten, Berechnungen, Handbüchern und technischen Spezifikationen.

Was hier entsteht, ist nichts weniger als eine kleine, autark über die Ozeane schwimmende Stadt, dessen Bau jedes Mal auf Neue fasziniert. Das gilt für klassische Fracht- und Containerschiffe genauso, wie für hochspezialisierte Kabelverlegeschiffe, komplexe Forschungsschiffe oder Einheiten für den militärischen Einsatz.

Der Daten-Backbone: Die Verbindung der maritimen Welt

Die größte Herausforderung liegt in der effizienten Verwaltung und transparenten Kontrolle der unterschiedlichsten Informationen, die über alle Gewerke sowie Entwicklungs- und Bauphasen hinweg entstehen. Wir haben dafür ein Datenmodell entwickelt, was speziell auf den Schiffsbau zugeschnitten ist und sämtliche Informationsarten, wie zum Beispiel Projektpläne, CAD-Modelle, Simulationsergebnisse, Konstruktionspläne und Lieferantenverträge, miteinander verknüpft.

Das Schiff als „physisch großes und komplexes System“ zu betrachten, ist dabei entscheidend. Das bedeutet, dass nicht einige wenige den Überblick über das Gesamtschiff behalten, sondern eine Vielzahl an Ingenieur*innen sich auf kleinere Verantwortungsbereiche aufteilt.

Dabei nehmen sie je nach Entwicklungsaufgabe und -phase unterschiedliche Perspektiven auf das Schiff ein: Während bei der Auslegung der Antriebseinheit eher der Aufbau des entsprechenden Systems von Interesse ist, steht bei der Auslegung des Schiffsrumpfs die räumliche Aufteilung im Zentrum. Eine klassische Produktstruktur, die Bauteile und -gruppen entsprechend ihrer Zusammensetzung hierarchisch organisiert, wird diesen Anforderungen nicht gerecht. Es gibt nicht „die eine“ Produktstruktur, sondern verschiedene Blickwinkel: systemisch, räumlich, produktionszentriert und modulorientiert.

Viele Werften und Entwicklungsbüros nutzen eine zentrale Systemstruktur, da ein Großteil der Arbeit die Auslegung, Konstruktion und Integration von Systemen aller Art betrifft. In Europa hat sich hierfür das „SFI Group System“ als Quasi-Standard durchgesetzt. Dieser Standardkatalog mit drei Ebenen umfasst 4080 Einträge für Systeme und Subsysteme, die in Schiffen jeglicher Art auftreten können.

Schematische Darstellung zum Schiffbau
Das Datenmodell von CONTACT erweitert den Standardkatalog um weitere Perspektiven.

Unsere IT-Architekt*innen haben gemeinsam ein Datenmodell entwickelt, das die weiteren Perspektiven um diesen Standard herum systematisch abbildet (siehe dazu unser Paper auf Zenodo). In der frühen Schiffentwicklung werden die Systeme zunächst mithilfe von Platzhaltern grob dimensioniert. Man legt zum Beispiel fest, dass ein Motor benötigt wird, nicht jedoch welcher. Diese Platzhalter, nachfolgend Positionen (engl. „Item“) genannt, werden nach den Katalogen des SFI Group Systems organisiert.

Im weiteren Entwicklungsverlauf verknüpfen wir diese mit weiteren Strukturen, die die Grundlage anderer Perspektiven bilden. Am vorherigen Beispiel des Antriebs kann das zum Beispiel bedeuten, dass für diese Position ein konkreter Motor ausgewählt wird. Neben entsprechenden Dokumenten, Anforderungen, Spezifikationen und Projektaufgaben kann darüber hinaus auch ein CAD-Modell angebunden werden, was unser Partner Cadmatic mit einer tiefgreifenden Integration der CAD-Werkzeuge ermöglicht.

Das Projekt ist noch nicht final abgeschlossen, doch ein schiffbauspezifischer PLM-Backbone, die flexible, modulare CONTACT Elements Plattform und die Tiefenintegration mit Schiffs-CAD bilden bereits ein solides Fundament, um auf der Anwendungsebene weiterzuentwickeln. Die Dimensionen machen deutlich, warum das so wichtig ist: Wenn von den bis zu 4.000 möglichen Subsystemen zu jedem auch nur zehn Dokumente an Spezifikationen, CAD-Dokumenten, Analysen, Handbüchern und Prüfungsdokumentationen gehören, sprechen wir von gewaltigen Datenmengen, die ohne strukturiertes Management unkontrollierbar werden.

Hinzu kommt, dass jedes dieser Dokumente eigene Zyklen, Prüfungen und Freigaben durchläuft, die sowohl innerhalb des Unternehmens als auch extern abgestimmt werden müssen. Ein lückenloses, nachverfolgbares Dokumentenmanagement über Unternehmensgrenzen hinweg ist daher absolut unerlässlich und dank einer Erweiterung in CONTACT Elements für den Schiffbau auch realisierbar.

Mehr zum Hintergrund und zu den Beteiligten erfahren Sie im SEUS-Jahresbericht 2025.

Vom Hype zur Realität: Warum KI-Systemintegration entscheidend ist

Der Hype um künstliche Intelligenz im Engineering ist riesig. Fast jeder Software-Anbieter bietet smarte AI-Funktionen an. Richtig eingesetzt, entfalten KI-gestützte Lösungen genau dort eine enorme Hebelwirkung, wo Ingenieur*innen und Konstrukteur*innen täglich wertvolle Zeit verlieren. Das können lästige Routineaufgaben oder wiederkehrende To-Dos im Hintergrund sein: das automatisierte Erstellen von Testfällen, das Erfassen komplexer Dokumente oder die schnelle Bewertung kleinerer Änderungen.

Doch schaut man hinter die Kulissen der Industrie, folgt die Ernüchterung. Laut einer CIMdata-Studie haben zwar rund 80 % der Software-Hersteller bereits KI-Features im Portfolio – die tatsächliche Aktivierungsrate bei den Industriekunden liegt jedoch nur bei 8 bis 33 %! Fast 9 von 10 Industrieunternehmen nutzen KI bisher in weniger als einem Viertel ihrer Projekte. Die meiste Zeit verharren die Projekte in der Pilotphase. Doch woran liegt es, dass der Motor nicht anspringt?

Die Herausforderung: Die unsichtbare Datenmauer

Das größte Hindernis ist nicht der Algorithmus selbst, sondern das, was danach kommt: die KI-Integration. Für Industriekunden ist die nahtlose Anbindung an bestehende Systeme ein wichtiges Auswahlkriterium. Doch Software- und Service-Provider unterschätzen diese Hürde systematisch. In der Praxis stoßen Service-Provider 2,4-mal häufiger auf unerwartete Probleme mit Altsystemen, als Kunden das im Vorfeld überhaupt auf dem Schirm haben. Wenn neue KI-Tools einfach nur isoliert an bestehende Systeme „angeschraubt“ werden, scheitern sie an der Realität komplexer Engineering-Prozesse. Unser Chief Product Officer Frank Patz-Brockmann bringt es auf den Punkt: „Der Schmerz liegt nicht in der Anschaffung, sondern in der Aktivierung.“

Integration statt API-Bastelei

CONTACT Software geht dieses Problem mit Fourier AI proaktiv an. Wir müssen KI-Systemintegration als fundamentale Architekturentscheidung begreifen, nicht als nachträgliches Bastelprojekt: Anstatt eine externe KI-Insel über Standard-Schnittstellen anzubinden, ist Fourier AI als vollintegrierte Intelligenzschicht tief in der bewährten Plattform CONTACT Elements verankert.

Manchmal hören wir in Kundengesprächen den Drang, gewachsene Datenstrukturen komplett über Bord zu werfen und durch eine Art „Data Lake“ oder gar „Data Swamp“ zu ersetzen, in der Hoffnung, die KI würde sich die Informationen dort schon selbst zusammensuchen. Das ist jedoch der völlig verkehrte Ansatz, da KI strukturierte Daten benötigt.

Mit Fourier AI setzen wir daher auf einen klaren, schichtweisen Aufbau von unten nach oben:

  1. Single Source of Truth (PLM) als Basis: Ganz unten steht nach wie vor das PLM-System mit seinen hochgradig strukturierten Daten. Dieses Fundament ist zwingend notwendig und bildet die verlässliche Ausgangsbasis für jegliche Intelligenz.
  2. Die Kontext-Konstruktion: Daten einfach nur irgendwo abzuspeichern, reicht nicht aus. Für die KI muss ein präziser Kontext konstruiert werden. Wenn ein Nutzer beispielsweise eine Anfrage stellt wie „Gib mir mal alle Daten zum Engineering Change“, muss diese Kontext-Schicht genau wissen, welche Daten dazugehören, wer sie erstellt hat und wie sie zusammenhängen.
  3. Der Modell-Layer: Darüber liegt die Modellschicht. Neben führenden externen Modellen bieten wir auch eigene Spezialmodelle an, wie beispielsweise für die 3D-Ähnlichkeitssuche. Das System wählt für bestimmte Aufgaben in der Plattform automatisch das passende Modell aus, lässt Unternehmen für eigene Use Cases aber auch die freie Auswahl, auf welche Modelle sie zugreifen möchten.
  4. AI Orchestration & Governance: Um Antworten zu bewerten und kontinuierlich zu verbessern, werden die erzeugten Traces festgehalten und geloggt. Das System filtert die Daten so, dass das Modell nur Antworten liefert, die der jeweilige Nutzer über das integrierte Rechtesystem tatsächlich sehen darf.
  5. Die User Interaction (Der PLM-Chatbot): Ganz oben steht schließlich der Anwender, der beispielsweise im PLM-Chatbot seine Frage eingibt.

Fazit: Erst die Basis, dann der Mehrwert

Dieser tiefgreifende architektonische Ansatz erfordert im ersten Schritt mehr Sorgfalt bei der Datenstrukturierung und Systemvorbereitung. Doch genau das ist der entscheidende Hebel: Weil das Fundament von vornherein sauber gebaut ist, lernt die KI-Schicht automatisch mit, sobald ein Kunde sein Datenmodell in CONTACT Elements erweitert – ganz ohne zusätzlichen Code schreiben zu müssen. So schließen wir die Lücke zwischen bloßer Technologiespielerei und echtem, produktivem Mehrwert im Engineering-Alltag.

Mehr zum Thema erfahren Sie im Live-Talk: