CRA-Meldepflichten ab September 2026: Vulnerability Disclosure und Incident Reporting

Von codAIx GmbH | 24. April 2026

Der Cyber Resilience Act (CRA) führt ein Melderegime mit strikten Zeitvorgaben ein: Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen Softwarehersteller dem als Koordinator benannten CSIRT und der ENISA innerhalb von 24 Stunden mitteilen — über zwei parallele dreistufige Regimes. Ab dem 11. September 2026 ist dies nicht mehr optional, sondern Pflicht. Dieser Artikel klärt auf, welche Fristen gelten, wer melden muss, und wie die einheitliche Meldeplattform nach Art. 16 CRA funktioniert.

Die drei Phasen der CRA-Implementierung

Bevor wir in die Details der Meldepflichten einsteigen, ein wichtiger Hinweis zur Chronologie nach Art. 71 CRA:

• 23. Oktober 2024: CRA wird verabschiedet
• 10. Dezember 2024: CRA tritt in Kraft
• 11. Juni 2026: Kapitel IV (Art. 35–51 — notifizierende Behörden und notifizierte Stellen) wird wirksam
• 11. September 2026: Phase 1 — Meldepflichten nach Art. 14 (aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle) werden verpflichtend
• 11. Dezember 2027: Phase 2 — Alle übrigen CRA-Anforderungen (Sicherheitsanforderungen aus Anhang I, Konformitätsbewertung, Sorgfaltspflichten aus Art. 13) sowie die Sanktionsvorschriften nach Art. 64 CRA treten in Kraft

Das bedeutet konkret: Die Meldepflichten kommen 15 Monate vor den anderen CRA-Anforderungen. Dies gibt Herstellern zwar Vorlauf, erzeugt aber auch neue Herausforderungen, da Schwachstellen-Management-Prozesse schneller aufgebaut werden müssen als andere Compliance-Massnahmen. Eine erste Übersicht zur Frage, wer überhaupt unter den CRA fällt, geben wir in Teil 1: SaaS und der CRA und in Teil 2: Drei-Elemente-Test.

Artikel 14: Zwei parallele Melderegimes

Artikel 14 CRA enthält zwei getrennte dreistufige Melderegimes:

• Art. 14 Abs. 1 und 2: Meldung aktiv ausgenutzter Schwachstellen in Produkten mit digitalen Elementen.
• Art. 14 Abs. 3 und 4: Meldung schwerwiegender Sicherheitsvorfälle, die sich auf die Sicherheit des Produkts auswirken.

Beide Regimes laufen jeweils dreistufig — Frühwarnung (24 h), Meldung (72 h) und Abschlussbericht. Sie müssen separat gehalten werden, weil Inhalt und Fristauslöser des Abschlussberichts unterschiedlich sind. Alle Meldungen erfolgen über die gemäss Art. 16 CRA eingerichtete einheitliche Meldeplattform (von ENISA betrieben, oft als CRA Single Reporting Platform / SRP bezeichnet) und gehen gleichzeitig an das als Koordinator benannte CSIRT (vgl. Art. 14 Abs. 7) und an die ENISA.

Regime 1: Aktiv ausgenutzte Schwachstellen (Art. 14 Abs. 1, 2)

Stufe 1 — Frühwarnung (24 h)

Unverzüglich, in jedem Fall aber innerhalb von 24 Stunden nach Kenntnis von einer aktiv ausgenutzten Schwachstelle: Frühwarnung mit mindestens der Angabe der Mitgliedstaaten, in deren Hoheitsgebiet das Produkt bereitgestellt wurde.

Stufe 2 — Meldung der Schwachstelle (72 h)

Unverzüglich, in jedem Fall aber innerhalb von 72 Stunden nach Kenntnis: Meldung mit allgemeinen Informationen — soweit verfügbar — über das betreffende Produkt, die allgemeine Art der Ausnutzung und der Schwachstelle, ergriffene Korrektur- oder Risikominderungsmassnahmen, Korrektur- oder Abhilfemassnahmen, die Nutzer ergreifen können, sowie eine Sensibilitätseinstufung der gemeldeten Informationen.

Stufe 3 — Abschlussbericht (14 Tage nach Verfügbarkeit der Abhilfe)

Spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmassnahme zur Verfügung steht, ein Abschlussbericht mit mindestens: Beschreibung der Schwachstelle inklusive Schweregrad und Auswirkungen, falls verfügbar Informationen zu böswilligen Akteuren, sowie Informationen zur bereitgestellten Sicherheitsaktualisierung oder anderen Korrekturmassnahmen.

