EU CRA 2026: Leitfaden zur Vorbereitung auf die Schwachstellenmeldung

Es ist 08:17 Uhr an einem Montagmorgen im September 2026. Anna, CISO eines schnell wachsenden europäischen SaaS-Unternehmens, denkt noch immer an die Vorstandssitzung der vergangenen Woche. Der CEO hatte die Frage gestellt, die derzeit jede Sicherheitsleitung hört: „Wenn wir uns bereits auf NIS2 vorbereitet haben und unsere Fintech-Kunden ständig Nachweise zu DORA anfordern, was ändert dann der Cyber Resilience Act?“

Dann landet die Antwort in ihrem Posteingang.

Ein unabhängiger Sicherheitsforscher meldet eine aus der Ferne ausnutzbare Schwachstelle in einer Firmware-Update-Komponente, die in einem der vernetzten Produkte des Unternehmens verwendet wird. Die Nachricht enthält einen Proof of Concept, den Namen einer Abhängigkeit und den Hinweis, dass eine ähnliche Ausnutzung bereits in freier Wildbahn beobachtet wurde.

Innerhalb weniger Minuten verlangt jeder eine andere Antwort. Der CTO fragt, ob die Schwachstelle tatsächlich besteht. Die Rechtsabteilung fragt, ob die Meldepflicht nach dem EU Cyber Resilience Act ausgelöst wurde. Das Produktteam fragt, welche Versionen betroffen sind. Die CISO fragt, ob die Abhängigkeit in SBOMs auftaucht. Der Compliance-Manager öffnet das ISO 27001-Risikoregister und findet einen Prozess zum Schwachstellenmanagement, aber keinen klaren Entscheidungsweg für Produktmeldungen.

Das ist das eigentliche Problem der CRA-Vorbereitung. Die meisten Organisationen beginnen nicht bei null. Sie verfügen bereits über Incident-Response-Richtlinien, Patch-Management-Routinen, sichere Entwicklungspraktiken, Lieferantenprüfungen, Schwachstellenscanner und ISO 27001-Nachweise. Der CRA honoriert jedoch keine isolierten Dokumente. Er verlangt einen schnellen, belastbaren Workflow, der fünf Fragen gleichzeitig beantworten kann:

1. Handelt es sich um eine aktiv ausgenutzte Schwachstelle oder um einen schwerwiegenden Vorfall mit Auswirkungen auf die Produktsicherheit?
2. Welche Produkte, Versionen, Kunden, Abhängigkeiten und Lieferanten sind betroffen?
3. Welche Behörde, welcher Kunde oder welcher vertragliche Empfänger muss benachrichtigt werden, und wann?
4. Welche Nachweise belegen, dass Triage, Risikominderung und Offenlegung kontrolliert abliefen?
5. Wie ist dies mit ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF und Auditerwartungen abgestimmt?

Die Antwort ist kein separater „CRA-Ordner“. Die Antwort besteht darin, die CRA-Schwachstellenmeldung mit dem ISMS, dem Prozess zur koordinierten Offenlegung von Schwachstellen, der SBOM-Disziplin, der Lieferanten-Governance und der Nachweiskette der Vorfallreaktion zu verzahnen, die Sie für eine ausgereifte Cybersicherheits-Governance ohnehin benötigen.

Warum der EU Cyber Resilience Act das Meldemodell verändert

Der EU Cyber Resilience Act, Verordnung (EU) 2024/2847, rückt Produktsicherheit in den Kernbereich der Compliance. Er gilt für Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden; dazu können vernetzte Geräte, Software, Firmware, eingebettete Systeme und Unternehmenssoftware gehören.

Die operative Änderung, die für CISOs, Verantwortliche für Produktsicherheit und Compliance-Teams am wichtigsten ist, beginnt am 11. September 2026. CRA Article 14 verlangt ein gestuftes Meldeverfahren für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, die die Sicherheit von Produkten mit digitalen Elementen betreffen. Praktisch bedeutet dies, dass Hersteller auf Folgendes vorbereitet sein müssen:

