Der Trost einer Zahl
Am 13. Juli 2026 veröffentlichte ENISA das SME Cyber Resilience Maturity Assessment Model. Der Name ist sperrig. Das Werkzeug verdient Aufmerksamkeit. Es richtet sich an Kleinstunternehmen sowie kleine und mittlere Unternehmen, die Produkte mit digitalen Elementen herstellen oder auf den Markt bringen, und kann ebenso von Integratoren und Dienstleistern genutzt werden. Es umfasst fünf Domänen: Governance und Dokumentation, Risikomanagement und Security by Design und by Default, Schwachstellen- und Patch-Management, Management des Produktlebenszyklus sowie Bewusstsein und Kompetenzen. Jedes Kriterium wird auf fünf Stufen bewertet, von fehlenden oder informellen Praktiken bis zu gesteuerten, kontinuierlich verbesserten Prozessen. Daraus ergeben sich drei Profile: Basic, Intermediate und Advanced.
Dazu kommt eine offizielle Excel-Tabelle. Sie führt durch die Bewertung, berechnet den Score und erlaubt es, die Selbstbewertung später zu wiederholen. Für ein Softwareunternehmen mit fünfzehn Beschäftigten, das den CRA seit zwei Jahren als bedrohliche Wolke aus Artikeln, Anhängen, unfertigen Normen und wandernden Terminen beschrieben bekommt, lässt sich kaum etwas Beruhigenderes vorstellen. Endlich ein Gegenstand mit Grenzen. Öffnen, antworten, Standort bestimmen. Nach sechs Monaten zurückkehren und messen, wie weit man gekommen ist.
Diese Erleichterung ist berechtigt. Das Werkzeug ist kostenlos, verständlich und dem Alltag eines KMU näher als viele Rahmenwerke, die für Organisationen mit CISO, eigener Rechtsabteilung und Menschen entworfen wurden, die den Freitagnachmittag der Governance widmen können. ENISA behandelt knappe Ressourcen nicht als moralisches Versagen. Die Agentur versucht, aus einer komplexen Verordnung einen Weg zu machen, den ein kleines Unternehmen gehen kann, ohne so zu tun, als wäre es eine Bank.
Und das Modell ist strenger, als das Wort Selbstbewertung vermuten lässt. Das Dokument verlangt, den Score auf objektive Nachweise zu stützen — dokumentierte Verfahren, umgesetzte Praktiken, beobachtbares Verhalten — und nicht auf Annahmen oder informelle Eindrücke. Es fragt nicht einfach: „Halten Sie sich für gut?“ Es fordert den Blick auf das, was existiert. Wer das Modell als weiteren bürokratischen Fragebogen abtut, hat es nicht gelesen.
Gerade weil es gut gebaut ist, wird die Zahl am Ende so leicht falsch zu verwenden sein.
Der Satz, den ENISA vorweggenommen hat
ENISA setzt den entscheidenden Hinweis in die Zusammenfassung und wiederholt ihn bei den Zielen des Modells. Selbst der Reifegrad Advanced ersetzt keine rechtlichen Pflichten und darf nicht als Konformitätsnachweis betrachtet werden. Das ist keine defensive Fußnote, die eine Rechtsabteilung am Ende ergänzt hat. Es ist eine Grenze des Entwurfs: Das Werkzeug misst eine Sache, der CRA verlangt am Ende eine andere.
Die Unterscheidung wirkt selbstverständlich, bis ein Score auftaucht. Basic, Intermediate und Advanced sind Wörter, die eine Organisation beschreiben. In einer farbigen Zelle sehen sie plötzlich wie ein Urteil aus. Advanced klingt nicht mehr nach „unsere Praktiken sind ziemlich strukturiert“. Es klingt nach „bestanden“. Steht darüber der Name der Agentur der Europäischen Union für Cybersicherheit, wird die Bedeutungsverschiebung beinahe zwangsläufig. Ein interner Indikator wird zur externen Qualifikation, ohne dass je jemand förmlich beschlossen hätte, dass er eine sein soll.
ENISA redet die eigene Arbeit nicht klein. Die Agentur sagt etwas Interessanteres: Reife begünstigt Konformität, ist aber nicht mit ihr identisch. Eine Organisation, die Verantwortung zuweist, Schwachstellen steuert, Dokumentation erzeugt und ihre Prozesse überprüft, ist wesentlich besser aufgestellt als eine, die im Gedächtnis zweier Personen lebt. Trotzdem kann sie ein nicht konformes Produkt haben. Umgekehrt kann eine noch wenig reife Organisation die Konformität eines einfachen, klar abgegrenzten Produkts nachweisen — vielleicht mit einem manuellen Aufwand, den sie beim nächsten Produkt nicht wiederholen kann.
Der Reife-Score beantwortet die Frage: „Wie verlässlich ist unsere Arbeitsweise?“ Die Konformitätsbewertung beantwortet: „Erfüllt dieses Produkt in dieser Konfiguration diese anwendbaren Anforderungen?“ Die Fragen liegen nah beieinander. Austauschbar sind sie nicht.
Zwei Selbstbewertungen, zwei Gegenstände
Hier ist eine Korrektur nötig, denn die schnellste Erklärung des Unterschieds ist zugleich juristisch falsch. Man könnte sagen, das ENISA-Modell sei eine Selbstbewertung, während Konformität von einer externen Stelle zertifiziert werde. Das wäre eine saubere Geschichte. Der CRA erzählt sie nicht.
Die Europäische Kommission fasst die Verfahren eindeutig zusammen. Für die Standardkategorie, zu der die meisten Produkte mit digitalen Elementen gehören, kann der Hersteller die interne Kontrolle nutzen. Das ist Modul A in Anhang VIII: Der Hersteller erstellt die technische Dokumentation, stellt sicher, dass Entwurf, Entwicklung, Produktion und Schwachstellenbehandlung die grundlegenden Anforderungen erfüllen, stellt die EU-Konformitätserklärung aus und übernimmt dafür die Verantwortung. Bei bestimmten Klassen wichtiger Produkte hängt die interne Kontrolle von der Anwendung harmonisierter Normen, gemeinsamer Spezifikationen oder von Zertifizierungssystemen ab. Wichtige Produkte der Klasse II und kritische Produkte erfordern Verfahren mit Dritten oder anwendbare europäische Zertifizierungssysteme. Die Einzelheiten ändern sich mit der Kategorie. Das Prinzip bleibt: Artikel 32 des CRA definiert Konformität nicht durch die Anwesenheit eines Auditors.
In vielen Fällen sind also beide Vorgänge Selbstbewertungen. Sogar dieselbe Person kann sie koordinieren. Was alles verändert, ist der Gegenstand der Aussage.
Im Reifemodell ist dieser Gegenstand die Organisation und die Beständigkeit ihrer Praktiken. Die Kriterien reichen über Produkte, Teams und Prozesse hinweg. Das Modell selbst verlangt, zunächst die Produkte im Anwendungsbereich des CRA zu identifizieren, ihre Kategorien zu bestimmen und die einschlägigen Konformitätsbewertungsverfahren festzulegen. Anschließend weist es darauf hin, dass sein Score nicht zwischen den Produktkategorien unterscheidet. Das ist kein Mangel. Es ist der Preis seiner organisationsweiten Verwendbarkeit.
In der Konformitätsbewertung ist der Gegenstand dagegen ein identifiziertes Produkt. Die Aussage lautet nicht „wir steuern Schwachstellen gut“, sondern „diese Version dieses Produkts erfüllt mit diesen Komponenten während dieses Supportzeitraums die anwendbaren Anforderungen, und wir können zeigen, warum“. Die EU-Konformitätserklärung ist keine Note. Sie ist der Akt, mit dem der Hersteller seinen Namen unter diese Aussage setzt und die Verantwortung für ihre Wahrheit übernimmt.
Der Unterschied liegt nicht darin, wer das Formular ausfüllt. Er liegt darin, was jemand über welchen Gegenstand behauptet und welche Folgen diese Behauptung hat.
Was die Zahl ausblendet
Jeder Score ist eine Kompressionsmaschine. Er nimmt eine komplexe Wirklichkeit, verwirft fast alles und behält einen vergleichbaren Wert. Genau das macht ihn nützlich: Kein Geschäftsführer möchte jedes Quartal vierhundert Seiten Logs erhalten, nur um zu verstehen, ob das Unternehmen besser wird. Doch die bei der Kompression verworfenen Informationen sind genau jene, die gebraucht werden, sobald Konformität nachzuweisen ist.
Nehmen wir das Schwachstellenmanagement. Eine Organisation kann definierte Rollen, einen dokumentierten Prozess, überwachte externe Quellen, Patch-SLAs und regelmäßige Überprüfungen haben. Bestätigen die Nachweise diese Aussagen, rechtfertigt das eine hohe Stufe im ENISA-Modell. Nichts davon garantiert, dass der Prozess bei jedem Produkt funktioniert hat. Eine Meldung kann im falschen Backlog liegen geblieben sein. Für ein Release kann die SBOM fehlen. Eine Abhängigkeit kann im ausgelieferten Paket vorhanden sein und im Inventar fehlen. Eine Schwachstelle kann als nicht ausnutzbar eingestuft worden sein, ohne dass jemand die Begründung aufbewahrt hat.
Der Reifegrad sagt weiterhin etwas Wahres über die Organisation. Doch um dieses Produkt für konform zu erklären, braucht es die Kette, die der Score nicht enthält: bewertete Version, Risikobewertung, Komponentenverzeichnis, eingegangene Meldungen, tatsächliche Bearbeitungs- und Behebungszeiten, Tests, begründete Entscheidungen, Supportzeitraum, Verantwortlichkeiten und Daten. Außerdem muss sich rekonstruieren lassen, wie sich diese Kette von einem Release zum nächsten verändert hat.
Das ist der Punkt, der am leichtesten verloren geht. ENISA verlangt objektive Nachweise, bevor ein Score vergeben wird, und das ist richtig. Aber die Existenz von Nachweisen erteilt dem Score keine Generalvollmacht über sie. Es bleibt zu prüfen, ob sie zum Produkt gehören, die anwendbaren Anforderungen vollständig abdecken, der auf den Markt gebrachten Version entsprechen und für den erforderlichen Zeitraum gepflegt werden. Die Zahl sagt, dass das Haus eine gute Methode für sein Archiv hat. Sie sagt nicht, dass die gesuchte Akte darin liegt.
Der Markt liebt Ersatzgrößen
In wenigen Monaten wird dieser Score in Ausschreibungen, Lieferantenqualifikationen und Vertriebsunterlagen auftauchen. Dafür muss man keinen Betrug unterstellen. Es genügt, den Anreizen zu folgen.
Der Vertrieb möchte einen Satz, der die Frage nach der Vorbereitung auf den CRA beendet. „Profil Advanced nach dem ENISA-Modell“ passt in eine Zeile, trägt einen gewichtigen Namen und erspart allen die Erklärung des Unterschieds zwischen einem Produkt der Standardkategorie und einem wichtigen Produkt der Klasse II. Der Einkauf möchte hundert Lieferanten auf eine vergleichbare Tabelle reduzieren. Einen Score abzufragen ist billig. Technische Dokumentationen zu öffnen, Nachweise stichprobenartig zu prüfen und über den Geltungsbereich zu sprechen ist teuer. Die Beratung möchte eine wiederholbare Leistung. Eine Excel-Tabelle auszufüllen hat einen Anfang, ein Ende und ein Ergebnis, das auf der Schlussfolie gut aussieht.
Keiner der drei muss lügen, damit sich die Ersatzgröße durchsetzt. Es reicht, dass jeder die Zahl der nächsten Frage vorzieht.
Das ist Goodharts Gesetz in seiner vertrauten Form: Wenn eine Messgröße zum Ziel wird, hört sie auf, eine gute Messgröße zu sein. Wird Advanced zur informellen Bedingung im Einkauf, beginnen Organisationen, ihre Antworten zu optimieren. Nicht zwingend durch Fälschung. Sie wählen den günstigsten Geltungsbereich, legen „konsequent angewandt“ großzügig aus, bereiten jene Nachweise vor, die die Stufe erhöhen, und vertagen jene, die das Produktrisiko tatsächlich schließen. Ein Modell, das Lücken sichtbar machen soll, wird dazu benutzt, den Durchschnitt vorzeigbar zu machen.
Die Autorität von ENISA erhöht die Gefahr, nicht weil ENISA einen Fehler gemacht hätte, sondern weil der Name den Warnhinweis überleben wird, der die Grenzen des Werkzeugs definiert. Das Logo bleibt auf dem Dokument. Auf dem Weg von der Publikationsseite in die Vertriebspräsentation verschwindet der Satz „darf nicht als Konformitätsnachweis betrachtet werden“.
Vom Score zur technischen Dokumentation
Das Modell richtig zu verwenden heißt, jede Antwort als Beginn der Arbeit zu behandeln, nicht als deren Abschluss. Wenn ein Kriterium besagt, dass Schwachstellen verfolgt und priorisiert werden, lautet die nächste Frage nicht: „Wie viele Punkte gibt das?“ Sie lautet: Für welche Produkte, in welchem System, unter welcher Kennung, gegenüber welcher Anforderung, ausgelöst durch welches Ereignis, geprüft von wem und wann aktualisiert?
Daraus entsteht eine Kette. Kriterium, Produkt, Anforderung, Nachweis, Owner, Datum, Änderungshistorie. Fehlt eines dieser Glieder, kann der Score weiterhin die interne Roadmap steuern, aber er kann nicht zum Beweisersatz befördert werden. Bestehen die Verbindungen und werden sie von der normalen Arbeit gespeist — die SBOM vom Build, das Schwachstellenregister vom Ticketsystem, die Entscheidungen vom Release-Prozess —, wird der Score beinahe nebensächlich. Die Organisation hat sich nicht nur für reif erklärt. Sie hat die Fähigkeit gebaut, ihre Aussagen Produkt für Produkt nachzuweisen.
Das ist der Schritt vom manuell gepflegten Register zum lebenden Inventar, und ein eleganteres Dokument wird ihn nicht leisten. Dafür braucht es Compliance als Architektur: Nachweise, die von realen Systemen erzeugt, mit Entscheidungen verbunden und lange genug aufbewahrt werden, um die Menschen zu überdauern, die sie getroffen haben.
Hier zeigt sich auch der Wert der Beratung. Das Modell für den Kunden auszufüllen erzeugt eine ordentlichere Fassung der Wahrnehmung des Kunden. Antworten stichprobenartig zu prüfen, Repositories zu öffnen, eine Schwachstelle von der Meldung bis zum Patch zu verfolgen, die SBOM mit dem ausgelieferten Artefakt zu vergleichen und fehlende Verbindungen zu bauen verwandelt eine Diagnose in Beweisfähigkeit. Das sind zwei verschiedene Berufe. Der erste hinterlässt einen Score. Der zweite hinterlässt eine Infrastruktur, die weiter Nachweise erzeugt, wenn der Berater nicht mehr im Raum ist.
Der Spiegel und das Fenster
Das ENISA-Werkzeug ist nicht die Antwort auf den Cyber Resilience Act. Es ist die gut gestellte Frage. Es fordert ein KMU auf, fünf Bereiche seiner Arbeit zu betrachten, die zu oft getrennt bleiben, und gibt ihm eine gemeinsame Sprache für die Entscheidung, wo es beginnen soll. So eingesetzt zählt das Profil weniger als die Lücke, die es sichtbar macht. Basic, Intermediate und Advanced sind Koordinaten auf einer Karte, keine Stempel in einem Pass.
Der CRA verlangt einen anderen Schritt. Bevor ein Produkt auf den Markt kommt, muss der Hersteller die Argumentation um diesen Gegenstand schließen und unterschreiben können. Manchmal tut er das allein mit Modul A. Manchmal muss er eine benannte Stelle einbeziehen oder ein anderes zulässiges Verfahren nutzen. In beiden Fällen hängt die Qualität der Antwort von den Nachweisen ab, die das Reifemodell zu finden geholfen hat, nicht von der Stufe in der letzten Zelle.
ENISA hat einen Spiegel gebaut. Ein Spiegel zeigt, wo wir stehen, und das ist bereits viel. Wer hineinsieht, erhält eine ehrliche Roadmap, Prioritäten und reale Kosten. Wer ihn anderen als Fenster vorhält, wird feststellen, dass sich darin kein Produkt, keine Anforderung und kein Nachweis erkennen lässt. Zu sehen ist nur die eigene Überzeugung, bereit zu sein.
Was du mitnimmst
Das ENISA-Modell ist ein starkes Diagnosewerkzeug: Es bewertet fünf Domänen, verlangt objektive Nachweise für die Antworten und macht sichtbar, wo ein KMU zuerst investieren muss.
Das Profil Advanced ist kein Konformitätsnachweis, wie ENISA ausdrücklich festhält. Es beschreibt die Reife der Praktiken einer Organisation, nicht die Konformität einer bestimmten Version eines bestimmten Produkts.
Der Unterschied lautet nicht Selbstbewertung gegen externe Prüfung. Der CRA erlaubt für viele Produkte die interne Kontrolle nach Modul A, doch dieses Verfahren verlangt technische Dokumentation, Produktverantwortung und eine EU-Konformitätserklärung.
Ein Score trennt Kriterium, Produkt, Anforderung und Nachweis voneinander. Diese Kompression macht ihn zur guten Orientierung und zur Gefahr, sobald eine Ausschreibung oder Vertriebsunterlage ihn als Ersatz für ein Zertifikat behandelt.
Vom Score zur technischen Dokumentation führt eine überprüfbare Kette: Zu jeder Antwort gehören Produkt, CRA-Anforderung, Nachweis, Owner, Datum und Änderungshistorie. Beratung schafft Wert, indem sie diese Kette baut, nicht indem sie die Tabelle für den Kunden ausfüllt.
Fragen & Antworten
Was misst das ENISA-Reifemodell für den CRA?
Es misst in fünf Domänen, wie strukturiert, konsequent angewandt und kontinuierlich verbessert die Sicherheitspraktiken einer Organisation sind: Governance und Dokumentation, Risikomanagement und Security by Design, Schwachstellen- und Patch-Management, Produktlebenszyklus sowie Kompetenzen. Es ist eine organisatorische Diagnose, die vor allem KMU zeigen soll, wo sie stehen und was sie zuerst angehen müssen.
Beweist ein ENISA-Profil Advanced die Konformität mit dem Cyber Resilience Act?
Nein. ENISA schließt das ausdrücklich aus: Selbst das Profil Advanced ersetzt keine rechtlichen Pflichten und darf nicht als Konformitätsnachweis gelten. Der Score beschreibt organisatorische Reife; Konformität muss für ein konkretes Produkt anhand der anwendbaren Anforderungen und des einschlägigen Verfahrens nachgewiesen werden.
Verlangt die Konformität nach dem CRA immer eine benannte Stelle?
Nein. Bei Produkten der Standardkategorie kann der Hersteller die interne Kontrolle nach Modul A nutzen und in eigener Verantwortung erklären, dass das Produkt die grundlegenden Anforderungen erfüllt. Für bestimmte wichtige oder kritische Produktkategorien gelten strengere Verfahren, die harmonisierte Normen, eine Zertifizierung oder eine benannte Stelle einbeziehen können.
Welche Nachweise braucht es zusätzlich zum Reife-Score?
Die Nachweise müssen an Produkt und Version gebunden sein: Risikobewertung, technische Dokumentation, eine beim Build erzeugte SBOM, Schwachstellenregister, tatsächliche Bearbeitungs- und Behebungszeiten, begründete Entscheidungen, Tests, Supportzeitraum und Änderungshistorie. Das ENISA-Werkzeug kann zeigen, wo man suchen muss, aber seine Endzahl ersetzt keines dieser Artefakte.
Wie sollte ein KMU das ENISA-Werkzeug einsetzen?
Als Roadmap, nicht als Schutzschild. Jede Antwort sollte mit den betroffenen Produkten, den anwendbaren CRA-Anforderungen, den verfügbaren Nachweisen und einem Owner verbunden sein, der sie aktuell hält. Der Wert des Scores liegt in der Lücke, die er sichtbar macht, und in der Arbeit, die er priorisieren hilft.
Der Autor