Wichtig: Die 14-Tage-Uhr startet mit Verfügbarkeit der Abhilfemassnahme — nicht ab Kenntnisnahme. Hersteller, die keine Abhilfe bereitstellen können, geraten nicht automatisch in eine 14-Tage-Frist, riskieren aber andere Pflichtenverstösse (Anhang I Teil II Nr. 4 zur unverzüglichen Behebung).

Regime 2: Schwerwiegende Sicherheitsvorfälle (Art. 14 Abs. 3, 4)

Stufe 1 — Frühwarnung (24 h)

Unverzüglich, in jedem Fall innerhalb von 24 Stunden nach Kenntnis: Frühwarnung mit zumindest der Angabe, ob der Verdacht besteht, dass der Vorfall auf rechtswidrige oder böswillige Handlungen zurückzuführen ist, und gegebenenfalls den betroffenen Mitgliedstaaten.

Stufe 2 — Meldung des Sicherheitsvorfalls (72 h)

Innerhalb von 72 Stunden nach Kenntnis: Meldung mit Art des Vorfalls, einer Erstbewertung, ergriffenen Korrektur- oder Risikominderungsmassnahmen, Massnahmen für Nutzer und Sensibilitätseinstufung.

Stufe 3 — Abschlussbericht (1 Monat nach Übermittlung der 72-h-Meldung)

Innerhalb eines Monats nach Übermittlung der 72-h-Meldung (nicht ab Kenntnisnahme): ausführliche Beschreibung des Vorfalls inkl. Schweregrad und Auswirkungen, Art der Bedrohung bzw. zugrunde liegende Ursache, Angaben zu getroffenen und laufenden Abhilfemassnahmen.

Wann ist ein Sicherheitsvorfall "schwerwiegend"? (Art. 14 Abs. 5)

Die Verordnung definiert das eng. Ein Vorfall gilt als schwerwiegend, wenn:

• a) er sich negativ auf die Fähigkeit des Produkts auswirkt oder auswirken kann, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen, oder
• b) er zur Einführung oder Ausführung eines böswilligen Codes im Produkt oder im Netzwerk- und Informationssystem eines Nutzers geführt hat oder dazu führen kann.

Eine grossflächige Ausnutzung, der Bezug zu kritischer Infrastruktur oder ein konkreter Datenabfluss können Indikatoren sein — kommen in der Definition aber nur über die Generalklausel der CIA-Triade hinein.

Wann beginnt die "Kenntnis"?

Die 24-Stunden-Frist beginnt formal mit der Kenntnisnahme. Wie ENISA und die nationalen Marktüberwachungsbehörden den Begriff "Kenntnis" im Vollzug auslegen werden, ist Stand 24. April 2026 jedoch noch nicht abschliessend geklärt — die ENISA-Konsultationen zur einheitlichen Meldeplattform laufen, eine verbindliche Leitlinie liegt nicht vor. Hersteller sollten sich aus drei Gründen nicht auf eine wohlwollende Auslegung verlassen:

Erstens — Grundsatz aus dem EU-Produktrecht. Im New Legislative Framework und in der EuGH-Rechtsprechung zu vergleichbaren Marktüberwachungsregimen ist anerkannt, dass sich ein Hersteller nicht auf bewusst herbeigeführte Unkenntnis berufen kann. Die Argumentation "wir haben kein Monitoring, also hatten wir keine Kenntnis" trägt nach dieser Logik nicht — der Massstab ist, was ein sorgfältiger Marktteilnehmer hätte wissen müssen ("man hätte es wissen müssen"). Es ist juristisch unwahrscheinlich, dass die EU-Kommission und ENISA eine Auslegung wählen, die bewusste Sorglosigkeit belohnt.

Zweitens — Übergang in die Vollanwendung. Spätestens ab dem 11. Dezember 2027 wird die Sorgfaltspflicht zur Schwachstellenermittlung aus Art. 13 Abs. 8 in Verbindung mit Anhang I Teil II verbindlich. Anhang I Teil II verlangt unter anderem (Nr. 1) Schwachstellen und Komponenten zu ermitteln und zu dokumentieren, einschliesslich einer Software-Stückliste in einem gängigen maschinenlesbaren Format (siehe Teil 7: SBOM), (Nr. 3) die Sicherheit des Produkts regelmässig und wirksam zu testen und zu überprüfen, sowie (Nr. 5) eine Strategie für die koordinierte Offenlegung von Schwachstellen aufzustellen und umzusetzen. Die abgestufte Logik dieser Sorgfaltspflicht haben wir in Teil 3: Abgestufte CRA-Pflichten im Detail behandelt. Verstösse gegen Anhang I oder gegen die Pflichten aus Art. 13 und 14 sind ab diesem Zeitpunkt nach Art. 64 Abs. 2 CRA bussgeldbewehrt: bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres (es gilt der höhere Wert).

