Cyber Resilience Act Anforderungen: Die Pflichten aus Annex I verständlich erklärt

 

Wer festgestellt hat, dass sein Produkt unter den Cyber Resilience Act fällt, steht sofort vor der eigentlichen Frage: Was genau muss ich jetzt tun? Die Antwort steht nicht verteilt über die gesamte Verordnung, sondern konzentriert in einem einzigen Dokument — dem Anhang I. Dort listet der Gesetzgeber die grundlegenden Cybersicherheitsanforderungen auf, die jedes Produkt mit digitalen Elementen erfüllen muss, bevor es in der EU auf den Markt kommt.

Dieser Leitfaden übersetzt Anhang I in Praxis-Sprache: Er gliedert die Anforderungen in ihre zwei Teile, erklärt zu jeder Pflicht, was operativ dahintersteht, und zeigt, wie Sie die Einhaltung nachweisen — von der technischen Dokumentation über die Konformitätsbewertung bis zur CE-Kennzeichnung. Am Ende ordnen wir ein, welche Pflichten Hersteller, Importeure und Händler jeweils treffen.

 

Anhang I: das Herzstück der CRA-Anforderungen

Der Cyber Resilience Act, im Deutschen auch Cyberresilienz-Verordnung genannt, gilt EU-weit unmittelbar — es gibt kein nationales Umsetzungsgesetz. Die Pflichten ergeben sich aus dem Verordnungstext selbst, und die inhaltlich zentralen stehen in Anhang I unter der Überschrift „Grundlegende Cybersicherheitsanforderungen”.

Anhang I ist in zwei Teile geteilt, und diese Trennung ist der Schlüssel zum Verständnis der Verordnung. Teil I beschreibt Eigenschaften, die das Produkt selbst mitbringen muss — sicheres Design und sichere Entwicklung. Teil II beschreibt Prozesse, die der Hersteller dauerhaft betreiben muss — den Umgang mit Schwachstellen, nachdem das Produkt auf dem Markt ist. Vereinfacht: Teil I ist eine Momentaufnahme des Produkts, Teil II eine laufende Verpflichtung über den gesamten Lebenszyklus.

Der CRA ist dabei nur eine von mehreren Regulierungen, die parallel auf Unternehmen einwirken. Wie er sich zu verwandten Rahmenwerken verhält, erläutert der Beitrag Cyber Resilience Act im Vergleich zu NIS2, DORA und ISO 27001 im Detail — für die konkreten Produktpflichten bleibt jedoch Anhang I der maßgebliche Text.

 

Annex I Teil I: sichere Produkteigenschaften (Security by Design)

Teil I verlangt, dass ein Produkt mit digitalen Elementen so konzipiert, entwickelt und hergestellt wird, dass es ein angemessenes Cybersicherheitsniveau bietet. Aus einer vorgeschalteten Risikobewertung leitet der Hersteller ab, welche der folgenden Anforderungen relevant sind. Die folgende Tabelle übersetzt sie in ihre praktische Bedeutung.

Anforderung (Annex I, Teil I)	Was das operativ bedeutet
Keine bekannten ausnutzbaren Schwachstellen	Bekannte Lücken sind vor Markteinführung geschlossen; ein Produkt mit offenem, bekanntem CVE darf nicht ausgeliefert werden.
Sichere Standardkonfiguration	Sicher voreingestellter Auslieferungszustand (Secure by Default) mit Reset-Möglichkeit — keine Standardpasswörter, keine unnötig offenen Dienste.
Behebbarkeit über Sicherheitsupdates	Schwachstellen lassen sich per Update beheben, wo sinnvoll automatisch; die Update-Fähigkeit ist technisch von Anfang an eingeplant.
Schutz vor unbefugtem Zugriff	Angemessene Zugangskontrolle über Authentifizierung und Identitäts- bzw. Zugriffsmanagement.
Vertraulichkeit der Daten	Schutz gespeicherter und übertragener Daten durch Verschlüsselung nach dem Stand der Technik (at rest und in transit).
Integrität	Schutz von Daten, Befehlen, Programmen und Konfiguration gegen unbefugte Manipulation.
Datenminimierung	Verarbeitet werden nur die für den vorgesehenen Zweck erforderlichen Daten.
Verfügbarkeit und DoS-Resilienz	Wesentliche Funktionen bleiben auch nach einem Vorfall verfügbar; Widerstand gegen Denial-of-Service-Angriffe.
Minimierte Angriffsfläche	Reduktion externer Schnittstellen und nicht benötigter Funktionen auf das Notwendige.
Wirkungsbegrenzung (Exploitation Mitigation)	Technische Mechanismen begrenzen den Schaden, falls es doch zu einem Vorfall kommt.
Sicherheitsrelevante Protokollierung	Aufzeichnung und Überwachung interner Aktivitäten wie Datenzugriffe und -änderungen.
Sichere Datenlöschung	Nutzer können alle Daten und Einstellungen sicher und dauerhaft entfernen.

