Warum Compliance mit dem Cyber Resilience Act eigentlich ein Datenproblem ist

Compliance hängt von der Fähigkeit ab, den Produktlebenszyklus zu verknüpfen

Im ersten Teil dieser Reihe habe ich das Cyber-Resilience-Gesetz der Europäischen Union als mehr als nur eine Anforderung an die Cybersecurity beschrieben. Es handelt sich um eine Verordnung, die den gesamten Produktlebenszyklus und den Marktzugang regelt. Diese Unterscheidung ist wichtig, da sie Einfluss darauf hat, wer innerhalb des Unternehmens für das Problem verantwortlich ist und was zu dessen Lösung erforderlich ist.

Der CRA verpflichtet Hersteller dazu, Produkte sicher zu konstruieren, Schwachstellen während der gesamten Supportdauer zu verwalten, Nachweise zu führen, Konformitätsbewertungen durchzuführen und schnell zu reagieren, wenn eine Schwachstelle ausgenutzt wird oder ein schwerwiegender Vorfall eintritt. Die Meldepflichten traten am 11. September 2026 in Kraft, und die wichtigsten Produktverpflichtungen gelten ab dem 11. Dezember 2027 Europäische Kommission – Cyber Resilience Act. Dieser Zeitplan ist nicht mehr nur theoretisch. Er ist bereits in Kraft.

Für viele Unternehmen wird die größte Schwierigkeit nicht darin bestehen, die einzelnen Anforderungen zu verstehen. Die größere Herausforderung wird darin bestehen, die vielen beweglichen Teile miteinander zu verknüpfen, die erforderlich sind, um diese Anforderungen konsequent umzusetzen. Hier kann PTC helfen.

PTC bietet „Digital Thread“-Funktionen, die Unternehmen dabei unterstützen, Produktinformationen, Arbeitsabläufe, Rückverfolgbarkeit, Änderungen und Lebenszyklusdaten zu verwalten, von denen eine effektive Compliance mit dem Cyber Resilience Act abhängt. Durch die Verknüpfung von Komponenten kann der „Digital Thread“ den Aufwand reduzieren, der für die Zusammenstellung von Nachweisen und die Reaktion auf Produktsicherheitsprobleme erforderlich ist.

Diese Herausforderung betrifft nicht nur den Kundenstamm von PTC. Eine ENISA-Analyse der Bedrohungslage aus dem Jahr 2024 ergab, dass sich die Ausnutzung von Sicherheitslücken als erster Angriffsvektor im Vergleich zum Vorjahr fast verdreifacht hat, was deutlich macht, warum die Aufsichtsbehörden die Hersteller zu einer schnelleren und präziseren Reaktion auf Sicherheitslücken drängen ENISA Threat Landscape 2024. Schnelligkeit und Rückverfolgbarkeit sind keine optionalen Aspekte mehr – sie sind der Mindeststandard.

Wie kann PTC Unternehmen dabei unterstützen, sich auf die CRA vorzubereiten?

Codebeamer: Anforderungen, Risiken, Tests und Nachweise miteinander verknüpfen

Bei CRA-Programmen unterstützt dies folgende Funktionen:

• Setzen Sie regulatorische und Cybersecurity-Anforderungen in kontrollierte Anforderungen um
• Verknüpfen Sie Anforderungen mit Risiken, Architektur, Tests, Fehlern und Korrekturmaßnahmen
• Richten Sie wiederverwendbare Workflows für sichere Entwicklung ein
• Weisen Sie den Umfang der Verifizierung und Validierung nach
• Führen Sie eine Auswirkungsanalyse durch, wenn sich eine Anforderung, eine Komponente oder ein Risiko ändert
• Verwalten Sie Änderungsverläufe, Überprüfungen, Genehmigungen und Baselines
• Erstellen Sie Nachweise, aus denen hervorgeht, wie jede Anforderung umgesetzt wurde

Der Vorteil besteht darin, dass, sobald qualifizierte Experten die geltenden Anforderungen definiert haben, Codebeamer den Teams dabei hilft, deren Umsetzung zu verwalten und den Zusammenhang zwischen den Verpflichtungen und den technischen Nachweisen aufzuzeigen. Diese Funktion gilt nicht nur für die CRA, sondern für alle Produkt- und regulatorischen Anforderungen, sei es im Bereich Software, Elektrotechnik oder Maschinenbau.

