Cyber Resilience Act PLM: Warum Rückverfolgbarkeit SBOMs übertrifft

ChampionXperience Team

13. September 2026 7 Minuten Lesezeit

Jenseits des SBOM: Warum der Cyber Resilience Act eine Herausforderung für die PLM-Rückverfolgbarkeit darstellt

Wenn Sie Produktentwickler, Systemingenieur oder PLM-Administrator sind, haben Sie im letzten Jahr wahrscheinlich viel über den Cyber Resilience Act (CRA) der Europäischen Union . Die meisten Diskussionen in der Branche konzentrierten sich auf die Grundlagen der Cybersicherheit: Secure-by-Design-Prinzipien, Verschlüsselung und die Erstellung einer Software-Stückliste (SBOM) in Standardformaten wie CycloneDX oder SPDX.

Das ist leicht nachzuvollziehen. Sicherheitsteams sind mit diesen Konzepten vertraut. Sie behandeln die SBOM-Generierung wie ein Problem der Software-Build-Pipeline: Code scannen, maschinenlesbare Datei ausgeben und die Konformität abhaken.

Ein SBOM (Self-Building Model) ist lediglich eine Aussage über den Inhalt Ihres Produkts. Es ist keine Garantie dafür, was tatsächlich an den Kunden ausgeliefert wurde, und hilft Ihnen auch nicht, wenn eine kritische Sicherheitslücke entdeckt wird und Sie nur wenige Stunden Zeit zum Reagieren haben. Deshalb ist die CRA (Certificate of Reliability) nicht nur eine Cybersicherheitsmaßnahme, sondern eine umfassende Herausforderung für das Produktlebenszyklusmanagement (PLM) und die Rückverfolgbarkeit.

Realitätscheck zum 11. September 2026: Die Uhr tickt bereits

Viele Hersteller konzentrieren sich zwar auf den 11. Dezember 2027 als Stichtag für die vollständige Einhaltung der Vorschriften (einschließlich CE-Kennzeichnung und Konformitätsbewertungen), doch ein wichtiger Meilenstein ist bereits erreicht. Seit dem 11. September 2026gelten die Meldepflichten gegenüber der CRA offiziell.

Gemäß diesen aktiven Regeln müssen Sie, wenn Ihr Produkt „digitale Elemente“ enthält und auf dem EU-Markt verkauft wird, aktiv ausgenutzte Sicherheitslücken und schwerwiegende Sicherheitsvorfälle der Europäischen Agentur für Cybersicherheit (ENISA) und den nationalen Behörden melden. Die Fristen sind strikt:

24 Stunden: Sie müssen eine Frühwarnmeldung einreichen, sobald Sie von einer aktiv ausgenutzten Sicherheitslücke oder einem schwerwiegenden Vorfall Kenntnis erlangen.
72 Stunden: Sie müssen eine detaillierte Meldung einreichen, die eine erste Einschätzung des Schweregrades und der Auswirkungen der Sicherheitslücke enthält.

Laut Rechts- und Branchenanalysen, beispielsweise von BlackBerry, gelten diese Fristen nicht nur für zukünftige Produkte, sondern auch für bereits auf dem Markt befindliche Artikel. Das bedeutet: Wird eine Sicherheitslücke in einer Komponente entdeckt, die Sie vor drei Jahren verwendet haben, beginnt die Frist sofort.

Warum das Generieren eines SBOM der einfache Teil ist

Ein SBOM ist eine Momentaufnahme. Es zeigt Ihnen, was Ihre Entwicklungsabteilung als im Produktdesign vorgesehen ansieht. Allerdings bleiben physische Produkte über ihren gesamten Lebenszyklus hinweg selten identisch mit ihren digitalen Zwillingen.

Betrachten wir einen typischen Hersteller von Hightech-Elektronik. Die Konstruktion beginnt in einem ECAD-Tool, wird als Engineering Bill of Materials (EBOM) in ein PLM-System übertragen und schließlich als MBOM an die Fertigung übergeben. Dabei werden Komponenten beschafft, ausgetauscht und aktualisiert.

