Wie sollten sich Hersteller auf die CRA-Meldung von Schwachstellen und Sicherheitsvorfällen über die ENISA Single Reporting Platform vorbereiten, und kann der Prozess derzeit automatisiert werden?

Einführung und regulatorischer Rahmen

Ab dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen die Meldepflichten des Cyber Resilience Act (CRA) für bestimmte Cybersicherheitsereignisse erfüllen. Diese regulatorische Veränderung stellt eine der umfassendsten Neugestaltungen der Sicherheitsstandards für Hardware und Software in der Geschichte der Europäischen Union dar und verpflichtet Technologieanbieter, Gerätehersteller und Softwareentwickler, die auf dem EU-Markt tätig sind, unmittelbar zur Einhaltung gesetzlicher Vorgaben.

Die ENISA Single Reporting Platform (SRP) ist das zentrale Online-System für die Meldung von:

• aktiv ausgenutzten Schwachstellen und

• schwerwiegenden Sicherheitsvorfällen, die Produkte mit digitalen Elementen betreffen.

Eine Meldung ist erforderlich, wenn ein Hersteller Kenntnis von einer aktiv ausgenutzten Schwachstelle in seinem Produkt oder von einem schwerwiegenden Sicherheitsvorfall erhält, der die Sicherheit des Produkts beeinträchtigt.

Nach dem Cyber Resilience Act umfasst die Definition eines Produkts mit digitalen Elementen eine große Bandbreite an vernetzten Geräten, eigenständiger Software und eingebetteten Hardwarekomponenten. Daher können Hersteller diese Anforderungen nicht als isolierte IT-Themen behandeln. Vielmehr erfordern sie eine durchgängige Integration in Produktdesign, Qualitätssicherung, Field Engineering und rechtliche Compliance-Funktionen.

Strenge Meldefristen und mehrstufige Abläufe

Der Meldeprozess ist zeitkritisch:

• innerhalb von 24 Stunden: muss eine Frühwarnung übermittelt werden;

• innerhalb von 72 Stunden: muss eine detailliertere Meldung zur Schwachstelle oder zum Sicherheitsvorfall folgen;

• ein Abschlussbericht ist zu einem späteren Zeitpunkt erforderlich, sobald weitere Informationen aus der Untersuchung und zur Behebung vorliegen.

Für die operative Vorbereitung ist es entscheidend, die genauen Anforderungen jeder Phase zu verstehen:

1. Die 24-Stunden-Frühwarnung: Diese erste Meldung soll ENISA und die nationalen Computer Security Incident Response Teams (CSIRTs) auf eine potenzielle systemische Bedrohung aufmerksam machen. Sie muss angeben, ob davon ausgegangen wird, dass die Schwachstelle oder der Vorfall auf böswillige Absichten zurückzuführen ist und ob eine grenzüberschreitende Bedrohung innerhalb des EU-Marktes besteht.

2. Die detaillierte 72-Stunden-Meldung: Aufbauend auf der Frühwarnung muss diese Meldung eine ausführlichere technische Analyse enthalten, einschließlich erster Bewertungen der Auswirkungen, Schweregradbewertungen (wie CVSS) und vorübergehender Maßnahmen zur Risikominderung, die den Nutzern empfohlen werden.

3. Der abschließende umfassende Bericht: Dieser Bericht wird innerhalb eines Monats nach Behebung des Vorfalls oder der Schwachstelle eingereicht und muss eine detaillierte Ursachenanalyse, eine Beschreibung eines dauerhaften Patches oder Softwareupdates sowie die umgesetzten Korrekturmaßnahmen zur Vermeidung einer Wiederholung enthalten.

Aktueller operativer Status der ENISA SRP

Wie ist der aktuelle Status der ENISA SRP? Mit Stand vom 3. September 2026 gibt ENISA an, dass die SRP bis zum 11. September 2026 betriebsbereit sein soll.