Windchill: Verwaltung des Produkts und der Nachweise zur Compliance

Windchill dient als kontrollierte, zentrale Produktdatenbasis für CRA-bezogene Aufgaben.

Diese Basis unterstützt Hersteller dabei:

• die genaue Produktkonfiguration zu identifizieren, die bewertet wird
• Hardware- und Software-Konfigurationsinformationen miteinander zu verknüpfen
• Stücklisten und zugehörige Produktdatensätze zu verwalten
• Cybersecurity-Anforderungen und Nachweise den betroffenen Produkten zuzuordnen
• Änderungen an Designs, Komponenten, Dokumentationen und Releases zu kontrollieren
• Revisionshistorien, Genehmigungen und Baselines über lange Produktlebenszyklen hinweg zu bewahren
• eine einheitliche Produktdefinition unternehmensweit bereitzustellen

Dies ist wichtig, da CRA-Nachweise nicht glaubwürdig sind, wenn sie von der Produktkonfiguration, auf die sie sich beziehen, losgelöst sind. Eine Risikobewertung, ein Testergebnis oder eine SBOM hat nur begrenzten Wert, wenn das Unternehmen nicht feststellen kann, welche Produktversion, -variante oder -version damit beschrieben wird. Windchill ist der Stammdatensatz für die geregelte Produktdefinition, und die anderen unten aufgeführten Funktionen sind damit verknüpft.

Creo: Die Integrität der Produktdefinition gewährleisten

Creo unterstützt den „Digital Thread“ der CRA, indem es die detaillierte technische Definition des physischen Produkts bereitstellt. In Verbindung mit Windchill wird so sichergestellt, dass die technischen Daten stets mit der geregelten Produktkonfiguration übereinstimmen. Diese Übereinstimmung ist für vernetzte Produkte von entscheidender Bedeutung, da sich Änderungen im Zusammenhang mit der Cybersecurity häufig auf die übergeordnete Produktdefinition auswirken und über die gesamte Konstruktions-, Fertigungs- und Serviceprozesse hinweg einheitlich verwaltet werden müssen.

Arbortext: Erstellung von Service- und technischen Informationen zur Unterstützung von Kampagnen und Rückrufaktionen

Wenn eine Sicherheitslücke oder eine Nichteinhaltung von Vorschriften Korrekturmaßnahmen vor Ort auslöst, benötigen Techniker und Kunden schnell genaue und aktuelle Anweisungen. Arbortext generiert dynamische, quellverbundene technische und Serviceinformationen direkt aus den verwalteten Produktdaten. Da die Inhalte mit der Produktkonfiguration und den Änderungsaufzeichnungen verknüpft sind, können Serviceanweisungen, Aktualisierungsverfahren und Sicherheitshinweise schnell und einheitlich erstellt und überarbeitet werden, um Feldkampagnen und Rückrufaktionen zu unterstützen. Damit wird eine häufig übersehene Lücke geschlossen: Die Korrektur mag zwar im Rahmen des Engineering-Prozesses ausgearbeitet sein, doch die Kampagne kann erst dann durchgeführt werden, wenn die ausführenden Mitarbeiter über korrekte, konfigurationsspezifische Anweisungen verfügen. Arbortext trägt dazu bei, dass die Serviceunterlagen genau auf die betroffenen Produkte und Versionen abgestimmt sind.

ServiceMax und Orbit: Korrekturmaßnahmen mit dem Außendienst verknüpfen

Die CRA-Verpflichtungen bestehen auch nach dem Markteintritt eines Produkts in die EU fort. Hersteller müssen Schwachstellen verwalten und während des Supportzeitraums entsprechende Sicherheitsupdates bereitstellen.

Zu den relevanten Anwendungsfällen gehören:

• Identifizierung betroffener installierter Produkte oder Produktbestände
• Koordination von Maßnahmen vor Ort und Arbeitsaufträgen
• Erfassung von Serviceaktivitäten und der Anlagenhistorie
• Erfassung von Kunden- oder Vor-Ort-Problemen
• Nachverfolgung der Umsetzung von Korrekturmaßnahmen
• Rückmeldung von Beobachtungen vor Ort an die Qualitätssicherung und die Entwicklung

