Dieser Beitrag ist der dritte Teil unserer Serie EU CRA Tales From The Trenches, in der wir praktische Erkenntnisse aus der Zusammenarbeit mit Herstellern, Softwareanbietern und Organisationen mit vernetzten Produkten teilen, die sich auf den EU Cyber Resilience Act (CRA) vorbereiten.

Ein gemeinsames Muster zeichnet sich ab: Nachhaltige CRA-Compliance erfordert weit mehr als starke Cybersecurity. Sie verlangt Governance, Transparenz, Verantwortlichkeit und Lifecycle-Management-Fähigkeiten, auf die viele Organisationen ursprünglich nicht ausgelegt waren.

Die neue Compliance-Realität für Hersteller und Softwareanbieter

Viele Organisationen beginnen ihre CRA-Reise selbstbewusst. Sie verfügen über reife Cybersecurity-Programme, nutzen Secure Development Lifecycles, führen Penetrationstests durch, verwalten Schwachstellen und besitzen oft Zertifizierungen nach IEC 62443, ISO 27001, Common Criteria oder anderen anerkannten Frameworks.

Doch bei den am weitesten fortgeschrittenen CRA-Programmen zeigt sich eine zentrale Lektion:

Sicher zu sein und CRA-ready zu sein ist nicht dasselbe.

Viele Organisationen erledigen bereits einen großen Teil der vom CRA geforderten Arbeit. Die Überraschung: Häufig können sie dies nicht konsistent nachweisen.

Die Herausforderung besteht nicht mehr nur darin, gute Security-Kontrollen einzuführen. Es geht zunehmend darum, zu belegen, dass diese Kontrollen implementiert wurden, wirksam bleiben und über die gesamte unterstützte Produktlebensdauer mit nachvollziehbaren Nachweisen hinterlegt sind.

Der CRA erweitert die Verantwortung weit über die Produktentwicklung hinaus. Er bringt laufende Pflichten zu Vulnerability Monitoring, Incident Reporting, Software Updates, Kundenbenachrichtigungen und Lifecycle Support mit sich. Für viele Organisationen ist das eine der größten operativen Veränderungen durch den CRA.

Erkenntnisse für Führungskräfte

Traditionell zielten Cybersecurity-Programme vor allem auf Risikoreduktion. Der CRA verlangt weiterhin Risikoreduktion, fordert aber zusätzlich nachweisbare Verantwortlichkeit.

Regulatoren, Kunden und Auditoren erwarten zunehmend Antworten auf Fragen wie: Was wurde getan? Warum? Wer hat es genehmigt? Wann hat sich etwas geändert? Welche Evidenz stützt die Entscheidung?

Die Lücke liegt oft nicht in der Cybersecurity selbst, sondern in Governance, Traceability und Evidence. Nachweise sind häufig über Ticketing-Systeme, Engineering-Tools, SharePoint, Tabellen, Testplattformen, Dokument-Repositories und E-Mail verteilt. Das Produkt kann sicher sein – die Organisation kann es nur nicht schnell und vollständig beweisen.

Führungskräfte erkennen deshalb zunehmend den Bedarf an einem lebenden System of Record je Produkt, das Cyberrisiko, regulatorische Konformität, Nachweise, Freigaben und Lifecycle-Historie in einer kontrollierten Umgebung zusammenführt.

Warum selbst reife Security-Programme CRA-Lücken haben

Der CRA umfasst Pflichten, die über klassische Security-Aktivitäten hinausgehen. Unternehmen müssen kontinuierliche Compliance über den Produktlebenszyklus nachweisen: Secure Development, abgeschlossene Security Tests, bewertete Risiken, dokumentierte Entscheidungen, verwaltete Schwachstellen und fortlaufendes Monitoring nach dem Release.

Evidence Management
Jede relevante Cybersecurity-Aktivität sollte nachprüfbare Evidenz erzeugen: Risikobewertungen, Security Reviews, Freigaben, Remediation, Testergebnisse und unterstützende Dokumentation.

Lifecycle Accountability
Security-Verantwortung endet nicht beim Versand. Organisationen müssen Produkte auf Schwachstellen überwachen, Updates bereitstellen, Incident Response steuern, Kunden informieren und unterstützende Aufzeichnungen über die gesamte Supportdauer pflegen.

Funktionsübergreifende Governance
CRA-Compliance gehört nicht allein Cybersecurity. Engineering, Produktmanagement, Qualität, Legal, Compliance, Support und Führung tragen Verantwortung. Ohne klare Ownership und koordinierte Governance wird konsistente Evidence schnell schwierig.

Audit Readiness
Organisationen müssen davon ausgehen, Entscheidungen Jahre nach Markteinführung erklären zu müssen. Das erfordert Dokumentationsdisziplin und Lifecycle Governance auf einem Niveau, das viele zuvor nicht benötigten.

Erkenntnisse aus der Praxis