Die genaue rechtliche Bewertung sollte stets durch qualifizierte Rechtsberatung erfolgen, die operative Lehre ist jedoch eindeutig. Die ersten 24 bis 72 Stunden sind nur so belastbar wie die Vorbereitung, die Monate zuvor abgeschlossen wurde.

Wenn Ihre SBOMs unvollständig sind, der CVD-Posteingang nur informell überwacht wird, Lieferantenverträge keine Schwachstellenbenachrichtigung verlangen oder Ihre Incident-Response-Richtlinie nicht zwischen Produktschwachstellenmeldungen und Datenschutz- oder Betriebsstörungen unterscheidet, läuft die rechtliche Frist schneller als Ihr Nachweisprozess.

ISO/IEC 27001:2022 als tragende Struktur für die CRA-Vorbereitung nutzen

ISO/IEC 27001:2022 ersetzt keine rechtliche Einhaltung des CRA, ist aber die beste Managementsystem-Struktur, um CRA-Verpflichtungen in die tägliche Governance zu integrieren.

Die Abschnitte 4.1 bis 4.4 verlangen, dass die Organisation den internen und externen Kontext, interessierte Parteien, Anforderungen, Schnittstellen zu anderen Organisationen und den ISMS-Geltungsbereich versteht ISO/IEC 27001:2022. Für die CRA-Vorbereitung bedeutet dies, dass Ihr ISMS-Geltungsbereich Produkte mit digitalen Elementen, Verantwortlichkeiten im Produktlebenszyklus, gehostete Komponenten, Build-Pipelines, Open-Source-Abhängigkeiten, Lieferanten, Benutzer, Importeure, Händler, regulierte Kunden und relevante Behörden erfassen sollte.

Die Abschnitte 6.1.1 bis 6.1.3 verlangen Risikobeurteilung und Risikobehandlung einschließlich Risikoverantwortlicher, Folgen, Eintrittswahrscheinlichkeit, Behandlungsentscheidungen, der Erklärung zur Anwendbarkeit und der Restrisikoakzeptanz. CRA-Meldungen sollten in diesem Prozess als Risikoszenario der Produktsicherheit behandelt werden, nicht als Ad-hoc-Übung zur rechtlichen Auslegung im Notfall.

ISO/IEC 27002:2022 ISO/IEC 27002:2022 liefert anschließend die praktische Maßnahmenstruktur. Die wichtigsten Maßnahmen für die CRA-Schwachstellenmeldung sind:

In Zenith Controls: Der Cross-Compliance-Leitfaden ordnet Clarysec ISO/IEC 27002:2022-Maßnahme 8.8, Management technischer Schwachstellen, als präventive Maßnahme ein, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt. Ihre Attribute sind den Cybersicherheitskonzepten Identify und Protect zugeordnet; Bedrohungs- und Schwachstellenmanagement ist die operative Fähigkeit.

Diese Einordnung ist wichtig. Bei CRA-Meldungen geht es nicht nur darum, Behörden zu benachrichtigen. Es geht darum nachzuweisen, dass eine präventive Fähigkeit zum Schwachstellenmanagement bereits existierte, bevor die Meldung einging.

Das Betriebsmodell auf CVD, SBOM und die Meldefrist ausrichten

Ein belastbarer CRA-Workflow für Schwachstellen beginnt, bevor ein Sicherheitsforscher Kontakt aufnimmt. Er beginnt mit der Fähigkeit, Schwachstellenberichte entgegenzunehmen, zu validieren, betroffene Komponenten zu identifizieren, die Ausnutzung zu bewerten, Risikominderungsmaßnahmen zu koordinieren, mit Benutzern zu kommunizieren und Nachweise zu bewahren.

Der erste Baustein ist ein öffentlicher Meldekanal für Schwachstellen. Clarysecs Richtlinie zur koordinierten Offenlegung von Schwachstellen, Anforderungen an die Umsetzung, Abschnitt 6.1, legt fest:

