CRA-Checkliste: Was der Cyber Resilience Act verlangt – und wie Sie es belegen

• 10. Dezember 2024 – Inkrafttreten.
• 11. Juni 2026 – Regeln zur Notifizierung von Konformitätsbewertungsstellen (Kapitel IV, Art. 35–51) gelten.
• 11. September 2026 – Meldepflichten nach Artikel 14 gelten, auch für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden (Art. 69 Abs. 3).
• 11. Dezember 2027 – alle übrigen Pflichten gelten.

Die Meldepflicht läuft also bereits. Für alles andere bleiben gut 14 Monate.

Diese Checkliste fasst den Verordnungstext zusammen. Sie ist keine Rechtsberatung. Wer sie abarbeitet, hat damit allein noch nicht nachgewiesen, dass ein Produkt die Anforderungen des CRA erfüllt.

Ein Durchgang pro Produkt und pro Rolle. Jeden Punkt als erledigt, offen oder nicht anwendbar markieren. Bei „nicht anwendbar“ den Grund notieren – Art. 13 Abs. 4 verlangt dafür eine klare Begründung in der technischen Dokumentation.

• Produkt mit digitalen Elementen und Datenverbindung (Art. 2 Abs. 1). Nachweis: kurze Notiz zu Zweckbestimmung und allen Verbindungen zu Geräten oder Netzen.
• Ausnahmen geprüft: Medizinprodukte, In-vitro-Diagnostika, Fahrzeug-Typgenehmigung, Zivilluftfahrt, Schiffsausrüstung (Art. 2 Abs. 2–4). Nachweis: Die Notiz nennt das einschlägige Regelwerk oder „keins“.
• Datenfernverarbeitung einbezogen, sofern das Produkt ohne sie eine Funktion nicht erfüllen kann (Art. 3 Nr. 2). Nachweis: Architekturskizze mit den betroffenen Backend-Diensten.
• Rolle je Produkt festgelegt: Hersteller, Einführer (Importeur) oder Händler (Art. 13, 19, 20). Nachweis: Rolle am Produkt hinterlegt.
• Herstellerstatus geprüft bei Eigenmarke oder wesentlicher Änderung (Art. 21, 22). Nachweis: datierte Entscheidungsnotiz.
• Einführer: Konformitätsbewertung, technische Dokumentation, CE-Kennzeichnung, EU-Konformitätserklärung und Nutzerinformationen vor dem Inverkehrbringen geprüft (Art. 19 Abs. 2). Nachweis: Prüfprotokoll je Lieferant und Produkt.
• Händler: CE-Kennzeichnung und erforderliche Unterlagen geprüft (Art. 20 Abs. 2). Nachweis: Wareneingangsprüfung.

In Attesly ist jedes Produkt ein eigener Datensatz. Einführer und Händler dokumentieren darin die Nachweise für ihre eigene Rolle.

• Kernfunktion mit Anhang III (wichtige Produkte, Klasse I oder II) und Anhang IV (kritische Produkte) abgeglichen. Nachweis: Klassifizierungsvermerk mit Kategorie oder „Standardprodukt“.
• Technische Beschreibungen der Durchführungsverordnung (EU) 2025/2392 herangezogen. Maßgeblich ist die Kernfunktion, nicht jede eingebaute Komponente (Art. 7 Abs. 1). Nachweis: Vermerk zitiert die verwendete Beschreibung.
• Konformitätsbewertungsverfahren gewählt nach Art. 32 (siehe Phase 6). Nachweis: Modul mit Begründung.
• Klasse nach jeder wesentlichen Änderung neu geprüft. Nachweis: Eintrag im Änderungsprotokoll.

Attesly schlägt am Produkt eine Klasse und ein Bewertungsverfahren vor. Sie prüfen den Vorschlag, ändern ihn bei Bedarf und halten Ihre Begründung dazu fest.

