Cyber Resilience Act: alle Werkzeuge und Artikel
Verordnung (EU) 2024/2847, Anhang I · ISO/IEC 27001:2022, Anhang A
Die grundlegenden Anforderungen des CRA, zugeordnet zu ISO 27001
Ein Hersteller mit zertifiziertem ISMS stellt zuerst eine Frage: Wie viel der technischen Dokumentation habe ich schon? Die Antwort hat drei Teile. Für die 14 Anforderungen in Teil I, die Eigenschaften des Produkts, betreibt das ISMS den Prozess, und das Produkt liefert den Beleg. Für 3 der 8 Anforderungen an die Schwachstellenbehandlung in Teil II ist der ISMS-Nachweis der Beleg. Und für 4 der 22 bringt nichts in Anhang A hervor, was die Verordnung verlangt.
Ein Managementsystem ist kein Produkt
ISO 27001 zertifiziert, wie eine Organisation Informationssicherheit steuert. Der Cyber Resilience Act regelt ein Produkt: was es tut, wie es gebaut wird und wie seine Schwachstellen während des Unterstützungszeitraums behandelt werden. Die beiden treffen sich in den Entwicklungsmaßnahmen von Anhang A, die bestimmen, wie das Produkt gebaut wird, und in den Maßnahmen zur Schwachstellenbehandlung, die bestimmen, was nach der Freigabe geschieht. Sie treffen sich nicht in den Eigenschaften des Produkts selbst: Kein ISMS-Nachweis zeigt, dass ein Produkt mit einer sicheren Standardkonfiguration ausgeliefert wird. Das zeigen die Dokumentation und die Tests des Produkts.
Drei Antworten, keine Punktzahl
- Der ISMS-Nachweis ist der Beleg
- 3
- Der Nachweis, den die Maßnahme erzeugt, ist das, was die technische Dokumentation zitiert: das Schwachstellenregister, das Behebungsprotokoll, die Testberichte.
- Das ISMS betreibt den Prozess, das Produkt liefert den Beleg
- 15
- Die Maßnahme legt die Anforderung, das Prinzip, die Programmierregel oder den Test fest; der Beleg, dass das Produkt sie erfüllt, ist der des Produkts, je Version.
- Nicht aus Anhang A
- 4
- Nichts in Anhang A veröffentlicht etwas, erstellt eine Stückliste eines Produkts oder verpflichtet zu kostenlosen Updates. Das wird für die Verordnung geschrieben.
Teil I: die Eigenschaften des Produkts
Nummer 1 ist die allgemeine Pflicht, auf Grundlage der Risikobewertung. Nummer 2 nennt dreizehn Eigenschaften, jede auf Grundlage dieser Bewertung anwendbar, sodass eine als nicht anwendbar beurteilte Eigenschaft mit Begründung in der Dokumentation ausgeschlossen wird. Für alle liefert das ISMS den Prozess: die Sicherheitsanforderungen, die das Produkt erfüllen muss, die Prinzipien, nach denen es entworfen ist, die Programmierregeln, die Tests vor der Freigabe. Der Beleg jeder Eigenschaft ist der des Produkts.
I.1 Angemessenes Cybersicherheitsniveau durch Konzeption
Das ISMS betreibt den Prozess, das Produkt liefert den Beleg
Der Prozess, in Anhang A
- Abschnitt 6.1.2
- A.5.8
- A.8.25
Was die Dokumentation noch braucht: Eine Cybersicherheits-Risikobewertung für das Produkt selbst (Artikel 13 Absätze 2 und 3), in der technischen Dokumentation nach Anhang VII Nummer 3. Das ISMS bewertet die Risiken der Organisation; die des Produkts sind ein eigener Nachweis.
Im Paket der technischen Dokumentation: Cybersecurity risk assessment
I.2.a Keine bekannten ausnutzbaren Schwachstellen bei der Freigabe
Das ISMS betreibt den Prozess, das Produkt liefert den Beleg
Der Prozess, in Anhang A
- A.8.8
- A.8.29
Was die Dokumentation noch braucht: Die Prüfung erfolgt je Freigabe und je ausgelieferter Komponente, und ihr Ergebnis bleibt bei dieser Version. Ein Scan der eigenen Systeme der Organisation ist ein anderer Nachweis.
Im Paket der technischen Dokumentation: Standards applied and test evidence
I.2.b Sichere Standardkonfiguration
Das ISMS betreibt den Prozess, das Produkt liefert den Beleg
Der Prozess, in Anhang A
- A.8.9
- A.8.26
Was die Dokumentation noch braucht: Die sichere Standardkonfiguration und das Zurücksetzen darauf sind Eigenschaften des Produkts, belegt durch seine Dokumentation und Tests, nicht durch eine Konfigurationsvorgabe für die Systeme der Organisation.
Im Paket der technischen Dokumentation: Standards applied and test evidence
I.2.c Sicherheitsupdates
Das ISMS betreibt den Prozess, das Produkt liefert den Beleg
Der Prozess, in Anhang A
- A.8.8
- A.8.32
Was die Dokumentation noch braucht: Ein Update-Mechanismus im Produkt, standardmäßig automatisch mit einer Abwahlmöglichkeit für den Nutzer, und eine Benachrichtigung der Nutzer, wenn ein Update verfügbar ist: eine Funktion, kein Prozess.
Im Paket der technischen Dokumentation: Standards applied and test evidence
I.2.d Schutz vor unbefugtem Zugriff
Das ISMS betreibt den Prozess, das Produkt liefert den Beleg
Der Prozess, in Anhang A
- A.8.26
- A.8.5
- A.5.15
- A.5.16
- A.5.17
Im Paket der technischen Dokumentation: Standards applied and test evidence
I.2.e Vertraulichkeit der Daten
Das ISMS betreibt den Prozess, das Produkt liefert den Beleg
Der Prozess, in Anhang A
- A.8.26
- A.8.24
Im Paket der technischen Dokumentation: Standards applied and test evidence
I.2.f Integrität von Daten, Befehlen und Konfiguration
Das ISMS betreibt den Prozess, das Produkt liefert den Beleg
Der Prozess, in Anhang A
- A.8.26
- A.8.24
- A.8.9
Im Paket der technischen Dokumentation: Standards applied and test evidence
I.2.g Datenminimierung
Das ISMS betreibt den Prozess, das Produkt liefert den Beleg
Der Prozess, in Anhang A
- A.8.26
- A.5.34
Im Paket der technischen Dokumentation: Standards applied and test evidence
I.2.h Verfügbarkeit wesentlicher und grundlegender Funktionen
Das ISMS betreibt den Prozess, das Produkt liefert den Beleg
Der Prozess, in Anhang A
- A.8.26
- A.8.6
- A.8.14
Im Paket der technischen Dokumentation: Standards applied and test evidence
I.2.i Keine negativen Auswirkungen auf andere Geräte und Netze
Das ISMS betreibt den Prozess, das Produkt liefert den Beleg
Der Prozess, in Anhang A
- A.8.27
- A.8.20
Im Paket der technischen Dokumentation: Standards applied and test evidence
I.2.j Begrenzte Angriffsflächen
Das ISMS betreibt den Prozess, das Produkt liefert den Beleg
Der Prozess, in Anhang A
- A.8.27
- A.8.9
Im Paket der technischen Dokumentation: Standards applied and test evidence
I.2.k Verringerte Auswirkungen von Sicherheitsvorfällen
Das ISMS betreibt den Prozess, das Produkt liefert den Beleg
Der Prozess, in Anhang A
- A.8.27
- A.8.28
Im Paket der technischen Dokumentation: Standards applied and test evidence
I.2.l Sicherheitsprotokollierung und Überwachung
Das ISMS betreibt den Prozess, das Produkt liefert den Beleg
Der Prozess, in Anhang A
- A.8.26
- A.8.15
- A.8.16
Im Paket der technischen Dokumentation: Standards applied and test evidence
I.2.m Sicheres und einfaches Löschen von Daten und Einstellungen
Das ISMS betreibt den Prozess, das Produkt liefert den Beleg
Der Prozess, in Anhang A
- A.8.26
- A.8.10
Im Paket der technischen Dokumentation: Standards applied and test evidence
Teil II: Schwachstellenbehandlung im Unterstützungszeitraum
Acht Anforderungen an den Hersteller, von denen keine ausgeschlossen werden darf. Hier ist ein ISMS der Verordnung am nächsten, und hier liegen die konkreten Lücken: die Stückliste, die öffentliche Bekanntgabe, die Richtlinie, die Kontaktadresse und die kostenlosen Updates.
II.1 Schwachstellen und Komponenten ermitteln und dokumentieren, mit SBOM
Der ISMS-Nachweis ist der Beleg
Der Prozess, in Anhang A
- A.8.8
- A.5.9
Was die Dokumentation noch braucht: Eine Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten des Produkts erfasst. Keine Maßnahme in Anhang A verlangt eine Stückliste eines Produkts.
Im Paket der technischen Dokumentation: Software bill of materials procedure
II.2 Schwachstellen unverzüglich beheben
Der ISMS-Nachweis ist der Beleg
Der Prozess, in Anhang A
- A.8.8
- A.8.32
Was die Dokumentation noch braucht: Sicherheitsupdates, die, soweit technisch machbar, getrennt von Funktionsupdates bereitgestellt werden: eine Freigabepraxis, die Anhang A nicht nennt.
Im Paket der technischen Dokumentation: Security updates and support statement
II.3 Regelmäßige Tests und Überprüfungen
Der ISMS-Nachweis ist der Beleg
Der Prozess, in Anhang A
- A.8.29
- A.8.8
- A.5.35
Im Paket der technischen Dokumentation: Vulnerability handling process
II.4 Behobene Schwachstellen bekannt geben
Nicht aus Anhang A
Was die Dokumentation noch braucht: Die öffentliche Bekanntgabe jeder behobenen Schwachstelle, sobald das Update verfügbar ist: Beschreibung, betroffene Produkte, Auswirkungen, Schweregrad und wie Nutzer Abhilfe schaffen. Anhang A enthält keine Maßnahme, die etwas veröffentlicht.
Im Paket der technischen Dokumentation: Vulnerability handling process
II.5 Richtlinie zur koordinierten Offenlegung von Schwachstellen
Nicht aus Anhang A
Was die Dokumentation noch braucht: Eine Richtlinie zur koordinierten Offenlegung von Schwachstellen, eingeführt und durchgesetzt. Anhang A verlangt einen Vorfallprozess, keine veröffentlichte Richtlinie für externe Meldende.
Im Paket der technischen Dokumentation: Coordinated vulnerability disclosure policy
II.6 Eine Kontaktstelle zur Meldung von Schwachstellen
Nicht aus Anhang A
Was die Dokumentation noch braucht: Eine veröffentlichte Kontaktadresse für Meldungen von Schwachstellen im Produkt und in seinen Drittkomponenten, und ein Weg, sie entgegenzunehmen.
Im Paket der technischen Dokumentation: Coordinated vulnerability disclosure policy
II.7 Sichere und rechtzeitige Verteilung von Updates
Das ISMS betreibt den Prozess, das Produkt liefert den Beleg
Der Prozess, in Anhang A
- A.8.24
- A.8.32
Was die Dokumentation noch braucht: Der Verteilmechanismus ist der des Produkts: Updates signiert, sicher und rechtzeitig ausgeliefert, wo zutreffend automatisch.
Im Paket der technischen Dokumentation: Security updates and support statement
II.8 Kostenlose Sicherheitspatches mit Hinweisen
Nicht aus Anhang A
Was die Dokumentation noch braucht: Sicherheitsupdates kostenlos während des Unterstützungszeitraums, unverzüglich, mit einem Hinweis an die Nutzer. Eine geschäftliche Zusage und eine Veröffentlichung, von denen Anhang A keine nennt.
Im Paket der technischen Dokumentation: Security updates and support statement
4 Dinge, die Anhang A nicht hervorbringt
Ausgeschrieben, damit ein zertifizierter Hersteller weiß, was er schreiben muss, nicht nur, was er zitieren kann. Jede der 4 landet in einem von 3 Dokumenten des Pakets der technischen Dokumentation, und diese Dokumente werden aus dem Produktdatensatz entworfen, nicht aus dem ISMS.
II.4 Behobene Schwachstellen bekannt geben
Die öffentliche Bekanntgabe jeder behobenen Schwachstelle, sobald das Update verfügbar ist: Beschreibung, betroffene Produkte, Auswirkungen, Schweregrad und wie Nutzer Abhilfe schaffen. Anhang A enthält keine Maßnahme, die etwas veröffentlicht.
II.5 Richtlinie zur koordinierten Offenlegung von Schwachstellen
Eine Richtlinie zur koordinierten Offenlegung von Schwachstellen, eingeführt und durchgesetzt. Anhang A verlangt einen Vorfallprozess, keine veröffentlichte Richtlinie für externe Meldende.
II.6 Eine Kontaktstelle zur Meldung von Schwachstellen
Eine veröffentlichte Kontaktadresse für Meldungen von Schwachstellen im Produkt und in seinen Drittkomponenten, und ein Weg, sie entgegenzunehmen.
II.8 Kostenlose Sicherheitspatches mit Hinweisen
Sicherheitsupdates kostenlos während des Unterstützungszeitraums, unverzüglich, mit einem Hinweis an die Nutzer. Eine geschäftliche Zusage und eine Veröffentlichung, von denen Anhang A keine nennt.
Was diese Seite nicht ist
Kein Abdeckungsgrad. Hier wird kein Prozentsatz berechnet, und es sollte keiner berechnet werden. Eine Anforderung, deren Prozess im ISMS liegt und deren Beleg noch nicht in der Dokumentation ist, ist kein anteilig abgedeckter Punkt; sie ist ein Dokument, das zu schreiben ist.
Keine Konformitätsvermutung. Nur eine im Amtsblatt zitierte harmonisierte Norm gibt eine (Artikel 27), und ISO 27001 ist diese Norm nicht und wird es nicht sein. Wo die harmonisierten Normen stehen, und was ihr Fehlen für jede Stufe bedeutet
Nicht die NIS2-Zuordnung. NIS2 regelt die Organisation, und ihre Maßnahmen sind aus ISO 27001 geschrieben, weshalb jene Zuordnung näher liegt. Die NIS2-Durchführungsverordnung, zugeordnet zu ISO 27001
Als Nächstes lesen
CRA Anhang I: die 22 grundlegenden Anforderungen als Checkliste
Anhang I des Cyber Resilience Act ist das, was Ihr Produkt ab dem 11. Dezember 2027 erfüllen und die technische Dokumentation zeigen muss. Teil I sind 14 Produktanforderungen, 13 davon „soweit anwendbar“ auf Grundlage Ihrer Risikobewertung; Teil II sind 8 Anforderungen an die Schwachstellenbehandlung, die immer gelten. Hier stehen sie als eine Tabelle, mit dem, was jede verlangt, und ob Sie sie ausschließen dürfen.
Was in die technische Dokumentation nach dem CRA gehört: Anhang VII, Punkt für Punkt
Ab dem 11. Dezember 2027 braucht jedes Produkt mit digitalen Elementen, das auf dem EU-Markt in Verkehr gebracht wird, vor dem Inverkehrbringen eine technische Dokumentation, aufzubewahren für zehn Jahre oder den Unterstützungszeitraum, je nachdem, was länger ist. Anhang VII sagt in acht Punkten, was sie enthält. Hier stehen sie, was jeder Punkt tatsächlich verlangt, die vier Dokumente, die Teil II des Anhangs I voraussetzt, und wie lange Sie sie aufbewahren.
Harmonisierte Normen für den CRA: Was der Normungsauftrag M/606 verlangt, bis wann, und was ein Hersteller heute hat
Artikel 27 gibt Produkten, die harmonisierten Normen mit Fundstelle im Amtsblatt folgen, eine Konformitätsvermutung. Am 3. Februar 2025 bat die Kommission CEN, CENELEC und ETSI um 41 davon, mit Fristen vom 30. August 2026 bis zum 30. Oktober 2027; die drei nahmen am 3. April 2025 an. Am 12. September 2026 hat das Verzeichnis harmonisierter Normen der Kommission noch keinen Eintrag für die Verordnung, was für ein Produkt der Klasse I bedeutet: kein Weg der Selbstbewertung nach Artikel 32(2). Was beantragt wurde, die Daten, und wogegen bis dahin zu bauen ist.
Selbstbewertung nach dem CRA: Was Modul A tatsächlich verlangt, aus Anhang VIII und den FAQ der Kommission
Die meisten Softwareprodukte werden nie eine notifizierte Stelle sehen. Sie nutzen Modul A, das Verfahren der internen Kontrolle aus Anhang VIII, und „Selbstbewertung“ ist das Wort, das alle dafür verwenden, ohne zu sagen, was es enthält. Anhang VIII Teil I sind fünf Punkte; die FAQ der Kommission ergänzen die Liste der Tätigkeiten, die Tatsache, dass keine Prüfmethodik vorgeschrieben ist, wo ein Softwareprodukt seine CE-Kennzeichnung trägt, die zwei Formen der Konformitätserklärung und den Zeitplan der harmonisierten Normen, der entscheidet, wann Selbstbewertung nicht mehr „direkt gegen Anhang I“ heißt.
Die Cybersicherheitsrisikobewertung nach dem CRA: Was Artikel 13 tatsächlich verlangt, und das eine Ergebnis, das sie liefern muss
Artikel 13 Absätze 2 bis 4 des Cyber Resilience Act machen die Risikobewertung zu dem Dokument, an dem jede andere CRA-Pflicht hängt. Sie muss Risiken aus Zweckbestimmung, vorhersehbarer Verwendung und Nutzungsbedingungen über die erwartete Nutzungsdauer analysieren; angeben, ob und wie jede Anforderung aus Teil I Nummer 2 gilt; sagen, wie Teil I Nummer 1 und Teil II angewandt werden; dokumentiert, über den Unterstützungszeitraum aktuell gehalten und in die technische Dokumentation aufgenommen sein, mit klarer Begründung für jede weggelassene Anforderung. Die vier Absätze, und eine einseitige Struktur, die sie erfüllt.
Verlangt der CRA eine SBOM? Ja, und hier steht genau, was er sagt
Anhang I Teil II Nummer 1 des Cyber Resilience Act verlangt eine Software-Stückliste in einem gebräuchlichen, maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten abdeckt. Sie gehört in die technische Dokumentation, wird nicht veröffentlicht, und eine Marktüberwachungsbehörde kann sie auf begründetes Verlangen anfordern. Die drei Sätze, die das entscheiden, und was sie offenlassen.
Die Richtlinie zur koordinierten Offenlegung von Schwachstellen, die der CRA verlangt: drei Vorschriften, und eine einseitige Richtlinie, die sie erfüllt
Anhang I Teil II Nummer 5 des Cyber Resilience Act verlangt von jedem Hersteller im Anwendungsbereich, eine Richtlinie zur koordinierten Offenlegung von Schwachstellen einzuführen und durchzusetzen. Artikel 13 Absatz 17 verlangt eine zentrale Kontaktstelle für Meldungen, die leicht zu finden ist und nicht auf automatisierte Werkzeuge beschränkt; Anhang II Nummer 2 verlangt die Kontaktstelle und den Fundort der Richtlinie in den Nutzerinformationen; Anhang VII Nummer 2 Buchstabe b nimmt beides in die technische Dokumentation auf. Was jede Vorschrift verlangt, was eine Richtlinie sagen muss und was sie nicht versprechen darf.
Der Cyber Resilience Act für einen kleinen Softwarehersteller, in zwölf Schritten
Alles, was ein Zehn-Personen-Unternehmen, das installierte Software oder ein Gerät ausliefert, nach dem CRA tun muss, in der Reihenfolge, in der es zu tun ist: die Feststellung des Anwendungsbereichs, die Stufe, das CSIRT und die Durchsetzungsbehörde, das Meldeverfahren, das seit dem 11. September 2026 gilt, dann die technische Dokumentation, die 22 Anforderungen, die SBOM, der Unterstützungszeitraum, die CE-Kennzeichnung und die Erklärung, fällig bis zum 11. Dezember 2027. Jeder Schritt mit seinem Artikel und dem Text, der ihn erklärt.
Die 4 Lücken sind 3 der 11 Dokumente der Dokumentation
StandardOS führt die ISMS-Nachweise, die die 23 zugeordneten Maßnahmen erzeugen, und das Paket der technischen Dokumentation entwirft die 11 Dokumente nach Anhang VII aus dem Produktdatensatz, darunter die Offenlegungsrichtlinie, die Update-Erklärung und das SBOM-Verfahren. Die Zuordnung auf dieser Seite ist die Verbindung zwischen beiden.
Anhang I gilt ab dem 11. Dezember 2027. Die Maßnahmen sind die 93 aus Anhang A der ISO/IEC 27001:2022, per Referenz zitiert; die Zuordnung ist unsere und nicht die der ISO oder der Kommission. Dies ist keine Rechtsberatung, und die Verordnung ist der Text, den es zu lesen gilt: Verordnung (EU) 2024/2847.