Öffentliche Offenlegungskanäle: Die Organisation muss einen klaren Kanal für Schwachstellenmeldungen unterhalten, etwa eine dedizierte E-Mail-Adresse für Sicherheitskontakte (zum Beispiel security@company.com) oder ein Webformular. Diese Informationen müssen auf der Sicherheitsseite der Unternehmenswebsite zusammen mit dem öffentlichen PGP-Schlüssel der Organisation veröffentlicht werden, um verschlüsselte Einreichungen zu ermöglichen.

Dies behebt einen häufigen Auditmangel. Viele Unternehmen geben an, Schwachstellenmeldungen entgegenzunehmen, doch der Meldeweg ist verborgen, nicht gesteuert oder läuft über eine allgemeine Support-Warteschlange. Unter CRA-Bedingungen wird der Meldekanal zum Auslöser für rechtliche Kenntniserlangung, Schweregradbewertung und Nachweiserfassung.

Der zweite Baustein ist die Triage. Die Richtlinie zur koordinierten Offenlegung von Schwachstellen, Anforderungen an die Umsetzung, Abschnitt 6.4, legt fest:

Triage und Bestätigung: Nach Eingang einer Meldung muss das VRT diese erfassen und dem Meldenden innerhalb von 2 Geschäftstagen eine Eingangsbestätigung mit einer Referenz zur Nachverfolgung senden. Das VRT muss eine vorläufige Schweregradbewertung durchführen, beispielsweise anhand eines CVSS-Scorings, und den Sachverhalt innerhalb eines Zielzeitraums von 5 Geschäftstagen validieren, gegebenenfalls mit Unterstützung von IT- und Entwicklungsteams. Kritische Schwachstellen, etwa solche, die Remotecodeausführung oder eine wesentliche Datenpanne ermöglichen, müssen beschleunigt bearbeitet werden.

Für die CRA-Vorbereitung sollte dieser Triage-Datensatz um Felder erweitert werden, die die rechtliche Meldeentscheidung unterstützen:

Der dritte Baustein ist SBOM-Disziplin. Clarysecs Richtlinie für sichere Softwareentwicklung, Governance-Anforderungen, Abschnitt 5.4, legt fest:

Die Nutzung von Open-Source- oder Drittanbietercode muss genehmigt, nachverfolgt und validiert werden durch: 5.4.1 Software Composition Analysis (SCA) 5.4.2 Lizenzprüfung (GPL, MIT, BSD usw.) 5.4.3 Scans auf bekannte Schwachstellen (CVEs, OSS Index usw.)

Für kleinere Organisationen formuliert Clarysecs Richtlinie zu Anforderungen an die Anwendungssicherheit - SME, Anforderungen an die Umsetzung der Richtlinie, Abschnitt 6.4.2, dieselbe Erwartung in praktischer Form:

Für jede verwendete externe Komponente muss durch den Entwickler oder IT-Dienstleister ein Nachweis geführt werden, einschließlich:

Dieser Komponentennachweis wird zum Mindestnachweissatz für eine SBOM-gestützte Schwachstellenreaktion. Er sollte Komponentenname, Version, Quelle, Lieferant oder Repository, Lizenz, Produktversion, Build-Datum und Status des Schwachstellenscans miteinander verbinden. Wenn ein CVE, ein Bericht eines Sicherheitsforschers oder eine Lieferantenmitteilung eingeht, sollte Ihr Team innerhalb von Stunden beantworten können: „Welche freigegebenen Produkte enthalten diese Komponente?“

CRA, NIS2, DORA und GDPR in einer Meldeentscheidungsmatrix abbilden

Der Cyber Resilience Act wird nicht isoliert wirken. Eine einzelne Produktschwachstelle kann CRA-Meldungen, eine NIS2-Bewertung als Vorfall, Nachweispflichten gegenüber DORA-Kunden, eine GDPR-Bewertung einer Datenschutzverletzung und vertragliche Mitteilungspflichten auslösen.

