Issue Nº 03supply-chainiso-27001audits14 Min. Lesezeit
Welches ENISA-KMU-Level ist die eigentliche CRA-Untergrenze?
ENISAs KMU-Reifegradmodell vom Juli 2026 sagt an keiner Stelle, welches seiner fünf Level die Cyberresilienz-Verordnung verlangt, und sein CRA-Mapping besteht aus fünf Zeilen auf Domänenebene; gelesen gegen die Verpflichtungsverben und Geltungsdaten der Verordnung selbst ist die vertretbare Untergrenze ein Band: Level-4-Praxis in den drei gemappten Domänen, während nichts von dem, was Level 5 auszeichnet, auf eine CRA-Bestimmung zurückgeht.
++++
field notesNº03
fig — Welches ENISA-KMU-Level ist die eigentliche CRA-Untergrenze?
ENISAs KMU-Reifegradmodell vom Juli 2026 sagt an keiner Stelle, welches seiner fünf Level die Cyberresilienz-Verordnung verlangt, und sein CRA-Mapping besteht aus fünf Zeilen auf Domänenebene; gelesen gegen die Verpflichtungsverben und Geltungsdaten der Verordnung selbst ist die vertretbare Untergrenze ein Band: Level-4-Praxis in den drei gemappten Domänen, während nichts von dem, was Level 5 auszeichnet, auf eine CRA-Bestimmung zurückgeht.
Ein Teil der Cyberresilienz-Verordnung gilt bereits. Artikel 71(2) der Verordnung (EU) 2024/2847 staffelt die Daten: ein Kapitel gilt seit dem 11. Juni 2026, die Meldepflichten des Artikels 14 ab dem 11. September 2026 (rund sieben Wochen nach diesem Beitrag), der Rest ab dem 11. Dezember 2027. Im Juli 2026 hat ENISA ein Reifegradmodell veröffentlicht, das KMU-Herstellern bei der Vorbereitung helfen soll. Das Modell hat fünf Level. Die Verordnung sagt nirgends, welches davon sie will; das Wort „maturity“ kommt im Verordnungstext an keiner Stelle vor. Ich habe die beiden Dokumente gegeneinander gelesen, um herauszufinden, wo die Untergrenze liegt. Die Antwort ist ein Band, und es ist schmaler, als das Etikett „advanced“ des Modells nahelegt.
Die Treppe des Art. 71(2): drei Daten, im Wortlaut
Der Anwendungszeitplan steht in Artikel 71(2) der Verordnung (EU) 2024/2847, der Cyberresilienz-Verordnung (CRA):
„Diese Verordnung gilt ab dem 11. Dezember 2027. Artikel 14 gilt jedoch ab dem 11. September 2026, und Kapitel IV (Artikel 35 bis 51) gilt ab dem 11. Juni 2026.“
Drei Tranchen, die älteste zuerst.
Seit dem 11. Juni 2026: Kapitel IV. Seine Überschrift lautet „NOTIFIZIERUNG VON KONFORMITÄTSBEWERTUNGSSTELLEN“. Das ist Maschinerie: wie Mitgliedstaaten notifizierende Behörden benennen, wie notifizierte Stellen beschaffen sein müssen, wie sie sich koordinieren. Die Pflichten darin treffen die Mitgliedstaaten und die Bewertungsstellen selbst. Nichts in Kapitel IV legt Herstellern eine Pflicht auf. Die Tranche existiert, damit die Bewertungsinfrastruktur steht, bevor Hersteller sie brauchen: Art. 35(2) bestimmt, dass die Mitgliedstaaten „bis zum 11. Dezember 2026 dafür [sorgen], dass es in der Union eine ausreichende Zahl notifizierter Stellen gibt, die Konformitätsbewertungen durchführen können, um Engpässe und Hindernisse mit Blick auf den Marktzugang zu verhindern.“ Die eigenen Konformitätsbewertungspflichten der Hersteller stehen in Kapitel III (Artikel 27 bis 32) und gelten ab dem 11. Dezember 2027 mit dem Rest.
Ab dem 11. September 2026: Artikel 14, „Meldepflichten der Hersteller“. Das ist die erste Tranche, die bei Herstellern landet. Art. 14(1):
„Ein Hersteller meldet jede aktiv ausgenutzte Schwachstelle, die in dem Produkt mit digitalen Elementen enthalten ist und von der er Kenntnis erlangt, gleichzeitig dem gemäß Absatz 7 als Koordinator benannten CSIRT und der ENISA. Der Hersteller meldet diese aktiv ausgenutzte Schwachstelle über die gemäß Artikel 16 eingerichtete einheitliche Meldeplattform.“
Art. 14(2) stellt die Uhr: eine Frühwarnung „innerhalb von 24 Stunden, nachdem der Hersteller davon Kenntnis erlangt hat“, eine Meldung von Schwachstellen „innerhalb von 72 Stunden“, und ein Abschlussbericht „spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme zur Verfügung steht“. Art. 14(3) und (4) übertragen denselben Rhythmus auf jeden schwerwiegenden Sicherheitsvorfall, der sich auf die Sicherheit des Produkts auswirkt: 24 Stunden, 72 Stunden, Abschlussbericht innerhalb eines Monats. Die einheitliche Meldeplattform wird von ENISA eingerichtet, verwaltet und gepflegt (Art. 16(1)).
Ab dem 11. Dezember 2027: alles andere. Dazu gehören Artikel 13 (die Herstellerpflichten), Anhang I (die grundlegenden Cybersicherheitsanforderungen) und die Konformitätsbewertungspflichten der Hersteller. Das meiste von dem, was dieser Beitrag mappt, gilt ab diesem Datum.
Sind Sie im Anwendungsbereich? Der Test in einem Absatz
Der Anwendungsbereich ist Artikel 2. Art. 2(1):
„Diese Verordnung gilt für auf dem Markt bereitgestellte Produkte mit digitalen Elementen, deren bestimmungsgemäßer Zweck oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt.“
Die Arbeit machen die definierten Begriffe. Ein „Produkt mit digitalen Elementen“ ist „ein Software- oder Hardwareprodukt und dessen Datenfernverarbeitungslösungen, einschließlich Software- oder Hardwarekomponenten, die getrennt in den Verkehr gebracht werden“ (Art. 3(1)). „Hersteller“ ist, wer „Produkte mit digitalen Elementen entwickelt oder herstellt oder die Produkte mit digitalen Elementen konzipieren, entwickeln oder herstellen lässt und sie unter ihrem Namen oder ihrer Marke vermarktet, sei es gegen Bezahlung, zur Monetarisierung oder unentgeltlich“ (Art. 3(13)).
Hier also der Anwendungsbereichstest der Cyberresilienz-Verordnung in einem weiterleitbaren Absatz. Die Verordnung gilt für ein Produkt, wenn drei Dinge zutreffen: Es ist Software oder Hardware, einschließlich einer getrennt verkauften Komponente (Art. 3(1)); sein bestimmungsgemäßer Zweck oder seine vernünftigerweise vorhersehbare Verwendung schließt eine direkte oder indirekte, logische oder physische Verbindung mit einem Gerät oder Netz ein (Art. 2(1)); und es wird im Rahmen einer Geschäftstätigkeit auf dem EU-Markt bereitgestellt, entgeltlich oder unentgeltlich (Art. 3(22)). Die Organisation, die die Herstellerpflichten trägt, ist diejenige, die das Produkt unter eigenem Namen oder eigener Marke vermarktet, auch wenn die Entwicklung ausgelagert war (Art. 3(13)). Die wichtigsten Ausnahmen sind sektoral: Medizinprodukte unter den Verordnungen (EU) 2017/745 und 2017/746, Fahrzeuge unter (EU) 2019/2144, nach (EU) 2018/1139 zertifizierte Luftfahrtausrüstung, Schiffsausrüstung unter der Richtlinie 2014/90/EU, Ersatzteile nach identischen Spezifikationen sowie Produkte, die ausschließlich für die nationale Sicherheit, für Verteidigungszwecke oder für die Verarbeitung von Verschlusssachen entwickelt wurden (Art. 2(2)–(7)).
Eine Diskrepanz beim Publikum: ENISAs Modell sagt, es richte sich „in erster Linie an KMU, die als Hersteller, Einführer oder Händler von Produkten mit digitalen Elementen auftreten“, und könne auch Integratoren und Dienstleistern dienen. Dieses Publikum ist breiter als der Kreis der Akteure, die die Pflichten aus Art. 13, Art. 14 und Anhang I tragen, denn diese adressieren Hersteller. Die Bewertungsinhalte des Modells sind durchgehend auf Hersteller zugeschnitten; die Pflichten von Einführern und Händlern stehen in den Artikeln 19 und 20 und bleiben hier außen vor.
Was das Modell ist: fünf Domänen, fünf Level, ein Vorbehalt
ENISAs SME Cyber Resilience Maturity Assessment Model ist ein 36-seitiges PDF vom Juli 2026 plus ein begleitendes Spreadsheet, CRA_Maturity_Model_TOOL.xlsx, mit vier Blättern: Dashboard, Questionnaire, Pivots, Checklist. (Die ENISA-Publikation liegt nur auf Englisch vor; alle Zitate daraus sind hier und im Folgenden eigene Übersetzungen.)
Die Struktur: fünf Bewertungsdomänen (Governance and Documentation — Governance und Dokumentation; Risk Management and Security by Design and by Default — Risikomanagement und Sicherheit durch Konzeption und Voreinstellungen; Vulnerability and Patch Management — Schwachstellen- und Patch-Management; Product Life Cycle Management — Produktlebenszyklus-Management; Awareness, Competence and Skills — Bewusstsein, Kompetenz und Fähigkeiten), fünf Fragen pro Domäne, 25 Fragen insgesamt (Annex A, S. 20–24). Jede Frage wird auf einer fünfstufigen Skala mit generischen Deskriptoren beantwortet: Level 1 „not implemented“ (nicht umgesetzt), Level 2 „informal or ad hoc“ (informell oder ad hoc), Level 3 „documented but inconsistently applied“ (dokumentiert, aber uneinheitlich angewendet), Level 4 „consistently applied and regularly reviewed“ (konsequent angewendet und regelmäßig überprüft), Level 5 „measured, monitored and continuously improved“ (gemessen, überwacht und kontinuierlich verbessert). Das PDF benennt die Level nie; das Spreadsheet schon („1 – Initial“ bis „5 – Optimised“). ENISA veranschlagt die gesamte Bewertung mit etwa zwei Stunden.
Das Modell ist streng gegen Noteninflation (S. 17): Ein dokumentierter Prozess, den niemand befolgt, bekommt Level 2, nicht 3; wo Praktiken über Produkte hinweg uneinheitlich sind, sei Level 3 „womöglich passender“ als 4; ohne Nachweis von Überprüfung und Verbesserung ist bei 4 Schluss.
Die Bewertung ist Arithmetik. Die fünf Antworten pro Domäne werden zu einem Domänen-Score gemittelt, die fünf Domänen-Scores zu einem Gesamt-Score. Profile sind Score-Bänder: basic 1,0–2,5, intermediate 2,6–3,9, advanced 4,0–5,0.
Der Satz, der alles Weitere in diesem Beitrag begrenzt, steht im Executive Summary (S. 5):
„Auch wenn es Praktiken abbildet, die die Umsetzung des CRA unterstützen, ersetzt ein advanced Reifegrad keine rechtlichen Verpflichtungen und sollte nicht als Nachweis der Konformität betrachtet werden. Es unterstützt Organisationen stattdessen dabei, ihre Produktsicherheit und Cyberresilienz im Lauf der Zeit strukturiert und handhabbar zu stärken.“
ENISA wiederholt den Punkt noch zweimal (S. 6 und in der Einleitung zu Annex B: „Das Befolgen dieser Schritte garantiert keine Konformität“). Jede Verwendung von „Untergrenze“ weiter unten ist also eine analytische Lesart zweier nebeneinandergelegter Texte; sie verortet Praxis gegenüber der Sprache der Verordnung und beweist gegenüber keiner Behörde irgendetwas.
Das Mapping, das ENISA mitliefert: fünf Zeilen, auf Domänenebene
Die CRA-Verbindung steckt in Annex D, „mapping to Cyber Resilience Act requirements“ (S. 33). ENISAs eigene Einleitung setzt die Erwartungen: Es sei „ein indikatives Mapping“, und „nicht alle Bewertungskriterien lassen sich direkt auf spezifische CRA-Bestimmungen abbilden“.
Zuerst der strukturelle Befund, denn an ihm hängt die gesamte Untergrenzen-Frage: Das Mapping arbeitet auf Domänenebene, und es ist fünf Zeilen lang. Es mappt nirgends Reifegrad-Level, Profile oder einzelne Fragen auf CRA-Bestimmungen, und auch das Spreadsheet enthält kein Artikel-Mapping. Niemand kann aus diesem Dokument „der CRA verlangt Level N“ herauslesen, weil ENISA in keiner Richtung einen Satz dieser Form geschrieben hat.
Hier die fünf Zeilen. Die beiden mittleren Spalten verdichten ENISAs Zellen (zitierte Fragmente sind wörtlich, übersetzt); die letzte Spalte ist meine Verifikation gegen den Volltext der Verordnung — Analyse, die auf dem Mapping aufsetzt und als solche zu lesen ist.
Domäne
ENISA: „CRA requirements“
ENISA: „CRA provisions“
Gegen die Verordnung geprüft
Governance and Documentation
„Im CRA nicht ausdrücklich als eigenständige Anforderung adressiert“
Unterstützt Art. 13, Art. 31 und Anhang VII (Risikobewertung, technische Dokumentation, Konformitätsbewertung)
Hält, verkauft sich aber unter Wert: technische Dokumentation vor dem Inverkehrbringen nach Art. 13(12), dokumentierte Risikobewertung darin nach Art. 13(3)–(4), Art. 31(1)–(2) und Anhang VII sind harte Pflichten, unabhängig vom Domänen-Etikett
Risk Management and Security by Design and by Default
Anhang I, Teil I(1) und (2): Risikobewertung, sichere Konzeption, Schutz vor Schwachstellen, sichere Konfiguration
Art. 13
Hält sauber: Art. 13(1)–(4); Anhang I Teil I(1) und Teil I(2)(a)–(m)
Vulnerability and Patch Management
Anhang I, Teil II: Behandlung von Schwachstellen, Behebung, Sicherheitsaktualisierungen, koordinierte Offenlegung von Schwachstellen
Art. 13 und 14
Hält sauber: Anhang I Teil II(1)–(8); Art. 13(6) und 13(8); Art. 14. Die einzige Zeile, die Art. 14 nennt
Product Life Cycle Management
Anhang I, Teil II (Sicherheitsaktualisierungen während des Unterstützungszeitraums); Anhang II (Informationen zum Unterstützungszeitraum)
Art. 13
Hält, mit einer Auslassung: Das Kapitel der Domäne selbst (S. 13) sagt, sie umfasse „das Behandeln und Melden von Schwachstellen“, doch die Zeile überspringt Art. 14. Die zitierten Pflichten sind real: Art. 13(8), Art. 13(19), Anhang II Nummern 7 und 8(d)
Awareness, Competence and Skills
„Im CRA nicht ausdrücklich adressiert“
„Unterstützt indirekt“ die Umsetzung von Art. 13 und Anhang I
Durch Volltextsuche bestätigt: keine Schulungs-, Awareness- oder Kompetenzpflicht für Hersteller im verfügenden Teil. Art. 10 verpflichtet die Mitgliedstaaten. Erwägungsgrund 23 sagt, die Hersteller sollten „sicherstellen, dass ihr Personal über die erforderlichen Fähigkeiten verfügt“ — ein Erwägungsgrund, keine verfügende Anforderung
Zwei Nahtstellen in ENISAs eigenem Dokument:
Zeile 4 lässt Artikel 14 aus. Das Kapitel, das die Produktlebenszyklus-Domäne beschreibt, sagt, sie umfasse „das Behandeln und Melden von Schwachstellen“. Die Annex-D-Zeile derselben Domäne nennt Art. 13, Anhang I Teil II und Anhang II und überspringt Art. 14. Die Meldepflicht taucht in genau einer Zeile auf (Vulnerability and Patch Management). Wer eine einzelne Zeile als Pflichtenliste seiner Domäne liest, verpasst die am frühesten geltende Herstellerpflicht der Verordnung.
Zeile 1 sagt „nicht ausdrücklich adressiert“ und nennt dann drei verbindliche Bestimmungen. Das Etikett stimmt im engen Sinn: Der CRA enthält keine Klausel, die eine Governance-Funktion verlangt. Aber die Zelle mit den unterstützenden Bestimmungen derselben Zeile zeigt auf Art. 13, Art. 31 und Anhang VII, und die tragen harte Pflichten: technische Dokumentation, erstellt vor dem Inverkehrbringen (Art. 13(12)), aktuell gehalten „zumindest während des Unterstützungszeitraums“ (Art. 31(2)). „Nicht ausdrücklich adressiert“ liest sich, als wäre die ganze Domäne optional. Die Hälfte davon ist verfügendes Recht.
Auf Domänen-Granularität stimmt alles, was ENISA zitiert: Keine Zeile nennt einen Artikel, der falsch wiedergibt, was sie abdeckt, und ich habe keinen Widerspruch zwischen den Quellen gefunden. Eine Namenskollision, bevor Sie das Tool öffnen: Das Spreadsheet nennt Level 2 „Basic“, während das Profil für die Scores 1,0–2,5 ebenfalls „basic“ heißt — Level-Name und Profil-Band sind verschiedene Dinge, die sich ein Wort teilen.
Wo die Untergrenze liegt, und was die Verordnung nie verlangt
Annex D ist level-agnostisch, die Untergrenze muss also hergeleitet werden. Die Herleitung hat zwei Eingaben: die Verpflichtungsverben der Verordnung und die Level-Deskriptoren des Modells.
Zuerst die Verben. Anhang I Teil II verlangt von Herstellern, „eine Strategie für die koordinierte Offenlegung von Schwachstellen aufstellen und umsetzen“ (II(5)), „unverzüglich Schwachstellen behandeln und beheben“ (II(2)) und „die Sicherheit des Produkts mit digitalen Elementen regelmäßig und wirksam testen und überprüfen“ (II(3)). Art. 13(8) verlangt, dass Schwachstellen während des Unterstützungszeitraums „wirksam“ behandelt werden. Umsetzen, unverzüglich, wirksam, regelmäßig: Der Text beschreibt Dinge, die tatsächlich passieren, laufend, für jedes Produkt.
Jetzt die Deskriptoren. Level 3 ist „dokumentiert, aber uneinheitlich angewendet“, und die Abwertungsregeln des Modells sagen: Ein dokumentierter Prozess, der nicht befolgt wird, bekommt Level 2, und bei Uneinheitlichkeit über Produkte hinweg sei Level 3 „womöglich passender“ als 4. Eine uneinheitlich angewendete CVD-Strategie ist keine Strategie, die „umgesetzt“ wird. Behebung, die bei manchen Produkten stattfindet, ist für die übrigen nicht „unverzüglich“. Der erste Level-Deskriptor, der mit den Verben der Verordnung vereinbar ist, ist Level 4: „konsequent angewendet und regelmäßig überprüft“.
Was fügt Level 5 hinzu? Das Modell ist da explizit (S. 17): „Level 4 zeigt an, dass Praktiken konsequent angewendet werden, während Level 5 Nachweise für Messung (z. B. Metriken oder Key Performance Indicators) und aktive Verbesserung auf Basis der Ergebnisse verlangt.“ Ich habe den verfügenden Teil der Verordnung — Artikel und Anhänge — nach diesen Unterscheidungsmerkmalen durchsucht; die Suchen laufen gegen die englische Sprachfassung des Verordnungstexts. Der Reproduktionspfad, erneut ausführbar:
Wirksamkeit von Kontrollen mit KPIs messen (Annex-B-advanced-Liste: „Die Wirksamkeit von Sicherheitskontrollen messen und Prozesse auf Basis der Ergebnisse verbessern“): Suchen nach "key performance", "indicator", "metric", "measur" liefern keine Anforderung, die Hersteller trifft; "effectiveness" trifft einmal, in Anhang VIII im optionalen Modul der umfassenden Qualitätssicherung, das vom Hersteller verlangt, dass er dessen „Wirksamkeit während des Unterstützungszeitraums“ erhält — das Aufrechterhalten eines zugelassenen Qualitätssicherungssystems, kein Messen von Kontrollen mit KPIs.
Erkennungs- und Behebungszeiten verfolgen (Annex B advanced: „Indikatoren wie die Zeit bis zur Erkennung und Behebung von Schwachstellen verfolgen“): Teil II(2) verlangt Behebung „unverzüglich“; eine Pflicht, Erkennungs- oder Behebungszeit zu messen, taucht nirgends auf.
Kontinuierliche Prozessverbesserung (der Level-5-Deskriptor selbst): Suchen nach "continuous", "continuously", "improv" treffen genau eine verfügende Klausel: Art. 31(2), wonach die technische Dokumentation „gegebenenfalls, zumindest während des Unterstützungszeitraums, laufend aktualisiert“ wird. Das ist eine Pflicht zur Aktualität der Dokumentation. Keine Klausel erwartet von Herstellern, Prozesse kontinuierlich zu verbessern.
Management-Reviews und interne Audits der Sicherheits-Governance: "management review" hat null Treffer; "audit" trifft Bestimmungen zu notifizierten Stellen und eine Vertraulichkeitsklausel zu Inspektionen und Audits der Behörden — keine davon legt Herstellern eine interne Auditpflicht auf.
Tabletop-Übungen und Tests des Reaktionsplans: null; das Wort "exercise" erscheint nur in "exercise due diligence" und "Exercise of the delegation".
Schulungs- und Awareness-Programme (Domäne 5; Annex B advanced: „Die Wirksamkeit von Schulungen verfolgen und Prozesse auf Basis der Ergebnisse verbessern“): keine Pflicht im verfügenden Teil; Art. 10 legt Kompetenzpflichten den Mitgliedstaaten auf. Aber Erwägungsgrund 23 sagt, die Hersteller sollten „sicherstellen, dass ihr Personal über die erforderlichen Fähigkeiten verfügt, um ihren in dieser Verordnung festgelegten Verpflichtungen nachzukommen“. Ein Erwägungsgrund begründet keine Anforderung, also ist diese Abwesenheitsbehauptung weicher als die anderen: Die Domäne ist diskutabel, und so würde ich sie auch nennen, statt sie für abwesend zu erklären. ENISAs eigenes Domänenkapitel räumt den Punkt ein (S. 14): „Die Kriterien in dieser Domäne unterstützen die Umsetzung von CRA-Anforderungen, stellen aber keine unmittelbare regulatorische Verpflichtung dar.“
Es gibt außerdem ein diskutables Mittelband auf Fragenebene: risikobasierte Priorisierung (Teil II(2) rahmt die Behebung „im Hinblick auf die Risiken“), das Verifizieren, dass Aktualisierungen halten, was sie behaupten (impliziert durch Teil II(2) und II(3)), operatives Monitoring (Teil II(3); Art. 13(7)), das Verfolgen externer Advisories (eine plausible Implikation der Sorgfaltspflichten des Art. 13(5) bei Komponenten Dritter). Nichts davon ist sauber abwesend, also gehört nichts davon auf die Liste ohne Trace.
Die Lesart, die ich vertreten kann, einmal ausgesprochen: Die Untergrenze des CRA ist, im Vokabular dieses Modells, ein Band aus Level-4-Praxis in den drei gemappten Domänen (Risikomanagement und sichere Konzeption, Schwachstellen- und Patch-Management, Produktlebenszyklus-Management) plus die Dokumentationspflichten hinter der Governance-Zeile. Nichts, was Level 5 auszeichnet, geht auf irgendeine CRA-Bestimmung zurück, und die Level der Awareness-Domäne sind höchstens Erwägungsgrund-Territorium. Das Band sitzt unbequem gegenüber den Profilnamen: 4,0 ist numerisch der Beginn von „advanced“, also unterschreitet „intermediate“ (2,6–3,9) die Verpflichtungsverben, während das advanced-Profil Level-5-Inhalte bündelt, die die Verordnung nie verlangt.
Drei Vorbehalte zu diesem Band.
Erstens kann Mittelwertbildung eine Domäne unterhalb der Untergrenze verstecken. Das durchgerechnete Beispiel des Tools kommt mit Domänen-Scores von 1,8, 2,8, 4,4, 2,8 und 3,0 auf eine Gesamtnote von 3: insgesamt „intermediate“, über 4 im Schwachstellen-Management, unter 2 in der Governance. Das Modell warnt selbst davor (Step 5, S. 18): Der Gesamt-Score „sollte nicht isoliert betrachtet werden. Ein intermediate Score bedeutet nicht, dass alle Bereiche auf demselben Niveau arbeiten.“ Die Zahl, die gegen das Band zu halten ist, ist der Domänen-Score, und zwar nur für die gemappten Domänen.
Zweitens ein Gegensignal: ENISA behandelt CRA-Arbeit nicht als Thema der oberen Etage. Annex Bs Aktionsliste für basic-Reife enthält bereits CRA-abgeleitete Punkte, darunter „Die zuständige Marktüberwachungsbehörde identifizieren und die grundlegenden Melde-Erwartungen unter dem CRA verstehen“ (S. 26) und den Aufbau eines Komponenteninventars „(SBOM), nach Möglichkeit in einem gängigen und maschinenlesbaren Format“ (S. 27). Wo das Modell mit CRA-relevanter Arbeit beginnt (basic) und wo Praxis den Verben der Verordnung entspricht (Level 4 in den gemappten Domänen), sind zwei verschiedene Punkte auf derselben Skala. Die Untergrenzen-Behauptung hier betrifft den zweiten.
Drittens ist im Dashboard des Spreadsheets für jede Domäne ein „Target“ von 5 fest hinterlegt. Das ist ein Spreadsheet-Default, keine irgendwo in der Prosa des Berichts ausgesprochene ENISA-Empfehlung, und die Verordnung setzt kein Maximierungsziel welcher Art auch immer. Der Vorbehalt von Seite 5 regiert weiterhin alles: Auch eine Selbstbewertung von 5,0 ist kein Konformitätsnachweis.
Sieben Fragen, um sich gegen die Untergrenze zu bewerten
Annex A hat 25 Fragen und keine Zitate von CRA-Artikeln oder -Bestimmungen (eine Frage, 1.5, nennt den CRA in Prosa). Hier sind sieben, daraus adaptiert, ausgewählt nach einer Regel: Jede muss auf einen konkreten Artikel oder eine Anforderung des Anhangs I zurückführbar sein. Die Klausel-IDs sind der Trace, verifiziert gegen den Volltext der Verordnung.
Technische Dokumentation (Annex A 1.3) — Existiert technische Dokumentation auf Produktebene, einschließlich der Bewertung der Cybersicherheitsrisiken? Trace: Art. 13(4), Art. 13(12), Art. 31, Anhang VII.
Risikogetriebene Konzeption (2.1) — Leiten dokumentierte Risikobewertungen Konzeption, Entwicklung und Komponentenentscheidungen? Trace: Art. 13(2)–(3).
Sichere Voreinstellungen (2.3) — Werden Produkte mit einer sicheren Standardkonfiguration bereitgestellt? Trace: Anhang I Teil I(2)(b).
Eingehende Schwachstellenbehandlung (3.1) — Können Außenstehende eine Schwachstelle melden, und wird jede Meldung erfasst und nachverfolgt? Trace: Anhang I Teil II(1) und II(6); Art. 13(17) zentrale Kontaktstelle; Art. 13(8) CVD-Strategie.
Sicherheitsaktualisierungen (3.2) — Werden Sicherheitsaktualisierungen erstellt, getestet und mit Hinweisen verbreitet, kostenlos? Trace: Anhang I Teil II(2), II(7), II(8); Teil I(2)(c).
SBOM (3.3) — Gibt es eine Software-Stückliste „in einem gängigen maschinenlesbaren Format“, aus der „zumindest die obersten Abhängigkeiten“ hervorgehen? Trace: Anhang I Teil II(1).
Unterstützungszeitraum (4.2) — Ist ein Unterstützungszeitraum festgelegt (mindestens fünf Jahre oder die erwartete Nutzungsdauer, wenn kürzer), mit dem Enddatum, das zum Kaufzeitpunkt angegeben wird? Trace: Art. 13(8), Art. 13(19), Anhang II Nummer 7.
Bewerten Sie jede Antwort mit den Deskriptoren des Modells und seinen Abwertungsregeln, ehrlich: dokumentiert-aber-nicht-befolgt ist eine 2. Gemessen am oben hergeleiteten Band sind das die Fragen, bei denen „dokumentiert, aber uneinheitlich angewendet“ hinter den Verben der Verordnung zurückbleibt. Dieselbe Grenze wie zuvor: Eine Selbstbewertung verortet Praxis auf ENISAs Skala; nach ENISAs eigenem Vorbehalt ist sie kein Konformitätsnachweis.
Die zwei Daten, die das aktuell machen, sind der 11. September 2026, wenn die 24-Stunden- und 72-Stunden-Meldepflichten des Art. 14 beginnen, und der 11. Dezember 2027, wenn Art. 13 und Anhang I folgen. Der Spreadsheet-Durchlauf dauert etwa zwei Stunden, und das Band, gegen das die Scores der gemappten Domänen zu halten sind, ist Level 4. Für ein konkretes Produkt, seine Kategorie und seinen Konformitätsweg ist das eine Frage für qualifizierte Rechtsberatung — und für die Konformitätsbewertung, die die Verordnung selbst vorschreibt.
devguard mappt Kontrollen auf die Frameworks, die sie verlangen, Klausel für Klausel — nützlich, wenn CRA-Pflichten neben ISO-27001- oder NIS2-Pflichten stehen: devguard.ch.
Folgen Sie dem Dispatch, oder sehen Sie devguard in Aktion.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird — ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird — ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.