ENISA hat bereits Leitlinien zur Benutzerregistrierung, zur Einreichung von Meldungen und zum SRP-Workflow veröffentlicht. Die endgültige öffentliche Produktions-URL wurde jedoch noch nicht veröffentlicht.

Hersteller sollten ihre internen Meldeprozesse, Verantwortlichkeiten und den EU-Login-Zugang bereits vorbereiten, bevor die Meldepflicht in Kraft tritt.

Mit der Einrichtung interner Abläufe zu warten, bis das Produktivportal online ist, birgt erhebliche Risiken. Da innerhalb von 24 Stunden kein Spielraum für administrativen Aufwand, rechtliche Prüfungen oder die Klärung von Zuständigkeiten während eines tatsächlichen Sicherheitsvorfalls bleibt, müssen Unternehmen bereits deutlich vor September 2026 Tabletop-Übungen und Probeläufe durchführen.

Automatisierungsmöglichkeiten und technische Einschränkungen

Kann die CRA-Meldung automatisiert werden? Nur teilweise. ENISA stellt derzeit keine API für die SRP zur Verfügung. Das bedeutet, dass externe Plattformen CRA-Meldungen nicht automatisch direkt an das ENISA-System übermitteln können.

Das Fehlen einer öffentlichen Programmierschnittstelle (Application Programming Interface, API) stellt eine erhebliche Hürde für Unternehmen dar, die eine durchgängige Orchestrierung ihrer Sicherheitsprozesse anstreben. Moderne Security Operations Center (SOCs) setzen stark auf automatisierte Ticketing- und Reaktionsprozesse. Für die CRA-Compliance über die ENISA SRP bleibt jedoch für die abschließende Übermittlung weiterhin ein Human-in-the-Loop erforderlich.

Ein großer Teil der Vorbereitung kann jedoch automatisiert werden. ONEKEY kann Hersteller dabei unterstützen:

• relevante Schwachstellen zu identifizieren,
• diese mit betroffenen Produkten und Komponenten zu verknüpfen,
• technische Nachweise zu erfassen und zu strukturieren und
• die für die 24-Stunden- und 72-Stunden-Meldungen erforderlichen Informationen vorzubereiten.

Durch die Automatisierung des Software-Bill-of-Materials-(SBOM)-Managements, der automatisierten Binäranalyse und des kontinuierlichen Monitorings können automatisierte Plattformen für Sicherheitsanalysen die Zeit, die für die Zusammenführung komplexer technischer Daten in standardisierte regulatorische Formate erforderlich ist, drastisch reduzieren.

Die eigentliche Übermittlung an die ENISA SRP muss derzeit weiterhin manuell durch einen autorisierten Benutzer erfolgen.

Strategischer Fahrplan für Hersteller

Um die vollständige Compliance bis zum 11. September 2026 sicherzustellen, sollten Hersteller einen strukturierten Fünf-Schritte-Plan zur Vorbereitung umsetzen:

1. Bestandsaufnahme und SBOM-Mapping: Eine genaue und aktuelle Software Bill of Materials für alle vernetzten Produkte und eingebetteten Systeme pflegen.
2. Integration der Incident-Response-Triage: Interne Triage-Prozesse so weiterentwickeln, dass Sicherheitsforscher und Entwickler Hinweise auf eine aktive Ausnutzung automatisch kennzeichnen.
3. Berechtigungs- und Zugriffsmanagement: Autorisierte unternehmensbezogene EU-Login-Konten für benannte primäre und stellvertretende Compliance-Verantwortliche einrichten.
4. Bibliothek mit vorformatierten Vorlagen: Vorlagen für die 24-Stunden- und 72-Stunden-Meldungen vorab erstellen, um die manuelle Eingabe in zeitkritischen Situationen zu minimieren.
5. Kontinuierliches Monitoring und Automatisierungstools: Automatisierte Plattformen zur Korrelation von Schwachstellen einsetzen, um die für die Datenerfassung benötigte Zeit drastisch zu verkürzen.