Wird eine Sicherheitslücke bekannt, reicht es nicht, nur theoretisch zu wissen, ob eine bestimmte Softwarebibliothek oder Mikrocontroller-Firmware anfällig ist. Sie müssen genau wissen, welche Geräte mit dieser Version ausgeliefert wurden, welche Kunden sie besitzen und ob ein Zulieferer die Komponente während der Produktion ausgetauscht hat. Sind Ihre Produktdaten über verschiedene Datenbanken, Tabellen und E-Mails verstreut, ist es praktisch unmöglich, diese Fragen innerhalb von 72 Stunden zu beantworten.

Die Diskrepanz: Traditionelle Compliance vs. digitale Rückverfolgbarkeit

Um zu verstehen, warum traditionelle Ansätze unter dem CRA nicht mehr ausreichen, betrachten wir, wie Produktdaten typischerweise verwaltet werden und wie sie in einer Welt nach dem CRA verwaltet werden müssen:

Fähigkeit	Traditioneller PLM- und Compliance-Ansatz	Digital Thread-gesteuerte Compliance
SBOM-Generierung	Statische Textdatei oder Tabellenkalkulation, die zum Zeitpunkt der Veröffentlichung generiert wird.	Dynamisches, live verknüpftes SBOM, das direkt mit der physischen Produktkonfiguration und der Seriennummer verbunden ist.
Schwachstellenverfolgung	Manuelle Suche in ERP-Systemen, Beschaffungsunterlagen und Konstruktionsarchiven.	Sofortige Wirkungsanalyse, die eine Komponente vom Software-Repository bis zur spezifischen Auslieferungsseriennummer verfolgt.
Lieferantenwechsel	Die Anmeldung erfolgt in separaten ERP- oder Lieferantenportalen; eine Synchronisierung mit dem Konstruktionsdatensatz findet nur selten statt.	Automatisierte Änderungsworkflows, die den digitalen Thread aktualisieren, wenn ein Lieferant eine Komponente austauscht.
Reaktion auf Vorfälle	Panikbedingte Feueralarmübung mit Beteiligung mehrerer Abteilungen, E-Mails und Telefonanrufen.	Strukturierte, automatisierte Berichtsworkflows, die direkt von PLM- und Sicherheitsüberwachungstools ausgelöst werden.

Der Albtraum der Produktdatenabweichung

Abweichungen bei Produktdaten sind ein stiller Killer der Compliance. In der Elektronikfertigung kann es vorkommen, dass eine Leiterplattenbestückung (PCBA) aufgrund von Lieferkettenengpässen oder Kostenoptimierungen mehrere Komponentenaustausche direkt im Werk erfährt. Ein Lieferant könnte beispielsweise einen alternativen Mikrocontroller oder Flash-Speicherchip einbauen.

Werden diese Änderungen nicht in das zentrale PLM-System zurückgemeldet, weicht Ihre offizielle Konstruktionsdokumentation von der Realität ab. Ihr automatisierter Sicherheitsscanner meldet möglicherweise, dass Ihr Produkt sicher ist, weil die offizielle EBOM eine sichere Komponente auflistet. Gleichzeitig befinden sich jedoch Tausende von Einheiten im Einsatz, die einen ausgetauschten, anfälligen Chip enthalten.

Software weist ein ähnliches Driftproblem auf. Firmware-Updates, Patch-Level und Open-Source-Abhängigkeiten ändern sich ständig. Wenn Ihr Softwareentwicklungszyklus (SDLC) nicht eng mit Ihrem physischen PLM- und Hardwarekonfigurationsmanagement verknüpft ist, verlieren Sie die Möglichkeit nachzuvollziehen, welche Softwareversion auf welcher Hardwarevariante läuft.

Aufbau eines digitalen Fadens zur schnellen Schwachstellenverfolgung

Um die strengen Meldefristen der CRA zu überstehen, müssen Hersteller einen robusten digitalen Faden aufbauen, der PLM, modellbasierte Systementwicklung (MBSE), ERP und Sicherheitsüberwachungstools miteinander verbindet.

