CRA-Schwachstellenbehandlung: Was jeder Hersteller vor September 2026 wissen muss

Der Cyber Resilience Act (CRA) der Europäischen Union ist ein tektonischer Wandel darin, wie Software und vernetzte Geräte reguliert werden. Zum ersten Mal ist Cybersicherheit nicht mehr nur eine Best Practice, sondern eine Voraussetzung für den Marktzugang. Wenn Sie Produkte mit digitalen Elementen (PDEs) herstellen und in der EU verkaufen, läuft die Uhr. Sie haben bis September 2026 Zeit, Ihre Prozesse zur Schwachstellenbehandlung umzubauen, sonst drohen erhebliche Strafen.

Während der CRA ein breites Spektrum an Cybersicherheitsanforderungen abdeckt, von Secure-by-Design-Prinzipien bis zur Vorfallmeldung, fallen die operativ anspruchsvollsten Pflichten in den Zuständigkeitsbereich dieses neuen Prozesses. Es geht nicht nur darum, Fehler schneller zu patchen; es geht darum, eine vollständig prüffähige Infrastruktur für das Empfangen, Triagieren, Beheben und Offenlegen von Sicherheitsschwachstellen aufzubauen.

Schlüsseln wir genau auf, was der CRA verlangt und welche praktischen Schritte Ihre Entwicklungs- und Sicherheitsteams heute zu gehen beginnen müssen.

Der Geltungsbereich: Gilt der CRA für Sie?

Bevor wir in die Anforderungen eintauchen, klären wir, wer betroffen ist. Die Reichweite des CRA ist bewusst groß.

• Produkte mit digitalen Elementen (PDEs): Das umfasst im Wesentlichen jedes Hardware- oder Softwareprodukt mit einer Datenverbindung (logisch oder physisch). Dazu gehören IoT-Geräte, Smart-Home-Geräte, industrielle Steuerungssysteme, Netzwerkausrüstung, Betriebssysteme, Passwortmanager und die meisten kommerziellen Softwareanwendungen.
• Der „Wirtschaftsakteur“: Die Hauptlast fällt auf den Hersteller. Doch auch Einführer und Händler haben Pflichten, zu überprüfen, ob der Hersteller seine Anforderungen erfüllt hat. Bringt ein Einführer oder Händler ein Produkt unter eigenem Namen in Verkehr oder verändert ein Produkt wesentlich, wird er unter dem CRA zum Hersteller.
• Open-Source-Ausnahme (mit Vorbehalten): Freie und quelloffene Software (FOSS) ist generell ausgenommen, außer sie wird im Rahmen einer kommerziellen Tätigkeit bereitgestellt (z. B. Sie verlangen Geld für Support, Enterprise-Funktionen oder hosten sie als SaaS).

Wenn Ihr Produkt dieser Beschreibung entspricht, sind die Anforderungen zur Schwachstellenbehandlung in Anhang I, Teil II nun Teil Ihrer rechtlichen Compliance-Checkliste.

Die zentralen Pflichten zur Schwachstellenbehandlung

Der CRA schreibt vor, dass Hersteller einen systematischen, dokumentierten Ansatz für das Schwachstellenmanagement über die gesamte unterstützte Lebensdauer des Produkts (oder 5 Jahre, je nachdem, was kürzer ist) etablieren. Hier sind die zentralen Säulen, die Sie umsetzen müssen:

1. Der Prozess der koordinierten Offenlegung von Schwachstellen (CVD)

Sie können sich nicht länger darauf verlassen, dass Forscher raten, wen sie anschreiben sollen, wenn sie einen Fehler finden. Der CRA verlangt einen formalisierten CVD-Prozess.

• Öffentliche Kontaktstelle: Sie müssen eine gut sichtbare, leicht zugängliche zentrale Kontaktstelle bereitstellen, an die Sicherheitsforscher Schwachstellen melden können. Das sollte kein allgemeines Support-Formular sein; es braucht einen dedizierten Sicherheitskanal (z. B. [email protected] oder ein eigenes Portal).
• Zeitnahe Bestätigung: Wird eine Meldung eingereicht, müssen Sie den Eingang innerhalb eines streng definierten Zeitrahmens bestätigen (Best Practice der Branche und Normentwürfe schlagen 48 Stunden vor).
• Sichere Kommunikation: Forscher müssen eine Möglichkeit haben, Schwachstellen sicher zu melden, um ein Abfangen zu verhindern (z. B. PGP-Verschlüsselung oder ein sicheres Einreichungsportal).