• Cybersicherheitsrisikobewertung dokumentiert und während des Unterstützungszeitraums aktualisiert (Art. 13 Abs. 2–3). Nachweis: datierte, versionierte Bewertung.
• Keine bekannten ausnutzbaren Schwachstellen bei Auslieferung (Nr. 2 Buchst. a). Nachweis: Schwachstellenabgleich der Release-SBOM mit Bewertungsnotizen.
• Sichere Standardkonfiguration mit Rücksetzung in den Ausgangszustand (b). Nachweis: Standardkonfiguration und Härtungstest.
• Sicherheitsupdates möglich, wo sinnvoll automatisch voreingestellt, mit Abschalt- und Aufschiebeoption (c). Nachweis: Beschreibung und Test des Update-Mechanismus.
• Schutz vor unbefugtem Zugriff und Meldung möglicher unbefugter Zugriffe (d). Nachweis: Authentifizierungskonzept, Testergebnisse.
• Vertraulichkeit, z. B. Verschlüsselung gespeicherter und übertragener Daten (e). Nachweis: Krypto-Übersicht.
• Integrität von Daten, Befehlen, Programmen und Konfiguration (f). Nachweis: Beschreibung von Signatur- oder Integritätsprüfung.
• Datenminimierung (g). Nachweis: Datenübersicht, abgeglichen mit der Zweckbestimmung.
• Verfügbarkeit und Widerstandsfähigkeit, auch gegen Denial-of-Service, und geringe Auswirkung auf andere Netze (h–i). Nachweis: Ergebnisse der Belastungstests.
• Kleine Angriffsfläche und Schutz gegen Ausnutzung (j–k). Nachweis: Liste der externen Schnittstellen und aktiven Schutzmechanismen.
• Protokollierung sicherheitsrelevanter Vorgänge, mit Abschaltmöglichkeit für Nutzer (l). Nachweis: Liste der protokollierten Ereignisse.
• Sicheres, dauerhaftes Löschen aller Daten und Einstellungen (m). Nachweis: Löschverfahren und Test.

• Software-Stückliste (SBOM) in einem gängigen, maschinenlesbaren Format, mindestens mit den direkten Abhängigkeiten (Nr. 1). Nachweis: eine SBOM je veröffentlichter Version.
• Schwachstellen unverzüglich behoben; Sicherheitsupdates nach Möglichkeit getrennt von Funktionsupdates (2). Nachweis: Tickets mit Zeitstempeln.
• Regelmäßige Sicherheitstests und -prüfungen (3). Nachweis: Testberichte.
• Behobene Schwachstellen veröffentlicht, sobald das Update verfügbar ist (4). Nachweis: Sicherheitshinweise (Advisories).
• Strategie zur koordinierten Offenlegung von Schwachstellen eingeführt und umgesetzt (5). Nachweis: veröffentlichte Richtlinie.
• Kontaktadresse für Schwachstellenmeldungen (6) und zentrale Anlaufstelle (Art. 13 Abs. 17). Nachweis: Kontaktseite oder security.txt.
• Sichere Verteilung und kostenlose Sicherheitsupdates mit Hinweisen für Nutzer (7–8). Nachweis: Beschreibung von Verteilung und Signatur, Vorlage für Hinweise.
• Sorgfalt bei Fremd- und Open-Source-Komponenten; Schwachstellen an deren Hersteller oder Maintainer gemeldet (Art. 13 Abs. 5–6). Nachweis: Prüfnotizen und Meldungen.

Attesly übernimmt SBOMs als CycloneDX oder SPDX im JSON-Format (z. B. aus syft, cdxgen oder Trivy) oder wandelt Excel/CSV in CycloneDX um – per Upload, Einfügen oder API/CI. Komponenten mit Package-URL (purl) werden beim Import, bei jedem erneuten Scan sowie täglich gegen OSV.dev geprüft. Komponenten, die nur einen CPE-Namen tragen, werden gegen die NVD geprüft, wo diese Prüfung aktiv ist; alles Übrige wird dokumentiert, aber nicht geprüft. Mehr dazu: CRA-Nachweise je Produkt pflegen.

• Allgemeine Beschreibung: Zweckbestimmung, für die Anforderungen relevante Softwareversionen, bei Hardware Fotos, Nutzerinformationen (Nr. 1).
• Konzeption, Entwicklung und Schwachstellenbehandlung: Systemarchitektur, SBOM, Offenlegungsstrategie, Nachweis der Kontaktadresse, Update-Verteilung (Nr. 2).
• Risikobewertung inkl. Anwendbarkeit von Anhang I Teil I (Nr. 3).
• Begründung des Unterstützungszeitraums (Nr. 4).
• Angewandte Normen: harmonisierte Normen, gemeinsame Spezifikationen oder Zertifizierungsschemata – oder Beschreibung der stattdessen gewählten Lösungen (Nr. 5).
• Prüfberichte zu Anhang I Teil I und II (Nr. 6).
• Kopie der EU-Konformitätserklärung (Nr. 7).
• Nutzerinformationen nach Anhang II: Herstellerkontakt, zentrale Anlaufstelle, Produktkennung, Ende des Unterstützungszeitraums, Anleitungen zu sicherer Nutzung, Updates und Außerbetriebnahme.

Nachweis für alle Punkte: eine versionierte technische Dokumentation je Produkt. Attesly zeigt mit einem Lückenwert von 0 bis 100, was noch fehlt, führt sechs CRA-Dokumentarten mit Revisionen und exportiert als CSV, JSON, Markdown oder Druck-PDF. Mehr dazu: Technische Dokumentation nach Anhang VII.

