Zum Inhalt springen
UPSTREAM
CRA-MELDEPFLICHTEN

CRA-Meldepflichten seit 11. September 2026: was Hersteller jetzt melden müssen.

Stand: · ALVPHA Tech GmbH

Was gemeldet werden muss

  • jede aktiv ausgenutzte Schwachstelle in einem Produkt mit digitalen Elementen, von der der Hersteller Kenntnis erlangt (Art. 14 Abs. 1)
  • jeder schwerwiegende Sicherheitsvorfall, der sich auf die Sicherheit des Produkts auswirkt (Art. 14 Abs. 3)
  • schwerwiegend ist ein Vorfall, wenn er die Fähigkeit des Produkts beeinträchtigt, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen, oder wenn er zur Ausführung von Schadcode führt oder führen kann (Art. 14 Abs. 5)

Die Fristen

Alle Fristen laufen ab dem Zeitpunkt, an dem der Hersteller Kenntnis erlangt. Informationen, die schon übermittelt wurden, müssen nicht wiederholt werden.

  • 24 Stunden: Frühwarnung, bei Schwachstellen mit den Mitgliedstaaten, in denen das Produkt bereitgestellt wurde; bei Vorfällen zusätzlich, ob ein rechtswidriges oder böswilliges Handeln vermutet wird
  • 72 Stunden: Meldung mit allgemeinen Angaben zum Produkt, zur Art der Ausnutzung bzw. des Vorfalls, zu ergriffenen Maßnahmen und zu Maßnahmen, die Nutzer ergreifen können
  • Schwachstelle: Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme verfügbar ist, mit Beschreibung, Schweregrad, Auswirkungen und bereitgestellter Korrektur (Art. 14 Abs. 2)
  • Sicherheitsvorfall: Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung, mit Ursache und Abhilfemaßnahmen (Art. 14 Abs. 4)

Wohin gemeldet wird

Gemeldet wird über die einheitliche Meldeplattform, die die ENISA betreibt (Art. 16), und zwar über den Endpunkt des CSIRT, das in dem Mitgliedstaat als Koordinator benannt ist, in dem der Hersteller seine Hauptniederlassung in der EU hat. Maßgeblich ist der Mitgliedstaat, in dem die Entscheidungen zur Cybersicherheit der Produkte überwiegend getroffen werden (Art. 14 Abs. 7). Die ENISA hat gleichzeitig Zugriff.

Das CSIRT kann Zwischenberichte anfordern (Art. 14 Abs. 6).

Nutzer und Open-Source-Komponenten

  • Betroffene Nutzer, gegebenenfalls alle Nutzer, sind über die Schwachstelle oder den Vorfall und mögliche Gegenmaßnahmen zu informieren, wo sinnvoll maschinenlesbar (Art. 14 Abs. 8)
  • Findet der Hersteller eine Schwachstelle in einer integrierten Komponente, auch einer quelloffenen, meldet er sie der Person oder Einrichtung, die die Komponente herstellt oder wartet (Art. 13 Abs. 6)
  • Hat der Hersteller selbst eine Korrektur für die Komponente entwickelt, teilt er Code oder Unterlagen dem Maintainer mit

Gilt das auch für ältere Produkte?

Ja. Die übrigen CRA-Anforderungen gelten für vor dem 11. Dezember 2027 in Verkehr gebrachte Produkte nur bei wesentlicher Änderung. Die Meldepflichten aus Art. 14 gelten dagegen ausdrücklich auch für diese Produkte (Art. 69 Abs. 3).

Was Teams vorbereitet haben sollten

  • Komponentenbestand und releasebezogene SBOM, um schnell zu klären, welche Produkte und Versionen betroffen sind
  • Triage mit Kriterien für „aktiv ausgenutzt“, zum Beispiel über Exploit-Hinweise und Kataloge wie CISA KEV
  • festgelegte Zuständigkeit, Vertretung und Freigabe für Meldungen, damit 24 Stunden auch am Wochenende einzuhalten sind
  • Vorlagen für Frühwarnung, Meldung und Abschlussbericht sowie für die Nutzerinformation
  • einen Weg, Schwachstellen an Open-Source-Maintainer zu melden