NIS2 Article 21 verlangt von wesentlichen und wichtigen Einrichtungen die Umsetzung geeigneter technischer, operativer und organisatorischer Maßnahmen. Diese Maßnahmen umfassen Risikoanalyse, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Beschaffung, Entwicklung und Wartung, Schwachstellenbehandlung und Offenlegung, Wirksamkeitsbewertung, Cyberhygiene, Kryptografie, HR-Sicherheit, Zugriffskontrolle, Asset-Management, MFA und sichere Kommunikation.

NIS2 Article 23 legt ein gestuftes Modell für Vorfallmeldungen fest: Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung, Vorfallmeldung innerhalb von 72 Stunden, Zwischenaktualisierungen auf Anforderung und einen Abschlussbericht spätestens einen Monat nach der Vorfallmeldung. NIS2 Article 20 begründet außerdem die Rechenschaftspflicht des Leitungsorgans für die Genehmigung und Überwachung von Maßnahmen zum Cybersicherheitsrisikomanagement.

DORA gilt seit dem 17. Januar 2025 und schafft ein einheitliches EU-Rahmenwerk für digitale operationale Resilienz bei Finanzunternehmen. Für SaaS-Anbieter, Softwareanbieter und IKT-Lieferanten erscheint DORA häufig über Kundenverträge. Ihr Kunde aus dem Finanzsektor kann das regulierte DORA-Unternehmen sein, aber Ihre Schwachstellenbearbeitung, SBOM-Nachweise, Unterstützung bei Vorfällen, Auditrechte und Meldezusagen können erforderlich sein, damit dieser Kunde seine eigenen Verpflichtungen erfüllen kann.

GDPR ergänzt einen weiteren Entscheidungszweig. Wenn die Schwachstelle oder der Vorfall zur unbeabsichtigten oder unrechtmäßigen Vernichtung, zum Verlust, zur Veränderung, zur unbefugten Offenlegung von oder zum unbefugten Zugriff auf personenbezogene Daten führt, ist eine Bewertung als Datenschutzverletzung erforderlich. GDPR Article 5 umfasst außerdem Integrität, Vertraulichkeit und Rechenschaftspflicht; die Organisation muss ihre Entscheidungsfindung daher nachweisen können.

Clarysecs Incident-Response-Richtlinie, Anforderungen an die Umsetzung der Richtlinie, Abschnitt 6.4.1, unterstützt diese Mehr-Regime-Bewertung bereits:

Wenn ein Vorfall zu einer bestätigten oder wahrscheinlichen Offenlegung personenbezogener Daten oder anderer regulierter Daten führt, müssen die Rechtsabteilung und der DPO die Anwendbarkeit der folgenden Anforderungen bewerten: 6.4.1.1 GDPR Article 33 (72-Stunden-Meldung an die Aufsichtsbehörde) 6.4.1.2 GDPR Article 34 (Benachrichtigung betroffener Personen, sofern ein hohes Risiko besteht) 6.4.1.3 NIS2 Article 23 (Meldung innerhalb von 24 Stunden nach Kenntniserlangung des Vorfalls) 6.4.1.4 DORA Article 17 (Meldung schwerwiegender IKT-bezogener Vorfälle)

Für die CRA-Vorbereitung sollte dieses Playbook um die Bewertung der Meldepflicht nach CRA Article 14 für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle mit Auswirkungen auf die Produktsicherheit erweitert werden.

Eine einheitliche Entscheidungsmatrix verhindert, dass Teams getrennte und uneinheitliche Melde-Playbooks betreiben:

Für KMU gibt Clarysecs Incident-Response-Richtlinie - SME, Governance-Anforderungen, Abschnitt 5.3.2, denselben Grundsatz in einfacherer Form vor:

Reaktionsfristen, einschließlich Datenwiederherstellung und Meldepflichten, müssen dokumentiert und an rechtlichen Anforderungen ausgerichtet sein, etwa an der GDPR-Anforderung zur Meldung von Datenschutzverletzungen innerhalb von 72 Stunden.

Die CRA-Vorbereitung erweitert diesen Grundsatz lediglich von der Meldung von Datenschutzverletzungen auf die Meldung von Produktschwachstellen und Produktsicherheitsvorfällen.

Lieferantennachweise sind jetzt Nachweise der Produktsicherheit