Design Reviews, Risikobewertungen, Penetrationstests und Schwachstellenmanagement finden oft bereits statt, doch die dazugehörige Evidenz liegt in vielen getrennten Systemen. Einen vollständigen Audit Trail zu erstellen wird dadurch zur manuellen Aufgabe.

Auch ein ausgezeichnetes Vulnerability-Management-Programm allein genügt nicht. Der CRA verlangt Nachweise darüber, wie Schwachstellen bewertet wurden, wer Remediation-Entscheidungen genehmigte, welche Kundenkommunikation erfolgte und warum Entscheidungen getroffen wurden.

Unternehmen, die durch Akquisitionen gewachsen sind, haben zusätzliche Probleme: Geschäftsbereiche nutzen unterschiedliche Engineering-Tools, Dokumentationsstandards und Security-Prozesse. Produkte können sicher sein, während der Compliance-Prozess uneinheitlich bleibt. Standardisierte Governance wird damit ebenso wichtig wie Security-Expertise.

Best Practices für CRA-Readiness

Ein Product System of Record etablieren
Eine zentrale Umgebung sollte Product Profiles, Cyber Risk Assessments, Regulatory Assessments, Security Controls, Evidence, Produktdokumentation und regulatorische Mappings enthalten.

Evidence als First-Class Deliverable behandeln
Jede Security-Aktivität sollte Nachweise erzeugen, die auch Jahre später auffindbar sind und nicht nur dokumentieren, was entschieden wurde, sondern warum.

Formales CRA-Gap-Assessment durchführen
Reife Organisationen erfüllen oft bereits viele CRA-Aktivitäten. Gap Assessments zeigen, wo Governance, Dokumentation, Evidence und Lifecycle Management gestärkt werden müssen.

Produktsicherheitsprozesse standardisieren
Konsistente Methoden verbessern Evidence-Qualität, Reporting, Audit Readiness und Lifecycle Governance über Produktportfolios hinweg.

Continuous Compliance aufbauen
CRA-Readiness ist kein Projekt, sondern eine operative Disziplin über die gesamte unterstützte Lebensdauer jedes vernetzten Produkts.

Häufige Fallstricke

Typische Fehler sind: bestehende Zertifizierungen automatisch als CRA-Nachweis anzusehen, technische Kontrollen zu priorisieren und Governance/Evidence zu vernachlässigen, CRA nur Security zuzuweisen, sich auf Tabellen/E-Mail/getrennte Repositories zu verlassen und Post-Market-Lifecycle-Pflichten zu spät zu planen.

Maßnahmen für OEMs und Softwareanbieter

Prioritäten: formales CRA-Gap-Assessment, Inventarisierung vorhandener Evidence-Quellen, Identifikation von Governance- und Dokumentationslücken, Ownership für Compliance-Artefakte, standardisierte Review- und Approval-Workflows, Evidence-Retention-Regeln, Lifecycle Monitoring, Audit-Readiness-Prozesse, Executive Reporting und kontinuierliche Compliance-Governance.

Wer früh beginnt, hat deutlich mehr Zeit, Prozesse vor zunehmender regulatorischer Prüfung zu reifen.

Wie OmniTrust Certify helfen kann

Eine der größten Lektionen lautet: CRA-Readiness entsteht nicht durch mehr Dokumente, sondern durch einen lebenden Datensatz zur Cybersecurity- und regulatorischen Lage jedes Produkts über den gesamten Lebenszyklus.

Certify schafft diese Grundlage. Statt verteilte Tabellen, E-Mails, Ticketing-Systeme, Engineering-Tools, Dokument-Repositories und Compliance-Plattformen zu nutzen, erstellt Certify ein zentrales Product Profile als System of Record für Produkt-Cyberrisiko und regulatorische Konformität.

Mit Certify können Organisationen lebende Product Profiles pflegen, Baseline Cyber Risk Assessments (TARAs) erstellen, Produkte gegen EU CRA und weitere Standards bewerten, Evidence und Engineering-Entscheidungen erfassen, Human-in-the-Loop-Validierung dokumentieren, standardisierte Risiko- und Regulatory Reports erzeugen, Änderungen verfolgen und Cyberrisiko sowie Compliance kontinuierlich neu bewerten. Führungskräfte erhalten Portfolio-Transparenz über Risiko und Readiness.

Zusammenfassung

CRA-Readiness bedeutet nicht nur, starke Cybersecurity-Praktiken einzuführen. Sie bedeutet, diese Praktiken über den gesamten Produktlebenszyklus nachzuweisen, aufrechtzuerhalten und verteidigen zu können.

Erfolgreich werden nicht zwingend die Organisationen mit den reifsten Security-Programmen sein, sondern jene, die diese Programme kontinuierlich demonstrieren, steuern und verbessern können – mit der Evidence, Verantwortlichkeit und Traceability, die Kunden, Auditoren und Regulatoren erwarten.

Das ist der eigentliche Unterschied zwischen „sicher“ und „CRA-ready“.

Als Nächstes in der Serie: EU CRA Tales From The Trenches #4 – Die eigentliche Arbeit für CRA-Compliance beginnt nach dem Produktrelease.