Das bedeutet nicht, dass Sie sämtliche Unternehmensdaten in ein einziges, monolithisches System migrieren müssen. Vielmehr geht es darum, aktive und nachvollziehbare Beziehungen zwischen diesen Systemen herzustellen. Wenn ein Softwareentwickler eine Firmware-Abhängigkeit aktualisiert, muss diese Änderung automatisch mit der betroffenen Hardwarekonfiguration im PLM-System verknüpft werden. Wenn ein Lieferant einen Komponentenaustausch anfordert, muss der Genehmigungsworkflow das aktive SBOM automatisch aktualisieren.

Wie aktuelle Erkenntnisse aus der Produktentwicklung von Dassault Systèmes, ist die Verknüpfung domänenübergreifender Engineering-Daten – aus den Bereichen Mechanik, Elektrotechnik und Software – der einzige Weg, die von modernen Vorschriften geforderte lückenlose Rückverfolgbarkeit zu gewährleisten. Wenn die Dokumentation zur Einhaltung von Vorschriften ein selbstverständliches Ergebnis Ihres täglichen Engineering-Workflows ist, wird eine 72-Stunden-Frist für die Berichterstattung nicht länger zu einer Krise, sondern zu einem Standardverfahren.

So führen Sie Ihren eigenen 72-Stunden-Stresstest durch

Warten Sie nicht auf einen tatsächlichen Sicherheitsvorfall, um herauszufinden, ob Ihre Produktdaten bereit sind. Sie können noch heute einen simulierten Test durchführen, um die Lücken in Ihrer Rückverfolgbarkeitskette zu identifizieren:

Wählen Sie ein ausgeliefertes Produkt: Wählen Sie ein komplexes, vernetztes Produkt, das seit mindestens einem Jahr auf dem Markt ist.
Eine simulierte Sicherheitslücke einführen: Wählen Sie eine bestimmte Open-Source-Softwarebibliothek oder eine elektronische Komponente eines Drittanbieters, die in diesem Produkt verwendet wird.
Starten Sie die Uhr: Geben Sie Ihrem Team 72 Stunden Zeit, um jede einzelne ausgelieferte Einheit, jeden Kunden, jede Konfiguration und jede Variante zu identifizieren, die von dieser Komponente betroffen ist.
Ergebnisse prüfen: Basierte die Nachverfolgung auf der Suche in einzelnen E-Mails, Lieferantentabellen oder dem persönlichen Gedächtnis einer Person? Falls ja, sind Ihre aktuellen PLM- und Konfigurationsmanagementprozesse nicht für die CRA-Konformität bereit.

Diese Übung zeigt Ihnen schnell, wo Datensilos Ihre Rückverfolgbarkeit unterbrechen. Die Behebung dieser Diskrepanzen ist jetzt wesentlich günstiger als spätere behördliche Strafen oder Marktverbote.

Weiterentwicklung: Konformität als Nebenprodukt der Entwicklung

Der Cyber Resilience Act verändert die Spielregeln für Hardware- und Softwarehersteller gleichermaßen. Sicherheit ist nicht länger eine nachträgliche Behebung von Sicherheitslücken, sondern ein grundlegender Bestandteil der Produktqualität und -konformität, der vom ersten Entwurf bis zum Ende des Produktlebenszyklus berücksichtigt werden muss.

Indem Sie Compliance-Daten als aktiven Bestandteil der einheitlichen Produktdokumentation behandeln, vermeiden Sie nicht nur behördliche Bußgelder. Sie bauen eine widerstandsfähigere Lieferkette auf, reduzieren Nacharbeiten im Entwicklungsprozess und liefern Ihren Kunden sicherere und zuverlässigere Produkte.

Sind Ihre Konstruktionsdaten so strukturiert, dass sie eine 72-stündige Reaktionszeit bei einem Vorfall überstehen, oder verlassen Sie sich immer noch auf unzusammenhängende Tabellenkalkulationen zur Verwaltung Ihrer Produktkonfigurationen?