Viele CRA-relevante Schwachstellen entstehen außerhalb Ihrer eigenen Codebasis. Sie können aus Open-Source-Paketen, Firmware-Modulen, SDKs, gehosteten Programmierschnittstellen, Build-Werkzeugen, Cloud-Services, unterbeauftragten Komponenten oder vorgelagerten Bibliotheken stammen. Damit wird Lieferanten-Governance zentral für die CRA-Vorbereitung.

ISO 27001:2022 Abschnitt 8.1 verlangt von Organisationen, extern bereitgestellte Prozesse, Produkte oder Dienstleistungen zu steuern, die für das ISMS relevant sind. ISO/IEC 27002:2022-Maßnahme 5.21, Management der Informationssicherheit in der IKT-Lieferkette, bildet den Maßnahmenanker.

In Zenith Controls ordnet Clarysec Maßnahme 5.21 als präventive Maßnahme ein, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt. Ihre operative Fähigkeit ist die Sicherheit von Lieferantenbeziehungen; ihre Domänen umfassen Governance, Ökosystem und Schutz. Der Punkt ist einfach: Lieferantenkontrollen sind kein Beschaffungspapier. Sie sind Maßnahmen zum Schutz des Ökosystems.

Clarysecs Richtlinie zur Lieferanten- und Drittparteiensicherheit - SME, Governance-Anforderungen, Abschnitt 5.3, legt die vertragliche Grundlage fest:

Verträge müssen verpflichtende Klauseln enthalten, die Folgendes abdecken:

Für Unternehmensprogramme erläutert der Zenith Blueprint: Eine 30-Schritte-Roadmap für Auditoren, Phase „Kontrollen in der Praxis“, Schritt 23, Organisatorische Maßnahmen 5.19 bis 5.37, ISO/IEC 27002:2022-Maßnahme 5.20, Berücksichtigung der Informationssicherheit in Lieferantenvereinbarungen:

Vertrauen darf bei Lieferanten nicht auf Annahmen beruhen. Es muss vertraglich festgeschrieben sein.

Für die CRA-Vorbereitung sollten Lieferantenvereinbarungen Klauseln zur Produktsicherheit enthalten, die eine schnelle Schwachstellenreaktion unterstützen:

DORA verstärkt dieselbe Richtung. Finanzunternehmen müssen IKT-Drittparteienrisiken steuern, Register zu IKT-Serviceverträgen führen, Kritikalität bewerten, gebotene Sorgfalt ausüben, Konzentrationsrisiko steuern, vertragliche Schutzmaßnahmen definieren, Auditrechte sichern und Ausstiege planen. Wenn Sie Software oder IKT-Dienstleistungen an Finanzunternehmen verkaufen, sollten Sie damit rechnen, dass Kunden fragen, ob Ihre Schwachstellenmeldung und Ihr SBOM-Prozess deren Anforderungen an DORA-Vorfallbearbeitung, Resilienz und Nachweise zu Drittparteien unterstützen können.

Der Clarysec-Workflow zur CRA-Vorbereitung

Clarysec unterstützt Kunden dabei, CRA-Meldungen innerhalb eines an ISO 27001:2022 ausgerichteten ISMS über einen praktischen Workflow zu operationalisieren.

1. CRA-Verpflichtungen in das ISMS-Anforderungsregister aufnehmen

Beginnen Sie mit ISO 27001:2022, Abschnitten 4.1 bis 4.4. Aktualisieren Sie Organisationskontext, interessierte Parteien und Geltungsbereich, sodass Produkte mit digitalen Elementen, EU-Marktexponierung, Benutzer, Importeure, Händler, Regulierungsbehörden, CSIRTs, Lieferanten und regulierte Kunden enthalten sind.

Erstellen Sie Einträge im Anforderungsregister für CRA-Schwachstellenmeldung, CRA-Meldung schwerwiegender Produktsicherheitsvorfälle, NIS2-Vorfallmeldung, DORA-Unterstützungspflichten gegenüber Kunden, GDPR-Bewertung von Datenschutzverletzungen, vertragliche Vorfallmitteilungen, CVD-Verpflichtungen und Kommunikation mit Sicherheitsforschern.