Häufige Fragen

Ab wann gilt eine Schwachstelle als „aktiv ausgenutzt“?

Nach Art. 3 Nr. 42 CRA, wenn verlässliche Nachweise vorliegen, dass ein böswilliger Akteur sie in einem System ohne Zustimmung des Systemeigners ausgenutzt hat. Ob das im Einzelfall zutrifft, ist Teil der Triage und sollte dokumentiert werden.

Ersetzt die CRA-Meldung andere Meldepflichten, etwa nach NIS2?

Nein, nicht automatisch. Ob und wie sich Meldungen nach CRA und anderen Regelungen überschneiden, hängt von Rolle und Sektor ab und sollte rechtlich geprüft werden.

Was übernimmt ALVPHA Upstream dabei?

Wir unterstützen Bestand, SBOM und die Triage konkreter Findings und dokumentieren Bewertung und Entscheidung. Die Meldung selbst und die rechtliche Bewertung bleiben beim Hersteller; wir geben keine Rechtsberatung.

QUELLEN

Dieser Artikel dient der fachlichen Orientierung und ist keine Rechtsberatung. Maßgeblich sind die verlinkten Primärquellen in ihrer jeweils geltenden Fassung.

Wo steht Ihr Team?

Der kostenlose Trust Check ordnet Ihre Selbstauskunft in sieben Dimensionen ein, von Komponentenbestand bis Nachweisfähigkeit. Für konkrete Fälle vereinbaren wir ein Erstgespräch.

Passende Leistung: Schwachstellen-Triage

Alle Artikel →
SBOM

Was ist eine SBOM und was muss sie enthalten?

Eine SBOM (Software Bill of Materials) ist eine maschinenlesbare Stückliste aller Komponenten einer Software, mit Version, Herkunft und Abhängigkeiten. Sie ist die Grundlage, um bei einer neuen Schwachstelle schnell zu wissen, ob ein Produkt betroffen ist. Der Cyber Resilience Act verlangt von Herstellern eine SBOM, die mindestens die obersten Abhängigkeiten abdeckt.

Artikel lesen
TRIAGE

Schwachstellen-Triage: von der CVE-Meldung zur Entscheidung.

Triage heißt, einen Schwachstellenbefund strukturiert zu bewerten: Ist unser Produkt tatsächlich betroffen, wie dringend ist es, und was entscheiden wir? Der Schweregrad (CVSS) allein reicht dafür nicht; Ausnutzungswahrscheinlichkeit (EPSS), belegte Ausnutzung (KEV) und der konkrete Einsatz im Produkt gehören dazu. Das Ergebnis wird nachvollziehbar dokumentiert, zum Beispiel als VEX-Aussage.

Artikel lesen
GOVERNANCE

Open-Source-Governance: Regeln, Lizenzen, Zuständigkeiten.

Open-Source-Governance regelt, wie eine Organisation Open Source auswählt, einsetzt, dokumentiert und pflegt. Sie verbindet Lizenz-Compliance, Sicherheitsprozesse und klare Zuständigkeiten. Ziel ist nicht, Open Source zu bremsen, sondern ihren Einsatz nachvollziehbar und verantwortbar zu machen.

Artikel lesen
CRA

Cyber Resilience Act: was Hersteller zu Open Source wissen sollten.

Der Cyber Resilience Act (Verordnung (EU) 2024/2847) legt Cybersicherheitsanforderungen für Produkte mit digitalen Elementen fest, die in der EU bereitgestellt werden. Für Hersteller heißt das unter anderem: Komponenten dokumentieren (SBOM), Schwachstellen behandeln, Sicherheitsupdates bereitstellen und aktiv ausgenutzte Schwachstellen fristgerecht melden. Die Meldepflichten gelten seit dem 11. September 2026, die übrigen Anforderungen ab dem 11. Dezember 2027.

Artikel lesen