Keine dieser Anforderungen gilt für jedes Produkt gleich. Der CRA folgt einem risikobasierten Ansatz: Welche Maßnahmen in welcher Tiefe nötig sind, ergibt sich aus der Cybersicherheits-Risikobewertung, die der Hersteller ohnehin durchführen und dokumentieren muss — ein einfacher Sensor braucht andere Vorkehrungen als eine industrielle Steuerung.

 

Annex I Teil II: Pflichten zum Schwachstellenmanagement

Teil II wird von vielen Herstellern unterschätzt, weil er nicht mit dem Verkauf endet, sondern dann erst richtig beginnt: Er verlangt einen dauerhaften Prozess zur Behandlung von Schwachstellen über den gesamten Support-Zeitraum. Acht Anforderungen bilden diesen Prozess:

• Software-Stückliste (SBOM): Der Hersteller dokumentiert die Komponenten seines Produkts in einer maschinenlesbaren Software Bill of Materials, die zumindest die wichtigsten Abhängigkeiten abdeckt (etablierte Formate: CycloneDX, SPDX). Ohne diese Transparenz lässt sich nicht sagen, welche Fremdkomponente von einer neuen Schwachstelle betroffen ist.
• Schwachstellen unverzüglich beheben: Bekannt gewordene Lücken werden ohne unnötige Verzögerung adressiert, insbesondere durch Sicherheitsupdates.
• Regelmäßige Tests und Prüfungen: Die Produktsicherheit wird wirksam und wiederkehrend getestet und überprüft, nicht nur einmalig vor dem Launch.
• Offenlegung behobener Schwachstellen: Ist ein Update verfügbar, werden Informationen zu den behobenen Schwachstellen geteilt und öffentlich bereitgestellt, samt Beschreibung.
• Policy zur koordinierten Offenlegung: Der Hersteller etabliert und lebt eine Coordinated-Vulnerability-Disclosure-Policy, die den geordneten Umgang mit gemeldeten Lücken regelt.
• Kontaktadresse für Meldungen: Es gibt eine benannte Anlaufstelle, an die Sicherheitsforscher und Dritte potenzielle Schwachstellen melden können.
• Sichere Update-Verteilung: Updates werden über sichere Mechanismen ausgeliefert, damit Lücken zeitnah und ohne neue Risiken geschlossen werden.
• Kostenlose Sicherheitsupdates: Verfügbare Sicherheitsupdates werden unverzüglich und — sofern nicht anders vereinbart — kostenlos bereitgestellt, getrennt von reinen Funktionsupdates.

Wer ein gelebtes Schwachstellenmanagement mit klaren Phasen bereits betreibt, hat den Kern von Teil II schon abgedeckt — der CRA gibt diesem Prozess lediglich einen verbindlichen gesetzlichen Rahmen und ergänzt die Melde- und Offenlegungspflichten.

 

 

Der Support-Zeitraum: wie lange Sie liefern müssen

Eine der praktisch folgenreichsten Vorgaben betrifft den Support-Zeitraum. Der Hersteller muss festlegen, wie lange er Sicherheitsupdates bereitstellt, und diesen Zeitraum an der realistisch erwarteten Nutzungsdauer des Produkts ausrichten. Als Faustregel gilt ein Zeitraum von mindestens fünf Jahren — kürzer nur, wenn das Produkt erkennbar für eine kürzere Nutzung bestimmt ist.

Das Ende des Support-Zeitraums muss bereits zum Kaufzeitpunkt klar angegeben werden, mindestens mit Monat und Jahr. Für die Produktplanung heißt das, Update-Fähigkeit und Wartungsbudget über Jahre einzukalkulieren — eine Verpflichtung, die weit über den Verkaufsmoment hinausreicht.

 

Wie weise ich die Konformität nach?

Die Anforderungen aus Anhang I zu erfüllen ist das eine — sie belegen zu können das andere. Der CRA verlangt einen durchgängigen Nachweis, der auf drei Säulen ruht.

1. Risikobewertung und technische Dokumentation. Grundlage ist eine dokumentierte Cybersicherheits-Risikobewertung, aus der hervorgeht, welche Anforderungen aus Anhang I für das Produkt gelten und wie sie umgesetzt wurden. Sie fließt in die technische Dokumentation ein, deren Mindestinhalt Anhang VII vorgibt: Produktbeschreibung, Design- und Entwicklungsinformationen, Bewertung der grundlegenden Anforderungen, SBOM und Angaben zum Support-Zeitraum. Diese Unterlagen sind mindestens zehn Jahre nach dem Inverkehrbringen — oder für die Dauer des Support-Zeitraums, je nachdem was länger ist — für die Marktüberwachungsbehörden bereitzuhalten.