Die Genauigkeit der CRA hängt nicht nur von den Definitionen „As-Designed“ und „As-Built“ ab, sondern auch von der Kenntnis des „As-Maintained“-Zustands der Produkte im Feld – also davon, was im Laufe der Zeit tatsächlich gewartet, aktualisiert oder ausgetauscht wurde. PTC Orbit hilft dabei, eine vernetzte „As-Maintained“-Dokumentation der installierten Produkte zu führen und erfasst die tatsächliche Konfiguration jedes Assets im Laufe seines Betriebs. Windchill bleibt der Stammdatensatz für die geregelte Produktdefinition; Orbit ergänzt diesen, indem es abbildet, wie sich einzelne Einheiten nach der Auslieferung verändert haben. Zusammen ermöglichen sie es einem Hersteller, mit Sicherheit zu beantworten, welche spezifischen Einheiten von einer bestimmten Sicherheitslücke betroffen sind, wodurch der Umfang einer Kampagne oder eines Rückrufs drastisch eingegrenzt wird.

Hinter dieser Präzision steht ein erheblicher finanzieller Nutzen. Die durchschnittlichen Kosten einer Datenpanne beliefen sich im Jahr 2024 weltweit auf 4,88 Millionen US-Dollar, und dieselbe Studie ergab, dass Unternehmen mit umfassenden Sicherheits-KI- und Automatisierungslösungen Datenpannen deutlich schneller identifizierten und eindämmten als solche ohne, so der IBM Cost of a Data Breach Report 2024. Die Eingrenzung des Umfangs einer Feldkampagne ist nicht nur eine operative Erleichterung, sondern wirkt sich direkt auf Kosten und Risiken aus.

Wie PTC dabei helfen kann, Compliance-Probleme zu vermeiden

Die beste Reaktion auf ein CRA-Problem besteht darin, zu verhindern, dass es überhaupt auf den Markt gelangt. Derselbe vernetzte Digital Thread, der ein Unternehmen CRA-fähig macht – wobei jede PTC-Lösung die oben beschriebene Rolle übernimmt –, verhindert auch von vornherein, dass Compliance-Lücken entstehen. Da die „Intelligent Product Lifecycle“-Lösungen von PTC diesen Digital Thread KI-fähig machen, wird die Prävention zu einem wiederholbaren, überprüfbaren Bestandteil der täglichen Produktentwicklung und ist nicht mehr nur eine hektische Maßnahme kurz vor jedem Audit oder jeder Markteinführung. Ein paar wenige Disziplinen übernehmen den Großteil der Arbeit.

Cybersecurity-Anforderungen in die Produktentwicklung integrieren

Wenn Sicherheitsanforderungen zusammen mit funktionalen, qualitativen, sicherheitsrelevanten und anderen regulatorischen Anforderungen verwaltet und nachverfolgt werden – und dabei in die geregelte Produktdefinition eingebunden sind, anstatt separat erfasst zu werden –, werden Lücken frühzeitig sichtbar. Eine fehlende Anforderung, eine unvollständige Verifizierung oder eine nicht genehmigte Änderung wird bereits vor der Auslieferung des Produkts erkannt und nicht erst während eines Audits.

Die Änderungskontrolle stärken

Ein Produkt kann die Anforderungen an Compliance nicht mehr erfüllen, wenn Change Management und Cybersecurity als getrennte Prozesse behandelt werden. Durch die Einbindung von Cybersicherheitsprüfungen in den geregelten Änderungsprozess lässt sich sicherstellen, dass die Compliance im Laufe der Produktentwicklung gewahrt bleibt, wobei dieselben vernetzten Produktdaten und dieselbe Rückverfolgbarkeit genutzt werden, auf die bereits bei Entscheidungen im Bereich des Engineerings zurückgegriffen wird. Anstatt erst im Nachhinein überprüft zu werden, wird Compliance zu einem festen Bestandteil der Bewertung und Umsetzung von Änderungen.

Die Transparenz von Softwarekomponenten verbessern

Nur wenn ein Hersteller genau weiß, was in jedem Produkt enthalten ist, kann er schnell feststellen, ob eine neu bekannt gewordene Sicherheitslücke betroffen ist. Dies ist kein hypothetisches Problem: Der Bericht „Open Source Security and Risk Analysis 2024“ ergab, dass 86 % der kommerziellen Codebasen mindestens eine bekannte Open-Source-Sicherheitslücke enthielten, so Synopsys OSSRA 2024.