2. Triage, Behebung und Fristen

Es reicht nicht, die Meldungen nur entgegenzunehmen; Sie müssen sie aktiv handhaben.

• Untersuchung: Sie müssen gemeldete Schwachstellen umgehend untersuchen.
• Behebung: Sie sind gesetzlich verpflichtet, Schwachstellen unverzüglich zu adressieren und zu beheben.
• Sicherheitsupdates: Updates müssen Nutzern kostenlos, sicher und nahtlos (automatisch, wo technisch machbar) bereitgestellt werden. Die Updates müssen klar von Funktionsupdates getrennt sein.

3. Die SBOM-Grundlage

Sie können nicht beheben, von dem Sie nicht wissen, dass Sie es haben. Der CRA erhebt die Software-Stückliste (SBOM) von einem „Nice-to-have“ zu einem verpflichtenden Artefakt.

• Kontinuierliche Pflege: Sie müssen ein SBOM erstellen und konsequent pflegen, das die Komponenten und Abhängigkeiten Ihres PDE auflistet.
• Schwachstellenkorrelation: Das SBOM muss kontinuierlich gegen bekannte Schwachstellendatenbanken (wie die NVD oder die kommende Datenbank von ENISA) geprüft werden, um geerbte Risiken zu identifizieren.

4. Öffentliche Offenlegung und Sicherheitsmeldungen

Sobald eine Schwachstelle behoben ist, ist der Prozess nicht vorbei.

• Sicherheitsmeldungen: Sie müssen die Schwachstelle und die verfügbare Korrektur öffentlich offenlegen.
• Maschinenlesbare Formate: Die Branche bewegt sich rasch hin zu maschinenlesbaren Sicherheitsmeldungen (und Regulierer werden sie wahrscheinlich erwarten), etwa dem OASIS Common Security Advisory Framework (CSAF 2.0).
• Transparenz: Die Sicherheitsmeldung muss die betroffenen Versionen, den Schweregrad (CVSS-Wert), die Auswirkungen und klare Anweisungen zur Behebung darlegen.

5. Verpflichtende Meldung an Behörden (Artikel 14)

Das ist vielleicht die einschüchterndste neue Anforderung für viele Hersteller. Entdecken Sie nach Artikel 14 eine aktiv ausgenutzte Schwachstelle in Ihrem Produkt, müssen Sie das zuständige nationale Computer Security Incident Response Team (CSIRT) oder ENISA benachrichtigen.

• Die 24-Stunden-Regel: Sie müssen innerhalb von 24 Stunden nach Kenntniserlangung von der aktiven Ausnutzung eine erste Frühwarnmeldung abgeben.
• Folgemeldung: Eine detailliertere Schwachstellenmeldung muss innerhalb von 72 Stunden folgen, mit einem Abschlussbericht, der 14 Tage nach Verfügbarkeit einer Risikominderungsmaßnahme erforderlich ist.

(Hinweis: Schwerwiegende Sicherheitsvorfälle haben ähnliche, parallele Meldefristen.)

Praktische Schritte zur Vorbereitung auf September 2026

Diese Infrastruktur aufzubauen braucht Zeit. Wenn Sie bis Anfang 2026 warten, um zu beginnen, werden Sie die Frist wahrscheinlich verpassen. Hier ist der operative Fahrplan, den Sie jetzt umzusetzen beginnen sollten.

Schritt 1: Ihre „Eingangstür“ einrichten (Q3/Q4 2025)

Betreiben Sie Ihr Sicherheitsprogramm nicht länger aus einem geteilten Postfach heraus.