Drittens — konstruktive Kenntnis bei öffentlich gewordenen Schwachstellen. Sobald eine Schwachstelle öffentlich wird (CVE-Eintrag, BSI-Warnung, Threat-Intelligence-Publikation, Diskussion in Sicherheits-Communities), ist die Argumentation "wir wussten von nichts" faktisch nicht mehr haltbar. Marktüberwachungsbehörden werden in solchen Fällen nach dem Massstab der konstruktiven Kenntnis prüfen, ab wann ein sorgfältiger Hersteller davon hätte erfahren müssen — und die 24-Stunden-Uhr von dort an laufen lassen.

In der Übergangsphase zwischen September 2026 und Dezember 2027 bleibt eine Restunsicherheit darüber, wie streng die Auslegung tatsächlich ausfallen wird. Wer aber Detection-Prozesse erst nach der ersten Behördenuntersuchung aufbaut, riskiert in jedem Szenario eine offene rechtliche Auseinandersetzung über den Kenntnis-Zeitpunkt — und ab Dezember 2027 zusätzlich die volle Sanktionsbewehrung.

Sonderregel für Kleinst- und Kleinunternehmen (Art. 64 Abs. 10 lit. a)

Wichtig für KMU: Die Bussgelder nach Art. 64 Abs. 3 bis 9 gelten nicht gegenüber Herstellern, die als Kleinst- oder Kleinunternehmen im Sinne der KMU-Empfehlung 2003/361/EG gelten, soweit es um die Nichteinhaltung der 24-Stunden-Frühwarnung nach Art. 14 Abs. 2 lit. a oder Art. 14 Abs. 4 lit. a geht. Die Pflicht selbst bleibt bestehen, der Bussgeld-Hebel jedoch nicht. Verstösse gegen die zugrunde liegenden Sicherheitsanforderungen aus Anhang I bleiben hingegen auch für Kleinst- und Kleinunternehmen sanktionsbewehrt.

Die einheitliche Meldeplattform (Art. 16 CRA)

ENISA betreibt die nach Art. 16 CRA eingerichtete einheitliche Meldeplattform (Single Reporting Platform), die ab dem 11. September 2026 als zentraler Meldekanal für CRA-Meldungen fungieren wird. Diese Plattform ist nicht optional — alle Meldungen nach Art. 14 müssen über diesen Kanal erfolgen.

Die Plattform leitet Meldungen automatisch an das als Koordinator benannte CSIRT weiter; das CSIRT des Mitgliedstaates, in dem der Hersteller seine Hauptniederlassung hat, ist der Koordinator (Art. 14 Abs. 7). Für Hersteller mit Hauptniederlassung in Deutschland ist dies das Bundesamt für Sicherheit in der Informationstechnik (BSI). Wo SaaS- und Hybrid-Architekturen die Hersteller-Eigenschaft oder die Hauptniederlassung unklar machen, hilft unsere Einordnung in Teil 4: CRA-Grauzone.

Artikel 15: Freiwillige Meldungen

Während Art. 14 verpflichtende Meldungen regelt, eröffnet Art. 15 Herstellern und anderen natürlichen oder juristischen Personen die Möglichkeit, freiwillig zu melden:

• Schwachstellen in Produkten mit digitalen Elementen sowie Cyberbedrohungen, die das Risikoprofil eines Produkts beeinflussen können (Art. 15 Abs. 1).
• Sicherheitsvorfälle mit Auswirkung auf die Sicherheit des Produkts sowie Beinahe-Vorfälle, die zu einem solchen Vorfall hätten führen können (Art. 15 Abs. 2).

Die freiwilligen Meldungen folgen demselben Verfahren über die einheitliche Meldeplattform, aber ohne die 24-h-/72-h-Fristen. Das CSIRT kann verpflichtende Meldungen vorrangig bearbeiten (Art. 15 Abs. 3). Wichtig: Wenn eine andere Person als der Hersteller eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Vorfall meldet, unterrichtet das CSIRT den Hersteller unverzüglich (Art. 15 Abs. 4) — ab diesem Moment beginnt für den Hersteller die Kenntnis im Sinne von Art. 14.