Durch die Verknüpfung von verwalteten Konfigurations- und SBOM-Daten mit dem breiteren Cybersecurity-Ökosystem können Unternehmen einen genauen Überblick über Produktrisiken behalten und gleichzeitig die Rückverfolgbarkeit über den gesamten Produktlebenszyklus hinweg gewährleisten. Sicherheitsbefunde werden mit den Anforderungen, Änderungen, Tests, Releases und Serviceaktivitäten verknüpft, die das Produkt prägen, und liefern so den notwendigen Kontext, um Auswirkungen zu bewerten und Abhilfemaßnahmen voranzutreiben. PTC bildet die Grundlage für diesen vernetzten Ansatz.

Manuelle Rekonstruktion von Beweismitteln durch Rückverfolgbarkeit ersetzen

Unternehmen, die die Compliance nach wie vor anhand von Word-Dokumenten, Tabellenkalkulationen, E-Mail-Genehmigungen und manuell erstellten Rückverfolgungsmatrizen nachweisen, erstellen für jedes Audit und jede Freigabe aufs Neue dieselben Nachweise.

Jeder Schritt im Produktlebenszyklus sollte nahtlos und leicht zu erkennen sein und nicht jedes Mal als eigenständiges Projekt behandelt werden.

Wie PTC eine schnelle Reaktion auf Compliance-Probleme unterstützen kann

Der Zeitplan der CRA für die Meldung macht die Reaktionsgeschwindigkeit zu einer strategischen Kompetenz. Eine Frühwarnung muss möglicherweise innerhalb von 24 Stunden erfolgen, gefolgt von einer ausführlicheren Meldung innerhalb von 72 Stunden und einem späteren Abschlussbericht. Branchenvergleiche zeigen, warum dieses Zeitfenster so anspruchsvoll ist: Der „Verizon Data Breach Investigations Report 2024“ ergab, dass die Medianzeit, die Unternehmen zur Behebung kritischer Schwachstellen nach deren Entdeckung benötigten, bei 55 Tagen lag, während Angreifer neue Schwachstellen häufig bereits innerhalb weniger Tage nach ihrer Offenlegung ausnutzen, so Verizon 2024 DBIR. Eine 24-Stunden-Meldefrist lässt keinen Spielraum für die manuelle Rekonstruktion von Produktdaten.

Um effektiv reagieren zu können, müssen Unternehmen mehrere Fragen schnell beantworten:

• Welche Produkte enthalten die betroffene Software oder das betroffene Bauteil?
• Welche Versionen und Konfigurationen sind betroffen?
• Welche Produkte wurden auf dem EU-Markt in Verkehr gebracht?
• Welche Kunden oder installierten Anlagen sind in ihrem aktuellen „As-Maintained“-Zustand betroffen?
• Welche Sicherheitsanforderungen und Tests gelten?
• Welche Änderungen sind erforderlich, und welche Dokumentation muss aktualisiert werden?
• Wie wird die Korrektur verifiziert, freigegeben und bereitgestellt?

Eine vernetzte PTC-Umgebung verkürzt den Weg zu diesen Antworten.

Schritt 1: Ermittlung der betroffenen Produkte

Auf der Grundlage des geregelten Produkt- und Änderungskontexts können Teams weitaus schneller genau ermitteln, welche Einheiten betroffen sind, als wenn sie isolierte Repositorys durchsuchen müssten. Diese Präzision reduziert den Umfang der Kampagne, die Kosten und die Beeinträchtigungen für die Kunden.

Schritt 2: Entwurf und Entwicklung der Lösung

Die Korrekturmaßnahmen werden als ein einziger, mit Rückverfolgbarkeit ausgestatteter Prozess verwaltet, der die Kontinuität von der Identifizierung des Problems bis hin zur Umsetzung und Überprüfung gewährleistet. Indem die Aktivitäten innerhalb des Produktlebenszyklus miteinander verknüpft bleiben, können Unternehmen ihre Maßnahmen in den Bereichen Cybersecurity, Entwicklung, Qualität und Service koordinieren, ohne dass unzusammenhängende Arbeitsabläufe oder Lücken in der Verantwortlichkeit entstehen.

