Pflichten für Hersteller nach dem Cyber Resilience Act

Der Cyber Resilience Act (CRA), offiziell Cyberresilienz-Verordnung, verpflichtet jeden Hersteller, der ein Produkt mit digitalen Elementen in der EU verkauft. Sie müssen das Produkt sicher bauen, Schwachstellen während des Supportzeitraums beheben, aktiv ausgenutzte Lücken melden und das alles in Unterlagen belegen. Die meisten Pflichten gelten ab dem 11. Dezember 2027, die Meldepflicht schon seit dem 11. September 2026.

Die Pflichten stehen vor allem in Artikel 13 und Artikel 14 der Verordnung (EU) 2024/2847. Hersteller ist, wer ein Produkt unter eigenem Namen oder eigener Marke auf den Markt bringt. Wenn Sie also einen Sensor, ein Gateway oder eine App unter Ihrem Firmennamen verkaufen, sind Sie gemeint, auch wenn ein Dienstleister die Platine entwickelt hat.

Vor dem Verkauf: das Produkt

Der Kern ist Anhang I. Er enthält 22 grundlegende Cybersicherheitsanforderungen: einen allgemeinen Grundsatz in Teil I Nummer 1, dreizehn Produktanforderungen in Teil I Nummer 2 Buchstaben a bis m und acht Anforderungen an die Schwachstellenbehandlung in Teil II Nummern 1 bis 8.

Einige davon betreffen Gerätehersteller ganz direkt. Das Produkt darf beim Inverkehrbringen keine bekannten ausnutzbaren Schwachstellen haben (Teil I Nr. 2 Buchstabe a). Es muss sicher voreingestellt sein und sich zurücksetzen lassen (b). Sicherheitsupdates müssen möglich sein, standardmäßig automatisch, mit Opt-out (c). Und Teil II Nummer 1 verlangt eine maschinenlesbare Stückliste (SBOM), also eine Liste aller Software-Bestandteile, mindestens für die obersten Abhängigkeiten.

Damit Sie wissen, welche Anforderungen für Ihr Produkt wie gelten, schreibt Artikel 13 Absätze 2 bis 4 eine Bewertung der Cybersicherheitsrisiken vor. Diese Risikobewertung halten Sie aktuell, und sie gehört in die technische Dokumentation. Passt eine Anforderung nicht zu Ihrem Produkt, begründen Sie das dort schriftlich.

Fremde Bauteile entlasten Sie nicht. Artikel 13 Absatz 5 verlangt Sorgfalt bei Komponenten von Dritten, ausdrücklich auch bei Open-Source-Bibliotheken. Finden Sie eine Schwachstelle in so einer Komponente, melden Sie sie dem, der sie pflegt (Artikel 13 Absatz 6).

Vor dem Verkauf: die Unterlagen

Was	Wo im CRA	Kurz erklärt
Technische Dokumentation	Artikel 31, Anhang VII	Beschreibung, Risikobewertung, SBOM, Testberichte
Konformitätsbewertung	Artikel 32	Meist Selbstbewertung (Modul A), bei manchen Produktklassen mit Drittstelle
EU-Konformitätserklärung	Artikel 28, Anhang V	Sie erklären und unterschreiben, dass Anhang I erfüllt ist
CE-Kennzeichnung	Artikel 29 und 30	Kommt erst nach der Bewertung aufs Produkt
Informationen für Nutzer	Anhang II	Kontakt, Supportende, sichere Nutzung, Updates
Kennzeichnung	Artikel 13 Absätze 15 und 16	Typ- oder Seriennummer, Name und Kontakt des Herstellers

Welche Konformitätsbewertung für Sie gilt, hängt von der Produktklasse ab. Die meisten Geräte sind Standardprodukte und können selbst bewertet werden. Router, smarte Türschlösser oder Sicherheitskameras stehen dagegen in Anhang III und brauchen unter Umständen eine benannte Stelle (im Verordnungstext: notifizierte Stelle). Mehr dazu im Ratgeber zu den Produktklassen.