Damit erhalten Auditoren einen nachvollziehbaren Weg von der externen Verpflichtung zur internen Maßnahme.

2. Ein Erfassungsformular für Produktschwachstellen erstellen

Stützen Sie das Erfassungsformular auf die Richtlinie zur koordinierten Offenlegung von Schwachstellen. Es sollte Identität des Meldenden, sichere Kontaktdaten, Produktversion, Modul, Umgebung, Proof of Concept, Reproduktionsschritte, Ausnutzungsstatus, potenzielle Datenexposition, Serviceauswirkung, SBOM-Komponentenabgleich, CVSS oder gleichwertigen Schweregrad, Verantwortlichen, Referenz zur Nachverfolgung und regulatorischen Prüfpunkt erfassen.

Das Formular sollte automatisch ein Ticket in der Warteschlange für die Schwachstellenreaktion erstellen. Außerdem sollte es einen Timer für die Meldeentscheidung starten, selbst wenn die endgültige Antwort „nicht meldepflichtig“ lautet.

3. SBOM-Daten mit Releases verbinden

Für jede freigegebene Produktversion ist eine SBOM oder ein gleichwertiges Komponentenverzeichnis zu führen. Die minimal nützlichen Nachweise umfassen Komponentenname, Version, Quelle, Lizenz, Lieferant oder Repository, Produktversion, Build-Datum und Status des Schwachstellenscans.

Die Richtlinie für sichere Softwareentwicklung und die Richtlinie zu Anforderungen an die Anwendungssicherheit - SME liefern die Richtliniengrundlage für SCA, Komponentenprüfung und Nachweise zu externen Komponenten.

4. Nachweise ab dem ersten Tag sichern

Jedes CRA-relevante Schwachstellenticket sollte Folgendes aufbewahren:

• Ursprüngliche Meldung
• Zeitstempel der Eingangsbestätigung
• Triage-Notizen
• CVSS- oder gleichwertige Begründung des Schweregrads
• Ergebnisse des SBOM-Abgleichs
• Bewertung der Ausnutzung
• Protokolle, Indikatoren und forensische Snapshots
• Lieferantenkommunikation
• Risikoakzeptanz, falls die Risikominderung verzögert wird
• Patch-Plan, Release Notes und Testnachweise
• Meldeentscheidungen gegenüber Kunden und Behörden
• Eingaben für den Abschlussbericht und Lessons Learned

Dies steht im Einklang mit ISO 27001:2022 Abschnitt 8.1, der dokumentierte Informationen verlangt, die ausreichen, um nachzuweisen, dass Prozesse wie geplant betrieben wurden, sowie mit den Abschnitten 8.2 und 8.3, die dokumentierte Ergebnisse der Risikobeurteilung und Risikobehandlung verlangen.

5. Mit einem realistischen Abhängigkeitsszenario testen

Führen Sie eine Tabletop-Übung mit einer simulierten aktiv ausgenutzten Abhängigkeitsschwachstelle durch. Beziehen Sie Engineering, Sicherheit, Rechtsabteilung, Datenschutz, Produkt, Kommunikation, Lieferantenmanagement und kundennahe Teams ein. Der Test sollte belegen, dass Ihre Organisation betroffene Versionen identifizieren, die Ausnutzung bewerten, eine Meldeentscheidung treffen, Lieferanten kontaktieren, Anwenderhinweise erstellen und Nachweise sichern kann.

Wie Auditoren die Vorbereitung auf CRA-Schwachstellenmeldungen prüfen werden

Eine Überprüfung der CRA-Vorbereitung wird selten auf eine CRA-Checkliste beschränkt sein. Unterschiedliche Auditoren prüfen dieselben Nachweise anhand unterschiedlicher Rahmenwerke.

