Nachweisbarkeit
Cyber Resilience Act: Was Ihre Software ab September 2026 belegen muss.
Der CRA sagt, was Hersteller melden und dokumentieren müssen. Er sagt nicht, wie die Software gebaut sein muss, damit eine 24-Stunden-Frist haltbar ist. Diese Seite übersetzt die Pflichten in Architekturanforderungen — und sagt deutlich, wen die Verordnung nicht betrifft.
Die Frist läuft ab Kenntnis. Die Antwort muss aus dem System kommen.
Am 11. September 2026 beginnt der erste greifbare Teil des Cyber Resilience Act: Hersteller von Produkten mit digitalen Elementen melden aktiv ausgenutzte Schwachstellen binnen 24 Stunden als Frühwarnung und binnen 72 Stunden als vollständige Meldung. Dasselbe gilt für schwere Sicherheitsvorfälle.
Diese Fristen sind keine organisatorische Herausforderung, sondern eine architektonische. Wer nicht abfragen kann, welche Produktversionen bei welchen Kunden laufen, seit wann eine Schwachstelle bekannt ist und welche Daten betroffen sind, meldet Schätzungen. Und jede korrigierte Schätzung ist selbst ein Vorgang, den man belegen muss.
Der Rest der Verordnung folgt ab 11. Dezember 2027: Security by Design, Schwachstellenbehandlung über mindestens fünf Jahre, technische Dokumentation, Konformitätsbewertung. Der gemeinsame Nenner aller Stufen: Die Nachweise entstehen im System — oder sie entstehen nicht.
Von der Pflicht zur Architekturanforderung.
Die linke Spalte steht in der Verordnung. Die mittlere ist das, was Ihr System dafür können muss. Die rechte ist das, was Sie im Ernstfall vorlegen.
| Pflicht aus dem CRA | Was das System können muss | Was Sie vorlegen |
|---|---|---|
| Meldung aktiv ausgenutzter Schwachstellen: 24h Frühwarnung, 72h Meldung (Art. 14) | Betroffenheit ist abfragbar: welche Versionen, welche Installationen, welche Mandanten, seit welchem Zeitpunkt. | Eine Meldung mit belastbarer Betroffenheitsaussage — aus dem System abgeleitet, nicht geschätzt. |
| Meldung schwerer Sicherheitsvorfälle (Art. 14) | Der Vorfall ist rekonstruierbar: was passiert ist, in welcher Reihenfolge, mit welchen Auswirkungen. | Ein rekonstruierter Ablauf aus der Historie — Zeitpunkt, Auslöser, betroffene Daten und Funktionen. |
| Security by Design über den Lebenszyklus (Art. 13, Anhang I) | Sicherheitsrelevante Änderungen an Code, Konfiguration und Rechten sind als Vorgänge mit Auslöser und Freigabe festgehalten. | Herkunft jeder Änderung: was, wann, von wem ausgelöst, in welcher Version ausgerollt. |
| Schwachstellenbehandlung über den Supportzeitraum (Art. 13, mind. fünf Jahre) | Versionen, Stellstände und deren Verbreitung sind über Jahre nachvollziehbar, nicht nur der aktuelle Stand. | Welche Installation auf welchem Stand läuft und welche Aktualisierung wann angeboten wurde. |
| Technische Dokumentation und Stückliste der Komponenten (Anhang I und IV) | Abhängigkeiten und deren Versionen sind je ausgeliefertem Release festgehalten — nicht nur im aktuellen Repository-Stand. | Die Stückliste eines bestimmten Release-Stands, auch die von vor zwei Jahren. |
| Konformitätsbewertung und EU-Konformitätserklärung (Art. 31, 32) | Entwicklungs-, Test- und Freigabeprozesse sind belegbar statt nur beschrieben. | Nachweis, dass die deklarierten Prozesse im Einzelfall tatsächlich so gelaufen sind. |
Umsetzungssicht, keine Rechtsberatung. Ob und in welcher Rolle Sie betroffen sind — Hersteller, Importeur, Händler — klärt Ihre Rechtsberatung. Reine SaaS- und Cloud-Dienste fallen grundsätzlich nicht unter den CRA; für sie ist NIS2 der einschlägige Rahmen.
Die vier Lücken, die ab September teuer werden.
Nicht bei Herstellern ohne Sicherheitsprozess. Bei Produkten, deren Historie nie als Nachweis gedacht war.
Betroffenheit als Schätzung
Niemand kann abfragen, welche Kundeninstallationen auf welcher Version laufen. Die 24-Stunden-Frist beginnt mit Kenntnis der Schwachstelle — wer dann erst Inventur macht, meldet zu spät oder falsch.
Schwachstellen-Management als Ticketliste
Ein Tracker sagt, dass eine Schwachstelle geschlossen ist. Er belegt nicht, wann sie bekannt wurde, wer sie eingestuft hat und welche Versionen betroffen waren. Genau diese Zeitpunkte lösen die Fristen aus.
Supportversprechen ohne Stellstand
Fünf Jahre Sicherheitsupdates sind zugesagt. Aber Build, Release und Auslieferung von vor drei Jahren lassen sich nicht mehr reproduzieren. Das Versprechen existiert, der Nachweis nicht.
Stückliste als Momentaufnahme
Die Abhängigkeiten lassen sich aus dem aktuellen Repository erzeugen. Die Frage eines Prüfers lautet aber: Welche Komponenten steckten in der Version, die der Vorfall betrifft?
Wie wir die Lücke schließen.
Nicht als Zertifizierungsprojekt. An der einen Frage, die im Ernstfall zuerst kommt: Was genau ist betroffen?
1 — Meldereife feststellen
Wir gehen die Fragen durch, die eine 24-Stunden-Meldung verlangt: Version, Verbreitung, Kenntniszeitpunkt, betroffene Daten. Markiert wird, was Ihr System heute beantwortet — und was im Ernstfall geraten würde.
2 — Betroffenheit abfragbar machen
Produktversionen, Installationen und Mandanten werden so verknüpft, dass die Tragweite einer Schwachstelle in Minuten eingegrenzt ist, nicht in Tagen.
3 — Unveränderliche Historie für das Sicherheitsrelevante
Schwachstellen, Einstufungen, Freigaben und Auslieferungen werden als fachliche Ereignisse geführt — nachträglich nicht veränderbar, jederzeit abfragbar.
4 — Übergabe mit Namen drauf
Am Ende steht jemand intern dafür gerade. Wir dokumentieren für die Person, die die erste Meldung ohne uns absetzt.
Wann das passt — und wann nicht.
Passt, wenn
- Sie Software als Produkt auf den Markt bringen — zum Download, eingebettet oder als lizenzierte Komponente
- Abnehmer CRA-Nachweise über die Lieferkette von Ihnen verlangen
- die Meldefristen ab September 2026 heute nicht abgedeckt sind
- ein neues Produkt entsteht und die Pflichten von Anfang an eingebaut statt nachgerüstet werden sollen
Passt nicht, wenn
- Sie einen reinen SaaS-/Cloud-Dienst ohne Produktcharakter betreiben — dann ist NIS2 Ihr Thema, nicht der CRA
- Sie eine Konformitätsbewertung oder CE-Beratung brauchen — dafür gibt es benannte Stellen
- Sie Rechtsberatung zur Betroffenheit suchen
- nur ein Tool eingekauft werden soll — die eigentliche Frage ist, was Ihr System belegen kann
Häufige Fragen
- Gilt der CRA auch für unser SaaS-Angebot?
- Grundsätzlich nicht: Reine Cloud- und SaaS-Dienste fallen nicht unter den CRA, für sie ist NIS2 der einschlägige Rahmen. Eine Ausnahme gibt es — Datenfernverarbeitung, die für die Funktion eines Produkts notwendig ist, zählt zum Produkt. Ob das auf Sie zutrifft, ist eine juristische Frage. Was wir klären können: ob Ihre Systeme die Nachweise liefern könnten, falls ja.
- Was ändert sich konkret am 11. September 2026?
- Die Meldepflichten nach Art. 14 beginnen: Aktiv ausgenutzte Schwachstellen sind binnen 24 Stunden als Frühwarnung und binnen 72 Stunden als Meldung zu berichten, schwere Sicherheitsvorfälle ebenfalls binnen 72 Stunden. Gemeldet wird über die zentrale Meldeplattform an das zuständige CSIRT und die ENISA. Die übrigen Pflichten — Security by Design, Dokumentation, Konformitätsbewertung — folgen am 11. Dezember 2027.
- Was droht bei Verstößen?
- Für Verstöße gegen die wesentlichen Anforderungen und die Meldepflichten sieht die Verordnung Bußgelder bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes vor. Der praktischere Hebel ist der Markt: Produkte ohne Konformität dürfen nicht mehr bereitgestellt werden, und Abnehmer fragen die Nachweise zunehmend in der Lieferkette ab.
- Reicht unser bestehendes Schwachstellen-Management?
- Als Prozess vielleicht. Neu ist die Nachweisbarkeit der Zeitpunkte: Wann wurde die Schwachstelle bekannt, wann eingestuft, wann gemeldet, welche Versionen waren betroffen? Ein Ticketsystem beantwortet das selten prüffest — die Fristen laufen ab Kenntnis, und Kenntnis muss datiert sein.
- Wir sind Zulieferer, kein Hersteller. Betrifft uns das?
- Sehr wahrscheinlich über die Lieferkette. Hersteller müssen die Sicherheit ihrer Komponenten dokumentieren und reichen diese Anforderungen an Zulieferer weiter — ähnlich wie Security-Fragebögen heute, nur mit Rechtsform dahinter.
Quellen
Wir zitieren den veröffentlichten Verordnungstext, damit Sie jede Aussage selbst prüfen können.
Könnten Sie morgen eine 24-Stunden-Meldung absetzen?
Der Nachweisfähigkeits-Check prüft in zehn Fragen, ob Ihr System die Antworten liefert, die eine Meldung verlangt: Betroffenheit, Zeitpunkt, Historie. Zehn Minuten, keine Anmeldung, Ergebnis sofort.