Nach dem Verkauf: jahrelang weiter

Hier unterschätzen viele kleine Teams den Aufwand. Der CRA endet nicht mit der Auslieferung.

• Supportzeitraum. Sie legen ihn fest, und er beträgt mindestens fünf Jahre (Artikel 13 Absatz 8). Nur wenn das Produkt erwartbar kürzer genutzt wird, darf er kürzer sein. Das Enddatum, mindestens Monat und Jahr, nennen Sie beim Kauf (Artikel 13 Absatz 19).
• Schwachstellen beheben. Während des Supportzeitraums behandeln Sie Schwachstellen nach Anhang I Teil II: ohne Verzögerung beheben, Updates sicher verteilen, kostenlos bereitstellen, behobene Lücken offenlegen.
• Updates aufbewahren. Jedes Sicherheitsupdate bleibt mindestens 10 Jahre oder für den Rest des Supportzeitraums verfügbar, je nachdem, was länger ist (Artikel 13 Absatz 9).
• Ansprechpartner. Sie benennen eine zentrale Anlaufstelle, über die Nutzer Schwachstellen melden können (Artikel 13 Absatz 17), und eine Richtlinie zur koordinierten Offenlegung (Anhang I Teil II Nr. 5).
• Melden. Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden Sie nach Artikel 14, mit einer Frühwarnung innerhalb von 24 Stunden. Details im Ratgeber zur Meldepflicht.
• Aufbewahren. Technische Dokumentation und Konformitätserklärung halten Sie 10 Jahre oder für den Supportzeitraum bereit, je nachdem, was länger ist (Artikel 13 Absatz 13).

Was oft übersehen wird

Die Meldepflicht gilt auch für Geräte, die Sie schon vor dem 11. Dezember 2027 verkauft haben (Artikel 69 Absatz 3). Für die übrigen Pflichten gilt bei solchen Altgeräten etwas anderes: Sie fallen erst unter den CRA, wenn Sie sie danach wesentlich verändern (Artikel 69 Absatz 2).

Zweitens: Die Pflichten sind dieselben, egal ob Sie fünf oder fünfhundert Leute beschäftigen. Kleine Unternehmen bekommen einige Erleichterungen, etwa eine vereinfachte technische Dokumentation (Artikel 33 Absatz 5). Die Anforderungen aus Anhang I bleiben aber gleich. Was genau leichter wird, steht im Ratgeber für KMU.

Und drittens gibt es Dinge, die nur Sie selbst tun können. Kein Werkzeug unterschreibt Ihre Konformitätserklärung, legt Ihren Supportzeitraum fest oder liefert die Updates aus. Diese Entscheidungen bleiben beim Hersteller.

Was Proofsheet hier erstellt

Proofsheet ist eine Web-App. Sie laden eine Datei hoch, zum Beispiel Ihr Firmware-Image oder Ihre Android-App. In wenigen Minuten listet die App die Bestandteile und Versionen auf, soweit die Datei sie zeigt, gleicht exakte Versionen mit der NVD ab (der US-Schwachstellendatenbank) und markiert Lücken, die auf der CISA-Liste aktiv ausgenutzter Schwachstellen stehen. Das Ergebnis ordnet sie den 22 Punkten aus Anhang I zu, jeweils als belegt, teilweise oder offen.

Den Punkt „keine bekannten ausnutzbaren Schwachstellen“ markiert die App nie höher als teilweise. Sie sieht nur die Teile, die sie in der Datei erkennt. Kein Mensch sieht sich Ihre Datei an, und sie wird innerhalb von 24 Stunden gelöscht.

Das ist ein technischer Nachweis, kein rechtliches Zertifikat. Wie ein erstellter Bericht aussieht, zeigt der Beispielbericht. Als Nächstes lohnt sich der Blick auf die Fristen.