Dieser Beitrag ist der vierte Teil unserer Blogserie Tales From the Trenches: CRA Lessons Learned . Ziel der Serie ist es, Herstellern, Softwareanbietern und Anbietern vernetzter Produkte die praktischen Realitäten der CRA-Umsetzung näherzubringen. Wir greifen auf Erfahrungen aus Kundenprojekten und Gesprächen mit Branchenführern zurück. Nachhaltige Compliance verlangt Governance, Transparenz, Verantwortlichkeit und Lifecycle Management weit über klassische Cybersecurity-Aktivitäten hinaus. Ein sicheres Produkt allein reicht nicht aus.

Warum Post-Market Cybersecurity zur entscheidenden Herausforderung der CRA-Readiness wird

Über Jahrzehnte arbeiteten Produktorganisationen nach einem einfachen Modell: Produkt entwickeln, testen, auf den Markt bringen und zum nächsten Release oder Produkt übergehen. Erfolg bedeutete termingerechte Entwicklung, erfüllte Leistungsanforderungen, bestandene Qualitätstests und vollständige Features.

Der Cyber Resilience Act (CRA) verändert diesen Maßstab grundlegend. Der Produktlaunch ist nicht mehr die Ziellinie, sondern der Startpunkt.

Früher konzentrierte sich sichere Produktentwicklung auf Secure Development, Risikobewertungen, Konformitätsbewertungen und technische Dokumentation. Unter dem CRA beginnen einige der bedeutendsten Pflichten erst, wenn Produkte bei Kunden eingesetzt werden.

Unternehmen müssen Programme betreiben, die über die gesamte unterstützte Lebensdauer aktiv bleiben: Schwachstellenmanagement, Coordinated Disclosure, Sicherheitsupdates, Incident Reporting, Überwachung der Software-Lieferkette, Kundenkommunikation und langfristige Support-Zusagen.

Die Frage lautet deshalb nicht mehr nur: „Ist dieses Produkt sicher genug für den Launch?“ Sondern: „Können wir für die nächsten fünf, sieben oder zehn Jahre Cybersecurity-Verantwortung aufrechterhalten?“

Erkenntnisse für Führungskräfte

Viele Organisationen behandelten CRA anfangs wie andere Compliance-Initiativen: Assessments durchführen, Security-Funktionen implementieren, Tests abschließen und Dokumentation erstellen. Diese Sicht unterschätzt den Umfang erheblich.

Der CRA führt ein Lifecycle-Modell der Cybersecurity-Verantwortung ein. Hersteller müssen Schwachstellen verwalten und offenlegen, Security Updates bereitstellen, Kunden informieren und dauerhaft Transparenz über Schwachstellen, Softwareabhängigkeiten, Updates, Notifications, Incident Response, Support-Zusagen und Produkt-Risikoprofil bewahren.

Das verlangt langfristige operative Fähigkeiten, die bestehen bleiben, nachdem Engineering bereits am nächsten Release arbeitet. CRA-Readiness ist daher nicht nur Produktsicherheit, sondern Product Lifecycle Governance.

Warum Verpflichtungen nach dem Release so schwierig sind

Produkte entwickeln sich weiter
Softwareupdates, neue Features, aktualisierte Drittanbieter-Komponenten und neue Nutzungsszenarien verändern Risikoprofile laufend. Ein Assessment beim Launch kann schnell veralten.

Schwachstellen hören nie auf
Forscher und Angreifer entdecken kontinuierlich neue Schwachstellen in Betriebssystemen, Open Source, kommerzieller Software und Hardwareplattformen. Unternehmen müssen fortlaufend prüfen, ob bereits ausgelieferte Produkte betroffen sind.

Produktteams ziehen weiter
Nach dem Release wechseln Engineering-Teams oft zum nächsten Produkt. Legacy-Produkte bleiben jedoch jahrelang im Feld und institutionelles Wissen kann verloren gehen. Ohne formale Lifecycle-Prozesse und gute Dokumentation verschwindet Wissen über Architektur und Sicherheitsfunktionen.

Software-Lieferketten werden komplexer
Moderne Produkte enthalten Dutzende oder Hunderte Komponenten. Unternehmen müssen jede Komponente und deren Updates nachvollziehen können.

Kundenbenachrichtigungen
Der CRA verlangt Kommunikation zu neu entdeckten Schwachstellen, Sicherheitsupdates und Änderungen der Supportbedingungen. Dafür sind operative Fähigkeiten nötig, die viele Unternehmen bisher nicht aufgebaut haben.