Schritt 3: Validierung der Lösung

Es muss nachgewiesen werden, dass die Korrektur das Risiko verringert, ohne neue Probleme zu verursachen. Da Verifizierung und Freigabe während des gesamten Prozesses mit den Arbeiten verknüpft bleiben, werden die zum Nachweis der Compliance erforderlichen Belege bereits im Rahmen der Maßnahme selbst erstellt. Anstatt nachträglich zusammengestellt zu werden, werden sie ganz natürlich erfasst, während Änderungen bewertet, umgesetzt und validiert werden.

Schritt 4: Bereitstellen und dokumentieren

Wenn ein Einsatz vor Ort erforderlich ist, erfüllen die vor Ort eingesetzten Tools jeweils die zuvor festgelegten Aufgaben: Arbortext erstellt die konfigurationsspezifischen Serviceanweisungen für die betroffenen Produkte, ServiceMax plant, disponiert und protokolliert die Arbeiten, und Orbit aktualisiert den „As-Maintained“-Datensatz, sobald die Korrekturmaßnahme angewendet wurde. Sowohl die Produkt- als auch die Compliance-Aufzeichnungen spiegeln dann den Service-Lebenszyklus genau wider.

Für behördliche Meldungen helfen PTC-Technologien dabei, die Produktnachweise zu organisieren und abzurufen, die Hersteller für den vorgeschriebenen CRA-Berichtsprozess benötigen, wodurch der Fluss genauer Produkt- und Serviceinformationen in den Berichtsworkflow verbessert wird.

Jetzt ist der richtige Zeitpunkt, den Lebenszyklus zu verknüpfen

Die erste wichtige Frist für die Umsetzung des CRA trat am 11. September 2026 in Kraft. Die vollständige Anwendung folgt am 11. Dezember 2027 Europäische Kommission – Cyber Resilience Act. Führungskräfte sollten sich folgende Fragen stellen:

• Wissen wir, welche unserer Produkte in den Geltungsbereich fallen?
• Können wir Sicherheitsanforderungen auf Risiken, Entwürfe, Software, Tests, Releases und Nachweise zurückführen?
• Können wir jedes Produkt, das von einer anfälligen Komponente betroffen ist – in seiner tatsächlichen, aktuellen Konfiguration –, innerhalb weniger Stunden identifizieren?
• Können wir die daraus resultierenden Korrekturmaßnahmen kontrollieren und überprüfen?
• Können wir betroffene Produkte und Kunden während des Supportzeitraums erreichen?
• Können wir stichhaltige Nachweise vorlegen, ohne diese manuell rekonstruieren zu müssen?

Wenn die Antwort auf eine dieser Fragen ungewiss ist, hat das Unternehmen mehr als nur ein regulatorisches Problem. Es hat ein Problem mit der Transparenz im Produktlebenszyklus.

Vom Aufwand für die Compliance hin zu einer schnelleren und effizienteren Produktentwicklung

Die Vorbereitung auf die CRA erfordert Investitionen. Doch die dafür notwendigen digitalen Fähigkeiten schaffen einen Mehrwert, der weit über die Einhaltung der CRA-Vorschriften hinausgeht. Der „Digital Thread“ bzw. die vernetzte Datenbasis, die die „Intelligent Product Lifecycle“-Lösungen von PTC bieten, wird zudem die Geschwindigkeit, die Kosten und die Qualität Ihres Produktentwicklungsprozesses verbessern.

Aus diesem Grund betrachte ich die CRA nicht ausschließlich als eine Frist für Compliance. Sie ist eine Chance, die Produktentwicklung zu transformieren. Unternehmen, die darauf mit der Erstellung weiterer Tabellenkalkulationen und zusätzlichen manuellen Überprüfungen reagieren, mögen zwar einzelne Anforderungen erfüllen, verursachen dabei jedoch zusätzliche Kosten und Verzögerungen.

Genau diese vernetzte Grundlage macht Lebenszyklusdaten für den Einsatz von KI bereit.

Die Verknüpfung dieser Zusammenhänge ist kein Projekt, das man erst in der Woche vor einem Audit in Angriff nimmt. Es beginnt mit einem Gespräch.