• Standardprodukte: interne Kontrolle, Modul A (Art. 32 Abs. 1).
• Wichtige Produkte, Klasse I: Modul A nur bei vollständiger Anwendung harmonisierter Normen, gemeinsamer Spezifikationen oder eines Zertifizierungsschemas; sonst Modul B+C oder H (Art. 32 Abs. 2).
• Wichtige Produkte, Klasse II: Modul B+C, H oder ein europäisches Cybersicherheitszertifizierungsschema mindestens für die Stufe „mittel“ (Art. 32 Abs. 3; im englischen Text „substantial“).
• Kritische Produkte: europäisches Cybersicherheitszertifikat, wo ein delegierter Rechtsakt es verlangt, sonst wie Klasse II (Art. 32 Abs. 4).
• Benannte Stelle früh angefragt, falls nötig. Nachweis: Angebot oder Vertrag.
• EU-Konformitätserklärung ausgestellt (Art. 28) und CE-Kennzeichnung angebracht (Art. 30); vollständige oder vereinfachte Erklärung mit Internetadresse liegt dem Produkt bei (Art. 13 Abs. 20).
• Produktkennung und Herstellerkontakt auf Produkt, Verpackung oder Begleitdokument (Art. 13 Abs. 15–16).

• „Kenntnis“ festgelegt: Wer entscheidet, dass eine Schwachstelle aktiv ausgenutzt wird oder ein Sicherheitsvorfall schwerwiegend ist (Begriffe: Art. 3, Art. 14 Abs. 5)? Nachweis: schriftlicher Ablauf mit Namen und Vertretung.
• Zugang zur einheitlichen Meldeplattform der ENISA eingerichtet und zuständiges CSIRT bestimmt (Art. 14 Abs. 7). Nachweis: Zugangsdaten, Ersatzperson.
• Frühwarnung binnen 24 Stunden nach Kenntnis (Art. 14 Abs. 2 Buchst. a, Abs. 4 Buchst. a).
• Meldung binnen 72 Stunden (Art. 14 Abs. 2 Buchst. b, Abs. 4 Buchst. b).
• Abschlussbericht: bei Schwachstellen spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme verfügbar ist; bei schwerwiegenden Sicherheitsvorfällen innerhalb eines Monats nach der 72-Stunden-Meldung (Art. 14 Abs. 2 Buchst. c, Abs. 4 Buchst. c).
• Betroffene Nutzer informiert, inkl. möglicher Gegenmaßnahmen (Art. 14 Abs. 8). Nachweis: Nutzerhinweis.

Attesly berechnet diese Fristen aus den Daten eines Falls und bereitet eine Zusammenfassung für die Meldeplattform vor. Mehr dazu: Meldung nach Artikel 14 vorbereiten.

• Unterstützungszeitraum festgelegt: mindestens fünf Jahre, außer das Produkt wird voraussichtlich kürzer genutzt (Art. 13 Abs. 8). Nachweis: Begründung in der technischen Dokumentation.
• Ende des Unterstützungszeitraums (Monat und Jahr) beim Kauf angegeben (Art. 13 Abs. 19).
• Jedes Sicherheitsupdate verfügbar gehalten: mindestens 10 Jahre oder für den Rest des Unterstützungszeitraums, je nachdem, was länger ist (Art. 13 Abs. 9).
• Technische Dokumentation und Konformitätserklärung aufbewahrt: mindestens 10 Jahre oder für den Unterstützungszeitraum, je nachdem, was länger ist (Art. 13 Abs. 13).
• SBOM, Schwachstellen und Risikobewertung bei jedem Release neu geprüft (Art. 13 Abs. 3 und 7). Nachweis: datierte Revisionen.
• Korrekturmaßnahmen, Rücknahme oder Rückruf, wenn ein Produkt Anhang I nicht erfüllt (Art. 13 Abs. 21).
• Behörden und Nutzer informiert, bevor Sie den Geschäftsbetrieb einstellen (Art. 13 Abs. 23).

Verstöße gegen Anhang I sowie gegen Art. 13 und 14 können mit Geldbußen von bis zu 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist (Art. 64 Abs. 2). Fehlende Nachweise fallen meist erst auf, wenn eine Behörde nachfragt – der ungünstigste Zeitpunkt, um sie zusammenzustellen.

Alle Nachweise an einem Ort. Attesly führt je Produkt einen Datensatz mit SBOM, Schwachstellenabgleich, Fristen nach Artikel 14 und technischer Dokumentation. Worauf es bei der Auswahl ankommt: CRA-Software: Was sie leisten muss.