• Eine Richtlinie zur Offenlegung von Schwachstellen (VDP) veröffentlichen: Legen Sie Ihre Spielregeln für Forscher klar dar. Was ist im Geltungsbereich? Welche Reaktionszeiten erwarten Sie? Ziehen Sie ISO/IEC 29147 zur Orientierung heran.
• Einen sicheren Eingangsmechanismus bereitstellen: Setzen Sie ein CVD-Portal oder ein sicheres, PGP-gestütztes E-Mail-System ein. Stellen Sie sicher, dass Sie die Werkzeuge haben, um das 48-Stunden-Bestätigungsfenster zu garantieren. Genau dieses Problem wurde CVD Portal gebaut zu lösen.

Schritt 2: Den internen Motor bauen (Q1/Q2 2026)

Sie brauchen die interne Verrohrung, um das zu leiten und zu beheben, was durch die Eingangstür kommt.

• Ihr minimal tragfähiges PSIRT definieren: Bestimmen Sie, wer für die Triage von Meldungen, das Vorantreiben der Korrektur in der Entwicklung und die Kommunikation mit dem Forscher verantwortlich ist. Selbst in einem kleinen Start-up müssen diese Rollen ausdrücklich zugewiesen werden.
• SBOM-Erstellung automatisieren: Integrieren Sie die SBOM-Erstellung (z. B. mit CycloneDX oder SPDX) in Ihre CI/CD-Pipeline. Manuelle Erstellung ist nicht nachhaltig.
• Schwachstellen-Scanning umsetzen: Nutzen Sie Werkzeuge (SCA, DAST, SAST), um Ihre Codebasis und Ihr SBOM kontinuierlich gegen bekannte CVEs zu scannen.

Schritt 3: Reaktion auf Vorfälle und Meldung formalisieren (Q2/Q3 2026)

Das 24-Stunden-Meldefenster aus Artikel 14 ist unerbittlich. Sie können Ihr Meldeprotokoll nicht herausfinden, während ein aktiver Exploit sich durch Ihre Kundenbasis frisst.

• Standardarbeitsanweisungen (SOPs) entwerfen: Erstellen Sie Playbooks dafür, wie eine eingereichte Schwachstelle vom Postfach {"->"} Jira-Ticket {"->"} PR {"->"} Release wandert.
• Die CSIRT-Brücke einrichten: Wissen Sie genau, an wen, wie und wo Sie Ihre Artikel-14-Meldungen in dem Mitgliedstaat einreichen müssen, in dem Sie niedergelassen sind. Entwerfen Sie die Vorlagen jetzt.
• Auf maschinenlesbare Ausgabe vorbereiten: Strukturieren Sie Ihre internen Schwachstellendaten so, dass sie sich leicht nach CSAF 2.0 oder das von ENISA letztlich vorgeschriebene Schema exportieren lassen.

Die Kosten der Nichteinhaltung

Der CRA besteht nicht nur aus Leitlinien; er hat Zähne. Die Nichteinhaltung der grundlegenden Cybersicherheitsanforderungen (zu denen die Schwachstellenbehandlung gehört) kann zu Bußgeldern von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes führen, je nachdem, was höher ist. Bußgelder für das Versäumen der Meldepflichten (Artikel 14) können 10 Millionen Euro oder 2 % des Umsatzes erreichen.

Über die Bußgelder hinaus haben Marktüberwachungsbehörden die Befugnis, Ihre Produkte zurückzurufen oder vollständig vom EU-Markt zu nehmen.

Fazit

Der Cyber Resilience Act erzwingt eine Reifung der europäischen Software- und Hardwareindustrie. Die koordinierte Offenlegung von Schwachstellen ist nicht länger die exklusive Domäne von Tech-Giganten mit riesigen Sicherheitsbudgets; sie ist eine Grundanforderung für die Geschäftstätigkeit.

Der Zeitplan ist ambitioniert, aber erreichbar, wenn Sie jetzt mit dem Aufbau der Infrastruktur beginnen. Konzentrieren Sie sich zuerst auf Ihre „Eingangstür“, Ihren Erfassungsprozess und Ihre Richtlinie, und bauen Sie systematisch die internen Motoren auf, die zum Triagieren, Beheben und Melden erforderlich sind. Die Ära des stillen Patchens und ignorierter Forscher-E-Mails ist vorbei.