2. Konformitätsbewertung. Anschließend wird die Übereinstimmung mit den Anforderungen in einem geregelten Verfahren bewertet. Welches Verfahren zulässig ist, hängt von der Risikoklasse des Produkts ab:

Produktkategorie	Zulässiges Bewertungsverfahren
Standardprodukte (nicht gesondert gelistet)	Interne Selbstbewertung (Modul A) durch den Hersteller ausreichend.
Wichtige Produkte, Klasse I (Anhang III)	Selbstbewertung nur bei vollständiger Anwendung harmonisierter Normen oder eines Cybersicherheitsschemas; sonst notifizierte Stelle.
Wichtige Produkte, Klasse II (Anhang III)	Verpflichtende Drittprüfung durch eine notifizierte Stelle.
Kritische Produkte (Anhang IV)	Gegebenenfalls europäisches Cybersicherheits-Zertifizierungsschema erforderlich.

3. EU-Konformitätserklärung und CE-Kennzeichnung. Ist die Bewertung positiv, stellt der Hersteller die EU-Konformitätserklärung aus (Muster in Anhang V) und bringt die CE-Kennzeichnung an. Erst sie signalisiert, dass das Produkt die Anforderungen des CRA und aller weiteren einschlägigen EU-Vorschriften erfüllt. Wie sich diese Nachweisschritte in einen Gesamtfahrplan einordnen, zeigt der Leitfaden zur CRA-Umsetzung in klaren Schritten.

 

Meldepflichten nach Art. 14 als laufende Betriebspflicht

Anhang I regelt Produkt und Prozesse — die Meldepflichten nach Art. 14 kommen als eigenständige Betriebspflicht hinzu und greifen früher als die Vollanwendung: bereits ab dem 11.09.2026. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gestaffelt nach Fristen an das CSIRT ihres Hauptniederlassungs-Mitgliedstaats und an die EU-Agentur ENISA melden.

Frist	Meldung bei aktiv ausgenutzter Schwachstelle
24 Stunden	Frühwarnung an CSIRT und ENISA.
72 Stunden	Vollständigere Meldung mit ersten Bewertungen und, soweit verfügbar, Korrekturmaßnahmen.
14 Tage	Abschlussbericht, nachdem eine Korrektur- oder Abhilfemaßnahme bereitsteht.

Für schwerwiegende Sicherheitsvorfälle gilt dieselbe 24- und 72-Stunden-Taktung, der Abschlussbericht ist hier binnen eines Monats fällig. Diese enge Taktung macht das Schwachstellenmanagement aus Teil II zum operativen Bereitschaftsprozess — 24 Stunden lassen keinen Raum für erst dann aufzubauende Strukturen.

 

Hersteller, Importeur, Händler: wer trägt welche Pflicht?

Die Hauptlast trägt der Hersteller, doch der CRA nimmt die gesamte Lieferkette in die Verantwortung. Wer als Importeur oder Händler ein Produkt unter eigenem Namen vermarktet oder wesentlich verändert, gilt rechtlich selbst als Hersteller und übernimmt dessen volle Pflichten aus Art. 13 und 14.

Rolle	Kernpflichten
Hersteller	Anhang I erfüllen, Risikobewertung und technische Dokumentation erstellen, Konformitätsbewertung durchführen, CE anbringen, Support-Zeitraum festlegen, Schwachstellen behandeln und melden.
Importeur	Nur konforme Produkte in Verkehr bringen; prüfen, dass Konformitätsbewertung, CE-Kennzeichnung, EU-Konformitätserklärung und Dokumentation vorliegen; Risiken an Hersteller und Behörden melden.
Händler	Mit gebotener Sorgfalt prüfen, dass CE-Kennzeichnung und erforderliche Unterlagen vorhanden sind; keine erkennbar nicht-konformen Produkte bereitstellen; bei Kenntnis von Schwachstellen informieren.

 

Von der Anforderung zum Prozess: Annex I über ein ISMS abdecken

Bei genauem Hinsehen sind viele Annex-I-Pflichten keine reinen Produktthemen, sondern Managementaufgaben: dokumentiertes Schwachstellenmanagement, gepflegte Komponenten- und Asset-Übersicht, definierte Verantwortlichkeiten, wiederkehrende Tests, nachvollziehbare Risikobewertungen und belastbare Nachweise. Genau das ist der Gegenstand eines Informationssicherheits-Managementsystems (ISMS).