Herausforderungen aus der Praxis
Wird eine kritische Schwachstelle in einer wiederverwendeten Bibliothek entdeckt, kann sie mehrere Versionen verschiedener Produkte betreffen. Ohne zentral gepflegte Dokumentation und vollständige SBOMs müssen Teams zahlreiche Produkte durchsuchen, historische Unterlagen zusammentragen und bereichsübergreifend koordinieren. Die technische Behebung kann einfach sein; zuverlässig festzustellen, wo die Komponente eingesetzt wird, ist oft schwieriger.

Best Practices für nachhaltige CRA-Compliance

Lifecycle-Security-Programme aufbauen
Cybersecurity-Verantwortung muss bei der Produktidee beginnen und bis zum Support-Ende reichen. Formale Prozesse sollten Vulnerability Monitoring, Security Updates, Incident Response, Kundenkommunikation und Product Retirement abdecken.

Kontinuierliche Produkttransparenz aufrechterhalten
Aktuelle Informationen zu Produkten, Softwarekomponenten, Drittanbieter-Abhängigkeiten, Ownern und Supportstatus sind Voraussetzung für wirksames Post-Market Management.

Klare Verantwortlichkeit schaffen
Für jedes Produkt müssen Zuständigkeiten für Sicherheitsüberwachung, Schwachstellenbewertung, Update-Management und Compliance Reporting feststehen.

Wo möglich automatisieren
Mit wachsenden Portfolios werden manuelle Prozesse unbeherrschbar. Automatisierung unterstützt Vulnerability Tracking, Evidence Collection, SBOM Management, Compliance Reporting und Audit Readiness.

Compliance in den Produktbetrieb integrieren
CRA-Aktivitäten sollten keine parallelen Projekte sein, sondern Teil normaler Produktmanagement- und Support-Prozesse.

Häufige Fallstricke

Compliance als Pre-Release-Aktivität betrachten
Viele Pflichten beginnen erst nach dem Deployment – und gehören zu den schwierigsten.

Langfristigen Support unterschätzen
Organisationen konzentrieren sich auf Entwicklung und unterschätzen Ressourcen für laufende Sicherheitsverpflichtungen.

Unvollständige Produktinventare pflegen
Wer nicht weiß, welche Produkte im Feld sind und welche Software sie enthalten, kann schlecht auf Schwachstellen reagieren.

Fragmentierte Dokumentation
Nachweise über viele Systeme verteilt erhöhen Aufwand und Compliance-Risiken.

Security Updates nur als Engineering-Aufgabe behandeln
Updates erfordern oft Engineering, Legal, Support, Produktmanagement, Qualität und Führung gemeinsam.

Maßnahmen für OEMs und Softwareanbieter

Sofortige Prioritäten

  • Aktuelle Support- und Wartungsprozesse überprüfen.
  • Alle unterstützten Produkte und Softwareplattformen inventarisieren.
  • Formale Vulnerability-Monitoring-Prozesse etablieren.
  • Owner für Post-Market Cybersecurity benennen.
  • Softwarekomponenten-Transparenz und SBOM-Praxis prüfen.
  • Incident-Response- und Disclosure-Readiness bewerten.
  • Kundenkommunikationsprozesse prüfen.
  • Lücken im Evidence Management identifizieren.

Wer früh beginnt, ist wesentlich besser auf CRA-Durchsetzungsfristen vorbereitet.

Wie OmniTrust Certify helfen kann

Eine der häufigsten Erkenntnisse aus CRA-Programmen lautet: Die erste Bewertung ist relativ schnell erstellt. Schwierig ist, Informationen aktuell zu halten, wenn sich Produkte, Schwachstellen, Lieferanten und Vorschriften verändern.

OmniTrust Certify automatisiert und zentralisiert diesen Prozess. Für jedes vernetzte Produkt entsteht ein lebendes Product Profile, das Cyberrisiko, regulatorische Konformität, Nachweise, Verantwortlichkeit und Produktänderungen kontinuierlich verfolgt und Engineering, Security, Produkt und Compliance mit derselben Informationsbasis arbeiten lässt.

Statt CRA als einmaliges Projekt zu behandeln, ermöglicht Certify einen nachhaltigen Lifecycle-Ansatz für Cybersecurity Governance.

Zusammenfassung

Unter dem CRA werden nicht einfach jene Organisationen erfolgreich sein, die sichere Produkte bauen. Erfolgreich sind jene, die Sicherheit über die gesamte Betriebsdauer kontinuierlich aufrechterhalten, überwachen, dokumentieren und verteidigen können.

Deshalb beginnt unter dem Cyber Resilience Act die eigentliche Arbeit erst nach dem Produktrelease.

Abonnieren Sie den Blog auf unserer Blog-Startseite. Weiter geht es mit „Blog #5: Die 24-Stunden-Meldefrist ist in Wirklichkeit ein Transparenzproblem“.