Vertraulichkeit der freiwillig übermittelten Informationen ist in Art. 15 Abs. 5 geregelt; die freiwillige Meldung darf nicht zu zusätzlichen Pflichten der meldenden Person führen.

Achtung: Art. 15 ist nicht dasselbe wie die Pflicht zur Coordinated Vulnerability Disclosure Policy. Diese sitzt in Anhang I Teil II Nr. 5 und ist eine Hersteller-Pflicht, eine eigene CVD-Strategie aufzustellen und umzusetzen. Für KI-Komponenten in Produkten ergeben sich aus dem AI Act zusätzliche Offenlegungspflichten — siehe dazu Teil 5: AI Act trifft CRA und Teil 6: Hochrisiko-KI.

Das Verhältnis zu NIS-2-Meldepflichten

Eine häufig gestellte Frage lautet: Muss ich das gleiche Sicherheitsereignis zweimal melden — einmal unter NIS-2 und einmal unter CRA?

Die kurze Antwort: Nein, aber es ist kompliziert.

NIS-2 vs. CRA: Unterschiedliche Auslöser, unterschiedliche Ziele

NIS-2 (Richtlinie (EU) 2022/2555) verpflichtet kritische Infrastruktur-Betreiber (nicht Softwarehersteller) zur Meldung von Sicherheitsvorfällen, die erhebliche Auswirkungen auf die Kontinuität ihrer Dienste haben.

CRA verpflichtet Softwarehersteller zur Meldung von aktiv ausgenutzten Schwachstellen und schwerwiegenden Sicherheitsvorfällen in ihrer Software.

Die Szenarien sind also unterschiedlich:

• Ein Softwarehersteller, dessen Produkt von kritischen Infrastruktur-Betreibern genutzt wird, muss die Schwachstelle nach CRA melden.
• Der Infrastruktur-Betreiber, der von einer Schwachstelle in der Software des Herstellers betroffen ist, muss nach NIS-2 melden.
• Die Meldungen gehen an unterschiedliche Behörden (Koordinator-CSIRT/ENISA für CRA, nationale NIS-2-Behörden für Infrastruktur).

Doppelmeldungen vermeiden

Es gibt jedoch Überschneidungen:

• Wenn ein Softwarehersteller gleichzeitig ein kritischer Infrastruktur-Betreiber ist (z. B. Telekommunikationsunternehmen mit proprietärer Software), können Meldepflichten kumulativ auftreten.
• Die Implementierungsrichtlinien der EU und nationale Behörden arbeiten an einer Harmonisierung, um Doppelmeldungen zu vermeiden.

Die Kritik: Sind die 24-Stunden-Frist und die parallele Trennung realistisch?

Die 24-Stunden-Frist bleibt eine kontroverse Bestimmung des Melderegimes — ergänzt um die operative Komplexität, dass Hersteller im Echtzeitbetrieb entscheiden müssen, ob ein Ereignis eine "aktiv ausgenutzte Schwachstelle" oder ein "schwerwiegender Sicherheitsvorfall" ist (oder beides), weil davon die Inhalte der 24-h-Frühwarnung und die Frist-Logik des Abschlussberichts abhängen.

Die Hauptkritikpunkte

Detection ist der Engpass. Um eine Schwachstelle als "aktiv ausgenutzt" zu identifizieren, benötigen Hersteller Telemetrie von Kundengeräten, die Exploit-Versuche erkennt, Integration mit Threat-Intelligence-Quellen, die Fähigkeit "Forschungs-Chatter" von echter Ausnutzung zu unterscheiden sowie schnelle interne Eskalation und Triage. Viele KMU und sogar mittlere Softwarehersteller verfügen über keines dieser Systeme.

SBOM als Voraussetzung. Ohne ein aktuelles, maschinenlesbares Software Bill of Materials (SBOM) lässt sich nicht schnell genug feststellen, ob überhaupt alle Versionen eines Produkts betroffen sind. Siehe auch Teil 7: SBOM für Softwarehersteller.

Klassifikationsdruck. Die Trennung zwischen Schwachstelle (Art. 14 Abs. 1) und schwerwiegendem Sicherheitsvorfall (Art. 14 Abs. 3 mit der Definition in Abs. 5) muss innerhalb der 24-h-Frist getroffen werden — ohne klare Behörden-Leitlinie.

