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.
- Für wen es gilt
- Ein Hersteller mit zertifiziertem Informationssicherheits-Managementsystem, der fragt, wie viel der technischen Dokumentation er bereits hat.
- Die Termine
- Bevor Sie die Akte beginnen, denn die Antwort entscheidet, was Sie schreiben und was Sie zitieren.
- Das eine, was zu tun ist
- Lesen Sie die Zuordnung Zeile für Zeile: was Ihr System bereits belegt, was es halb abdeckt und was keine Sicherheitsmaßnahme hervorbringt.
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
| Grundlage | Anforderungen | Was das heißt |
|---|---|---|
| Der ISMS-Nachweis ist der Beleg 3 | 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 | 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 | 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 1: die 22 grundlegenden Anforderungen als Checkliste, 14 Produktanforderungen und 8 zur Schwachstellenbehandlung
Was Ihr Produkt ab dem 11. Dezember 2027 erfüllen und die technische Dokumentation zeigen muss: Teil I, 14 Produktanforderungen, 13 davon „soweit anwendbar“ auf Grundlage Ihrer Risikobewertung; Teil II, 8 Anforderungen an die Schwachstellenbehandlung, die immer gelten.
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.
Harmonisierte Normen für den CRA: noch keine im Amtsblatt, 41 beauftragt, die ersten zwei waren zum 30. August 2026 fällig
Der Normungsauftrag M/606 vom 3. Februar 2025 verlangt von CEN, CENELEC und ETSI 41 Normen: zwei horizontale bis zum 30.
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.
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.
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.
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.
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.
Als Nächstes: die technische Dokumentation, elf Dokumente, in Ihre Organisation entworfen.
Dokumente per E-Mail; fügen Sie sie jederzeit einem kostenlosen Arbeitsbereich hinzu.
Oder kostenlos starten und ein Produkt registrieren
Oder mit Ihnen gemeinsam erledigt: CRA-Bereitschaft, 1.500 €, 10 Arbeitstage
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.