In Zenith Controls ordnet Clarysec ISO/IEC 27002:2022-Maßnahme 5.24, Planung und Vorbereitung des Managements von Informationssicherheitsvorfällen, als korrektive Maßnahme ein, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt. Sie ist auf Respond und Recover ausgerichtet, mit Governance und Management von Informationssicherheitsereignissen als operativen Fähigkeiten.

Diese Maßnahme bildet die Brücke zwischen Schwachstellenentdeckung und regulatorischer Meldung.

NIST CSF 2.0 ist besonders nützlich als Kommunikationsebene für das Leitungsorgan. Seine Funktionen GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND und RECOVER helfen zu erklären, wie Produktschwachstellenmeldungen in die unternehmensweite Cybersicherheits-Governance passen, statt als Engineering-Ausnahme behandelt zu werden.

Häufige Lücken in der CRA-Vorbereitung, die vor 2026 zu beheben sind

Clarysec sieht immer wieder dieselben Lücken.

Die erste ist CVD ohne Meldelogik. Ein Unternehmen hat eine Sicherheits-E-Mail-Adresse oder eine security.txt-Datei, aber keinen internen Weg vom Bericht eines Sicherheitsforschers zur rechtlichen Bewertung der Meldepflicht.

Die zweite ist SBOM ohne Verantwortlichkeit. Engineering kann während des Builds eine SBOM erzeugen, aber niemand ist für die Richtigkeit bei freigegebenen Produkten verantwortlich oder erklärt, wie SBOM-Ergebnisse in die Schwachstellenreaktion einfließen.

Die dritte ist ein ISO-Zertifikat ohne Produktgeltungsbereich. Das ISMS umfasst Unternehmens-IT und SaaS-Betrieb, aber keine eingebettete Software, Firmware, Produkt-Update-Infrastruktur, Build-Pipelines oder Schwachstellenoffenlegung.

Die vierte sind Lieferantenverträge ohne Schwachstellenklauseln. Die Beschaffung verlangt Vertraulichkeit und Datenschutz, aber keine Schwachstellenbenachrichtigung, Komponententransparenz, Unterstützung bei Vorfällen, koordinierte Offenlegung oder Auditnachweise.

Die fünfte ist Incident Response ohne Logik für Produktschwachstellen. Der Vorfallsplan deckt Ransomware, Phishing und Datenschutzverletzungen ab, aber keine aktiv ausgenutzten Produktschwachstellen, bei denen Kundensysteme gefährdet sein können, bevor die eigene Umgebung des Herstellers kompromittiert ist.

Die sechste ist manuell bearbeiteter DORA-Kundennachweis. Vertrieb oder Customer Success beantworten Fragebögen aus dem Finanzsektor fallweise, während dem Sicherheitsteam ein standardisiertes Nachweispaket fehlt, das Schwachstellenbearbeitung, SBOM-Governance, Unterstützung bei Vorfällen und Lieferantenkontrollen belegt.

Jede Lücke lässt sich beheben. Jede wird teuer, wenn sie während einer laufenden Schwachstelle entdeckt wird.

90-Tage-Checkliste zur Vorbereitung auf CRA-Schwachstellenmeldungen

Nutzen Sie die nächsten 90 Tage, um eine belastbare Grundlage zu schaffen:

• Identifizieren Sie Produkte mit digitalen Elementen, die auf dem EU-Markt in Verkehr gebracht oder bereitgestellt werden.
• Aktualisieren Sie ISMS-Geltungsbereich und Analyse der interessierten Parteien, sodass CRA-Stakeholder enthalten sind.
• Nehmen Sie die Bewertung der Meldepflicht nach CRA Article 14 in das Register der rechtlichen und regulatorischen Anforderungen auf.
• Veröffentlichen und überwachen Sie einen sicheren Meldekanal für Schwachstellen.
• Richten Sie ein Vulnerability Response Team mit Rollen aus Rechtsabteilung, Produkt, Engineering, Sicherheit und Kommunikation ein.
• Führen Sie SBOMs oder Komponentenverzeichnisse für freigegebene Produktversionen.
• Verknüpfen Sie SCA-Ergebnisse mit Schwachstellentickets und Produkt-Releases.
• Ergänzen Sie Triage-Formulare um Kriterien für aktive Ausnutzung und schwerwiegende Produktvorfälle.
• Erstellen Sie eine kombinierte Meldeentscheidungsmatrix für CRA, NIS2, DORA, GDPR und Verträge.
• Aktualisieren Sie Lieferantenverträge um Klauseln zu Schwachstellenmitteilungen, SBOM, Unterstützung bei Vorfällen und Koordination der Offenlegung.
• Führen Sie Patch-Protokolle und Abhilfenachweise.
• Testen Sie den Workflow mit einer simulierten aktiv ausgenutzten Abhängigkeitsschwachstelle.
• Präsentieren Sie die Ergebnisse der Geschäftsleitung mit Lücken, Restrisiken und Verantwortlichen für Abhilfemaßnahmen.
• Nehmen Sie das Nachweispaket in Internes Audit und Managementbewertung auf.