Internationale Herausforderungen. Softwarehersteller mit verteilten Teams in verschiedenen Zeitzonen können die Eskalation nicht immer innerhalb von 24 Stunden koordinieren.

Expertenposition und Ausblick

Der Center for Cybersecurity Policy und andere Fachorganisationen haben diese Bedenken während der Verhandlungen eingebracht. Die endgültige CRA enthält einige Präzisierungen: die Klarstellung, dass die Frist ab Kenntnisnahme beginnt, der Hinweis auf CSIRT-Helpdesks für KMU sowie die Bussgeld-Ausnahme für Kleinst- und Kleinunternehmen bei der 24-h-Frühwarnung (Art. 64 Abs. 10 lit. a). Die 24-Stunden-Frist bleibt dennoch ambitioniert — realistisch einhaltbar ist sie nur mit kontinuierlichen Prozessen, nicht mit punktuellen Massnahmen.

Warum Meldepflichten-Compliance in der Praxis scheitert

Die rechtlichen Fristen klingen auf dem Papier handhabbar — 24 Stunden, 72 Stunden, 14 Tage / 1 Monat. Was uns in Gesprächen mit Herstellern regelmässig begegnet, ist eine andere Realität. Spätestens mit der vollen Anwendung der CRA ab dem 11. Dezember 2027 verlangt die Verordnung nicht erst eine schnelle Meldung, sondern bereits eine kontinuierliche Schwachstellenbeobachtung als Vorstufe (Art. 13 Abs. 8 in Verbindung mit Anhang I Teil II — siehe Teil 3: Abgestufte CRA-Pflichten). Und auch in der Übergangsphase davor sollten Hersteller nicht auf eine wohlwollende Auslegung des Kenntnis-Begriffs setzen — wer ohne Detection-Prozesse arbeitet, exponiert sich gegen die Argumentation "man hätte es wissen müssen". Genau hier setzen die typischen Lücken an: Detection-Prozesse, die Exploit-Aktivitäten erst Tage später aufnehmen, weil Telemetrie und Threat-Intelligence-Feeds nicht zusammenlaufen. SBOMs, die im letzten Release erstellt und seitdem nicht aktualisiert wurden, sodass im Ernstfall niemand innerhalb von Stunden sagen kann, welche Produktversionen betroffen sind. Eskalationspfade, die zwar auf Papier existieren, aber noch nie unter Zeitdruck getestet wurden. Und fehlende, audit-feste Zeitstempel über den gesamten Meldeprozess hinweg — was die Einhaltung der Fristen gegenüber Marktüberwachungsbehörden nachträglich nicht mehr beweisbar macht.

Das ist kein einmaliges Projekt. Es ist ein kontinuierlicher Compliance-Prozess, der an jedem Release, jeder neuen CVE-Meldung und jeder Änderung in der Lieferkette wieder zuschlägt. Genau daran scheitern in unserer Erfahrung die meisten internen Initiativen: Der Detection-Prozess wird einmal aufgesetzt, aber Monate später fehlt der Bezug zur aktuellen Produktlandschaft, SBOM-Daten sind veraltet, und sobald eine Schwachstelle öffentlich wird und damit eine konstruktive Kenntnis kaum noch zu bestreiten ist, läuft die 24-Stunden-Uhr bereits, während interne Abstimmung zu Klassifikation, Zuständigkeiten und Meldeinhalt erst gestartet wird.

crAIready für Ihre Meldepflicht-Bereitschaft

crAIready ist die AI-gestützte SaaS-Plattform, die genau diesen Teil der CRA-Pflichten für Sie übernimmt:

• Automatisches Requirement-Mapping der Art-14-Pflichten (beide Regimes — Schwachstellen und Sicherheitsvorfälle, jeweils 24-h-/72-h-/14-Tage- bzw. 1-Monats-Fristen, Schwerwiegend-Definition aus Art. 14 Abs. 5, Art. 15 freiwillige Meldungen) gegen Ihr Produkt-Portfolio – inklusive Abgrenzung, welche Produkte unter welche Meldekategorie fallen.
• Kontinuierliche Gap-Analyse Ihrer Detection-, Eskalations- und Dokumentationsprozesse gegen Art. 14 CRA und NIS-2 – mit Ampelstatus und priorisiertem Massnahmen-Backlog, damit Sie vor dem 11. September 2026 wissen, wo die Zeit verloren geht.
• Integrierte SBOM- und Vulnerability-Daten als Grundlage: Sobald eine aktive Ausnutzung bekannt wird, sind die betroffenen Produktversionen und Kundensegmente sofort sichtbar – Voraussetzung, um die 24-Stunden-Frist überhaupt halten zu können.
• Audit-feste Dokumentation aller Meldevorgänge und internen Entscheidungen, inklusive Tamper-Proof-Logging der Zeitstempel – entscheidend, damit die Einhaltung der Fristen gegenüber dem Koordinator-CSIRT, der ENISA und Marktüberwachungsbehörden nachweisbar ist.