Ein ISMS — etwa nach ISO 27001 — liefert die Struktur, um diese Pflichten nicht als lose Einzelmaßnahmen, sondern als ineinandergreifende, auditierbare Prozesse zu betreiben. Das Schwachstellenmanagement aus Teil II deckt sich weitgehend mit der ISO-Control zur Handhabung technischer Schwachstellen; Dokumentation und Risikobewertung sind ohnehin Kern jedes Managementsystems. Wer bereits ein ISMS betreibt, fängt für den CRA nicht bei null an, sondern erweitert seine vorhandenen Prozesse gezielt um die produktbezogenen Anforderungen.

Genau an dieser Schnittstelle setzt die CRA-Compliance-Beratung von TrustSpace an: Sie verbindet die Anforderungen aus Anhang I mit einem strukturierten Managementsystem, sodass Nachweisführung, Schwachstellenprozess und Meldepflichten aus einer Hand belegbar werden — statt in verstreuten Dokumenten und Ad-hoc-Reaktionen.

 

 

Fazit: Anhang I ist die To-do-Liste des CRA

Der Cyber Resilience Act wirkt umfangreich, doch die eigentlichen Pflichten lassen sich auf einen klaren Kern eindampfen. Anhang I Teil I definiert, wie das Produkt beschaffen sein muss: sicher konfiguriert, frei von bekannten Lücken, aktualisierbar, verschlüsselt, mit minimierter Angriffsfläche. Teil II definiert den Prozess dahinter: Schwachstellen dokumentieren, beheben, offenlegen und über den Support-Zeitraum begleiten, gestützt auf eine aktuelle SBOM.

Nachgewiesen wird all das über Risikobewertung, technische Dokumentation, Konformitätsbewertung und CE-Kennzeichnung, ergänzt um die laufenden Meldepflichten nach Art. 14. Wer diese Anforderungen nicht als Einzelaufgaben, sondern als zusammenhängenden, in ein Managementsystem eingebetteten Prozess versteht, verwandelt eine regulatorische Pflicht in einen belastbaren Nachweis von Produktsicherheit — und erspart sich die Hektik, kurz vor der Vollanwendung am 11.12.2027 Strukturen aufzubauen, die längst hätten laufen sollen.

 

Häufige Fragen (FAQ)

Was steht konkret in Annex I des Cyber Resilience Act?

Anhang I enthält die grundlegenden Cybersicherheitsanforderungen des CRA in zwei Teilen. Teil I beschreibt sicherheitsbezogene Produkteigenschaften wie sichere Standardkonfiguration, Verschlüsselung, minimierte Angriffsfläche und die Freiheit von bekannten ausnutzbaren Schwachstellen. Teil II beschreibt acht Prozessanforderungen zur Schwachstellenbehandlung, darunter die Erstellung einer SBOM, die unverzügliche Behebung von Schwachstellen und kostenlose Sicherheitsupdates.

Was ist eine SBOM und warum verlangt der CRA sie?

Eine SBOM (Software Bill of Materials) ist eine maschinenlesbare Stückliste aller Softwarekomponenten und Abhängigkeiten eines Produkts. Anhang I Teil II verlangt sie, damit Hersteller jederzeit nachvollziehen können, welche Komponente von einer neu bekannt gewordenen Schwachstelle betroffen ist. Gängige Formate sind CycloneDX und SPDX; die Liste muss über den gesamten Support-Zeitraum aktuell gehalten werden.

Wie weise ich die Einhaltung der CRA-Anforderungen nach?

Der Nachweis ruht auf einer dokumentierten Risikobewertung, der technischen Dokumentation nach Anhang VII, einer Konformitätsbewertung, der EU-Konformitätserklärung und der CE-Kennzeichnung. Je nach Risikoklasse des Produkts genügt eine Selbstbewertung oder es ist die Prüfung durch eine notifizierte Stelle erforderlich. Die Unterlagen sind mindestens zehn Jahre bereitzuhalten.

Gelten die CRA-Pflichten auch für Importeure und Händler?

Ja. Importeure dürfen nur konforme Produkte in Verkehr bringen und müssen prüfen, dass CE-Kennzeichnung, Konformitätserklärung und Dokumentation vorliegen. Händler prüfen mit gebotener Sorgfalt das Vorhandensein der CE-Kennzeichnung und der Unterlagen. Wer ein Produkt unter eigenem Namen vermarktet oder wesentlich verändert, gilt als Hersteller und trägt dessen volle Pflichten.

Ab wann gelten die Meldepflichten nach Art. 14?

Die Meldepflichten greifen ab dem 11.09.2026 und damit vor der Vollanwendung des CRA am 11.12.2027. Aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle sind binnen 24 Stunden als Frühwarnung, binnen 72 Stunden als Meldung und mit Abschlussbericht (14 Tage bei Schwachstellen, ein Monat bei Vorfällen) an das zuständige CSIRT und an ENISA zu melden.