Clarysecs Richtlinie zum Schwachstellen- und Patch-Management - SME, Anforderungen an die Umsetzung der Richtlinie, Abschnitt 6.2.1, unterstützt die Überwachungsgrundlage:

Die IT-Funktion muss Schwachstellen überwachen mithilfe von:

Dieselbe Richtlinie, Governance-Anforderungen, Abschnitt 5.4.1, ergänzt den Prüfpfad:

Ein Patch-Protokoll muss geführt und bei Audits sowie bei Tätigkeiten der Incident Response überprüft werden.

Dieses Patch-Protokoll kann zu einem der wichtigsten Artefakte in einem CRA-Abschlussbericht werden. Es belegt Entdeckung, Priorisierung, Abhilfe, Tests und Abschluss.

Sorgen Sie dafür, dass September 2026 unspektakulär wird

Das beste CRA-Meldeereignis ist nicht deshalb einfach, weil die Schwachstelle einfach ist. Es ist einfach, weil die Organisation den Workflow bereits geprobt hat.

Vor September 2026 kann Clarysec Sie dabei unterstützen, Schwachstellenmeldungen in ein auditbereites System zu überführen, indem Ihr bestehendes ISO 27001:2022-ISMS, Ihr CVD-Prozess, Ihre SBOM-Fähigkeit, Ihre Lieferantenklauseln und Ihre Incident-Response-Playbooks gegen die Erwartungen aus CRA, NIS2, DORA, GDPR und NIST CSF abgebildet werden.

Beginnen Sie mit einer fokussierten Bewertung der Vorbereitung auf CRA-Schwachstellenmeldungen. Clarysec prüft Ihre Richtlinien, SBOM-Nachweise, Lieferantenverträge, Schwachstellentickets, Incident-Playbooks und den Prüfpfad. Anschließend nutzen wir Zenith Blueprint und Zenith Controls, um eine praktische Roadmap zur Mängelbehebung zu erstellen, keinen theoretischen Compliance-Ordner.

Wenn Sie bereits Clarysec-Richtlinien nutzen, passen wir diese für CRA-Meldungen an. Falls nicht, unterstützen wir Sie bei der Umsetzung des passenden Richtliniensatzes, einschließlich Richtlinie zur koordinierten Offenlegung von Schwachstellen, Richtlinie für sichere Softwareentwicklung, Incident-Response-Richtlinie, Richtlinie zum Schwachstellen- und Patch-Management - SME, Richtlinie zu Anforderungen an die Anwendungssicherheit - SME und Richtlinie zur Lieferanten- und Drittparteiensicherheit - SME, soweit angemessen.

September 2026 ist nah genug für Planung und weit genug entfernt für disziplinierte Vorbereitung. Organisationen, die jetzt handeln, werden in den ersten 24 Stunden nicht fragen: „Wer ist für diese Schwachstelle verantwortlich?“ Sie werden die Antwort, die Nachweise und den Meldeweg bereits haben.

Kontaktieren Sie Clarysec, um eine Bewertung der Vorbereitung auf CRA-Schwachstellenmeldungen zu planen und regulatorische Komplexität in einen belastbaren Vorteil für die Produktsicherheit zu verwandeln.