Der Einstieg ist unser CRA Quick Assessment: In 5–7 Werktagen erhalten Sie einen belastbaren Bericht, wo Ihre Meldepflicht-Readiness heute steht, welche Lücken CRA-relevant sind und welche Top-10-Massnahmen Sie vor September 2026 angehen sollten – zum Festpreis und ohne Beratungsabhängigkeit.

Querverweise zu vorherigen Artikeln der Serie

Diese Meldepflichten bauen auf grundlegenden CRA-Konzepten auf, die in vorherigen Artikeln behandelt wurden:

• Artikel 1: SaaS und der CRA — Grundlagen und Geltungsbereich
• Artikel 2: Drei-Elemente-Test — Wer fällt unter die CRA?
• Artikel 3: Abgestufte CRA-Pflichten — Risk Management und Due Diligence
• Artikel 4: CRA-Grauzone — Grenzen und Besonderheiten
• Artikel 5: AI Act trifft CRA — Spezialfall KI-Systeme
• Artikel 6: Hochrisiko-KI — KI-Risikobewertung
• Artikel 7: SBOM — Das Software Bill of Materials, Grundlage für Schwachstellenerkennung

Hinweis zur Methodik

Dieser Artikel basiert auf dem offiziellen Wortlaut der Verordnung (EU) 2024/2847 (Cyber Resilience Act) in der deutschen Sprachfassung, abgerufen von EUR-Lex und Springlex (Stand 24. April 2026). Die Fristen-, Inhalts- und Definitionsangaben (Art. 14 Abs. 1–5, Art. 15, Art. 16, Art. 64, Art. 71) wurden gegen den Verordnungstext gegengeprüft. Implementierungsrichtlinien und Plattformen sind teilweise noch in Entwicklung; eine verbindliche ENISA-Leitlinie zur Auslegung des Kenntnis-Begriffs in Art. 14 CRA liegt zum Redaktionsstand nicht vor. Die Einschätzungen zur Auslegung der "Kenntnis" und zur konstruktiven Kenntnis stützen sich auf etablierte Grundsätze des EU-Produktrechts (New Legislative Framework) und sind als Erwartung an die behördliche Praxis zu verstehen, nicht als verbindliche Auslegung. Für rechtliche und technische Detailfragen empfehlen wir, die offizielle ENISA-Dokumentation und die Leitlinien des Koordinator-CSIRT (in Deutschland: BSI) zu konsultieren.

Quellen

• Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (Cyber Resilience Act), insbesondere Art. 13 (Pflichten der Hersteller, Abs. 8 zur Schwachstellenbehandlung), Art. 14 (Meldepflichten), Art. 15 (freiwillige Meldungen), Art. 16 (einheitliche Meldeplattform), Art. 64 (Sanktionen, inkl. Abs. 10 lit. a Ausnahme für Kleinst-/Kleinunternehmen) und Art. 71 (Inkrafttreten und Anwendung), EUR-Lex
• Anhang I Teil II der Verordnung (EU) 2024/2847 — Schwachstellenmanagement (Nr. 1 SBOM, Nr. 3 Sicherheitstests, Nr. 5 Coordinated Vulnerability Disclosure Policy)
• Richtlinie (EU) 2022/2555 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über Massnahmen für ein hohes Mass an Cybersicherheit in der Union (NIS-2-Richtlinie), EUR-Lex
• Empfehlung 2003/361/EG der Kommission vom 6. Mai 2003 betreffend die Definition der Kleinstunternehmen sowie der kleinen und mittleren Unternehmen (für die Anwendung von Art. 64 Abs. 10 lit. a CRA), EUR-Lex
• Center for Cybersecurity Policy: Vulnerability Management Under The Cyber Resilience Act, CCSP

Im nächsten Artikel dieser Serie: Konformitätsbewertung und CE-Kennzeichnung unter dem CRA — welches der fünf Module nach Art. 32 CRA für Ihr Produkt passt, wann Sie zwingend eine notifizierte Stelle einschalten müssen und wie die BSI TR-03183-H Modul H mit einem ISO-27001-ISMS verbindet.