Cyber Resilience Act Umsetzung: Ihre Roadmap bis September 2026

 

Cyber Resilience Act Umsetzung: Das Wichtigste auf einen Blick

Der erste verbindliche Stichtag des CRA ist der 11. September 2026, nicht Dezember 2027. Ab diesem Datum gilt die Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle.

Was bis dahin vorliegen muss:

• Scoping und Risikoklassifizierung des eigenen Produkts (bis Ende Juni 2026)
• SBOM, Vulnerability Disclosure Policy und interne Meldekette (bis Ende August 2026)
• Registrierung auf der ENISA Single Reporting Platform und Testlauf des Meldeprozesses (bis 11. September 2026)

Dieser Artikel zeigt, wie die Umsetzung in drei Phasen gelingt und was ein kleines IT-Team realistisch allein leisten kann.

Warum September 2026 zahlt und nicht erst Dezember 2027

Viele SaaS-Anbieter haben den Cyber Resilience Act bisher als Thema für 2027 eingeordnet. Das ist ein teurer Irrtum. Denn der CRA funktioniert nicht als einheitlicher Stichtag, sondern als gestaffelte Pflichtarchitektur. Die erste operative Hürde liegt deutlich früher.

Ab dem 11. September 2026 greift Artikel 14 der Verordnung (EU) 2024/2847: die Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Diese Pflicht gilt unabhängig davon, ob ein Produkt bereits vollständig CRA-konform ist. Sie gilt für alle Hersteller, die unter den Anwendungsbereich des CRA fallen, also auch für SaaS-Anbieter, deren Lösung als Produkt mit digitalen Elementen eingestuft wird.

Die Vollpflicht mit allen technischen Anforderungen (Security-by-Design, CE-Kennzeichnung, Konformitätsbewertung, Lifecycle-Management) folgt erst zum 11. Dezember 2027. Wer bis dahin wartet, um seine Meldeprozesse aufzubauen, steht am 11. September 2026 ohne funktionierenden Incident-Response-Kanal da.

Was bedeutet das konkret? Ein Sicherheitsvorfall, der an einem Montag im Oktober 2026 entdeckt wird, lost innerhalb von 24 Stunden eine Meldepflicht gegenüber dem zustandigen CSIRT (Computer Security Incident Response Team) und der ENISA (EU-Agentur für Cybersicherheit) aus. Innerhalb von 72 Stunden folgt eine detaillierte Folgemeldung, spätestens 14 Tage nach der Erstmeldung ein vollständiger Abschlussbericht. Wer diesen Prozess nicht vorher eingeübt hat, wird die Fristen im Ernstfall nicht halten.

Der Vorlauf bis September 2026 ist kurzer, als er auf den ersten Blick wirkt. Wer heute noch keine Gap-Analyse abgeschlossen hat, kein SBOM vorliegen hat und keine interne Meldekette definiert hat, hat realistisch noch drei bis vier Monate produktive Vorbereitungszeit. Mehr zur Betroffenheitsfrage findet sich in Artikel 1 dieser Serie. Die folgende Roadmap zeigt, was in dieser Zeit aufgebaut werden muss und in welcher Reihenfolge.

Phase 1: Grundlagen schaffen (bis Ende Juni 2026)

Bevor Prozesse aufgebaut werden können, muss die Basis stimmen. Phase 1 ist keine Dokumentationsübung, sondern die Voraussetzung dafür, dass alle späteren Schritte auf einem belastbaren Fundament stehen. Drei Aufgaben stehen im Vordergrund: Scoping, Produktarchitektur-Dokumentation und Risikoklassifizierung.

Schritt 1: Scoping

Der erste Schritt ist eine ehrliche Bestandsaufnahme. Welche Produkte, Module oder Komponenten der eigenen SaaS-Lösung fallen tatsächlich unter den CRA? Relevant ist dabei nicht die interne Produktbezeichnung, sondern die funktionale Einordnung: Kann die Lösung direkt oder indirekt mit einem Gerät oder Netzwerk verbunden werden? Für die meisten SaaS-Anbieter lautet die Antwort ja, aber der Scope ist nicht immer offensichtlich. Zu klären ist auch, ob einzelne Module separat bewertet werden müssen oder ob das Gesamtprodukt als eine Einheit behandelt wird. Einen umfassenden Überblick zum CRA bietet unser CRA-Überblicksartikel.

Schritt 2: Produktarchitektur-Dokumentation

Der CRA verlangt, dass Hersteller ihre Produkte technisch dokumentieren. Für SaaS-Anbieter bedeutet das konkret: eine schriftliche Beschreibung der Produktarchitektur, der eingesetzten Softwarekomponenten (einschließlich Open-Source-Bibliotheken und Drittanbieter-Abhängigkeiten), der Datenschnittstellen und der Update-Mechanismen. Diese Dokumentation ist keine einmalige Aufgabe, sondern muss aktuell gehalten werden.

Praktisch empfiehlt sich ein internes Technical File als zentrales Ablageformat. Es dient später als Grundlage für die Konformitätsbewertung (die formale Prüfung, ob ein Produkt die CRA-Anforderungen erfüllt, entweder durch Selbstbewertung oder durch eine akkreditierte externe Prüfstelle) und als Referenzdokument im Meldefall.

Schritt 3: Risikoklassifizierung

Nicht alle SaaS-Produkte werden unter den CRA gleich behandelt. Die Verordnung unterscheidet zwischen Standardprodukten und wichtigen Produkten (Anhang I, Klasse I und II) sowie kritischen Produkten (Anhang II). Für Standardprodukte ist in vielen Fallen eine Selbstbewertung ausreichend. Für wichtige und kritische Produkte ist eine externe Konformitätsbewertungsstelle einzubeziehen.

Für SaaS-Anbieter im B2B-Umfeld ist die Einordnung nicht immer eindeutig. Produkte, die in sicherheitsrelevante Infrastrukturen integriert sind oder besondere Datenschutzkategorien verarbeiten, können in eine höhere Risikoklasse fallen. Diese Einordnung sollte in Phase 1 verbindlich geklärt werden, weil sie den gesamten weiteren Aufwand bestimmt. Weitergehende Informationen zur Klassifizierung stellt das BSI auf seiner CRA-Seite bereit.

Phase 2: Prozesse aufbauen (bis Ende August 2026)

Mit dem Scoping abgeschlossen und der Produktarchitektur dokumentiert, beginnt die eigentliche operative Arbeit. Phase 2 ist der aufwändigste Teil der Roadmap. Hier werden die drei Kernprozesse aufgebaut, die ab dem 11. September 2026 funktionieren müssen: die SBOM, die Vulnerability Disclosure Policy und die interne Meldekette.

SBOM: Transparenz über die eigene Software-Lieferkette

Eine SBOM (Software Bill of Materials, zu Deutsch: Software-Stuckliste) ist eine strukturierte, maschinenlesbare Aufstellung aller Komponenten, die in einem Softwareprodukt enthalten sind. Dazu gehören eigener Code, Open-Source-Bibliotheken, kommerzielle Drittanbieter-Komponenten und deren jeweilige Versionen sowie bekannte Schwachstellen.

Der CRA macht die SBOM zur Pflicht. Der Grund ist nachvollziehbar: Wer nicht weiß, welche Komponenten in seinem Produkt stecken, kann auch nicht zuverlässig melden, ob eine neu entdeckte Schwachstelle das eigene Produkt betrifft. Die SBOM ist damit keine bürokratische Formalität, sondern die operative Grundlage für jeden Meldeprozess.

Für die Erstellung gibt es etablierte offene Formate, vor allem SPDX und CycloneDX. Beide sind von der ENISA anerkannt. Viele Build-Systeme und CI/CD-Pipelines unterstützen die automatische SBOM-Generierung bereits heute. Aufwändiger ist die Pflege: Die SBOM muss bei jedem Release aktualisiert werden und Drittanbieter-Abhängigkeiten vollständig erfassen, auch transitive Abhängigkeiten, also Bibliotheken, die von anderen Bibliotheken eingebunden werden.

Vulnerability Disclosure Policy: Der formale Eingangskanal für Schwachstellenmeldungen

Eine Vulnerability Disclosure Policy (VDP) regelt, wie externe Meldungen über Sicherheitslücken entgegengenommen, bewertet und bearbeitet werden. Sie ist der offizielle Kanal für Sicherheitsforscher, Kunden und Partner, um Schwachstellen verantwortungsvoll zu melden, ohne direkt an die Öffentlichkeit zu gehen.

Der CRA verlangt von Herstellern, einen solchen Kanal bereitzustellen. Mindestanforderungen für eine CRA-konforme VDP sind: ein öffentlich erreichbarer Meldeweg (typischerweise eine dedizierte E-Mail-Adresse oder ein Webformular), eine klare Beschreibung des Bearbeitungsprozesses, Angaben zu erwarteten Reaktionszeiten und eine Aussage zur koordinierten Offenlegung (Coordinated Vulnerability Disclosure). Letzteres bedeutet: Der Hersteller verpflichtet sich, eine gemeldete Schwachstelle innerhalb eines definierten Zeitraums zu beheben, bevor der Melder sie veröffentlicht.

Eine VDP muss kein umfangreiches Dokument sein. Ein strukturierter, klarer Text auf einer öffentlich zuganglichen Unterseite der eigenen Website ist ausreichend. Wichtig ist, dass der Prozess dahinter tatsachlich funktioniert und dass die Verantwortlichkeiten intern geklärt sind.

Interne Meldekette: Wer erkennt, wer entscheidet, wer meldet

Die 24-Stunden-Frist für die Erstmeldung ist das operativ anspruchsvollste Element des CRA. Sie setzt voraus, dass innerhalb eines Unternehmens in sehr kurzer Zeit drei Dinge passieren: die Schwachstelle oder der Vorfall wird erkannt und als meldepflichtig eingestuft, eine Entscheidung über die Meldung wird getroffen und die Meldung wird über die ENISA Single Reporting Platform (SRP) abgesetzt.

Das funktioniert nur, wenn die Kette vorher definiert ist. Konkret heißt das: Es muss eine benannte Person oder Rolle geben, die rund um die Uhr erreichbar ist und im Ernstfall die Meldung auslösen kann. Es braucht einen internen Eskalationspfad mit klaren Schwellenwerten, ab wann ein Vorfall als meldepflichtig gilt. Und es sollten vorbereitete Meldetexte und Checklisten vorliegen, damit im Stressfall keine Zeit mit Formulierungsfragen verloren geht.

Für kleinere SaaS-Anbieter bedeutet das in der Praxis oft: eine Doppelfunktion im IT-Security-Team mit expliziter CRA-Verantwortung, eine Eskalationsliste bis auf Geschäftsführungsebene und ein einseitiges Runbook, das den Meldeprozess Schritt für Schritt beschreibt.

Phase 3: Meldeprozess aktivieren (bis 11. September 2026)

Phase 3 ist keine Aufbauphase mehr, sondern eine Aktivierungsphase. Die Prozesse aus Phase 2 sind definiert, die SBOM liegt vor, die VDP ist veröffentlicht. Jetzt geht es darum, den Meldeprozess technisch anzubinden, die zuständigen Behörden zu kennen und den Ernstfall einmal durchzuspielen, bevor er eintritt.

ENISA Single Reporting Platform: Registrierung und technische Anbindung

Die ENISA (Agentur der Europaischen Union für Cybersicherheit) betreibt die zentrale Meldeplattform für den CRA, die sogenannte Single Reporting Platform (SRP). Uber diese Plattform laufen alle Meldungen zu aktiv ausgenutzten Schwachstellen und schwerwiegenden Sicherheitsvorfällen. Eine direkte Kommunikation mit nationalen Behörden ersetzt die SRP nicht, sie ergänzt sie.

Für SaaS-Anbieter bedeutet das: Die SRP muss vor dem 11. September 2026 bekannt und zugänglich sein. Das klingt trivial, ist es aber nicht. Wer die Plattform zum ersten Mal unter Zeitdruck aufruft, einen Account anlegt und gleichzeitig eine 24-Stunden-Frist lauft, verliert wertvolle Zeit mit technischen und organisatorischen Grundfragen. Die Registrierung und die Einarbeitung in das Meldeformular gehoren deshalb in Phase 3, nicht in den Ernstfall.

BSI als nationales CSIRT: Rolle im Meldeprozess verstehen

In Deutschland ist das Bundesamt für Sicherheit in der Informationstechnik (BSI) das zuständige nationale CSIRT im Sinne des CRA. Das BSI nimmt Meldungen entgegen, koordiniert die Weitergabe an die ENISA und kann im Bedarfsfall unterstützend tätig werden.

Wichtig zu verstehen: Die Meldepflicht nach CRA richtet sich primär an die ENISA über die SRP. Das BSI ist als nationales CSIRT in diesen Prozess eingebunden, ersetzt aber die ENISA-Meldung nicht. SaaS-Anbieter sollten die BSI-Seite zum CRA kennen und prüfen, ob für ihr Produkt zusätzliche nationale Meldewege relevant sind, etwa wenn gleichzeitig NIS2-Pflichten bestehen.

Testlauf: Den Meldeprozess einmal durchspielen

Der wichtigste Schritt in Phase 3 ist gleichzeitig der am häufigsten übersprungene: ein Trockenlauf des gesamten Meldeprozesses vor dem Stichtag. Gemeint ist eine realistische Simulation, bei der ein fiktiver Schwachstellenfund den internen Eskalationspfad durchläuft, die zuständige Person die ENISA-Plattform aufruft, das Meldeformular ausfüllt (ohne es abzusenden) und die Zeituhr dabei läuft.

Dieser Testlauf deckt Lücken auf, die in der Theorie unsichtbar bleiben. Typische Probleme: Die benannte Ansprechperson ist im Urlaub und es gibt keine Vertretungsregelung. Das Runbook beschreibt den Prozess, aber nicht, wo die SBOM gespeichert ist. Das Meldeformular fragt nach Produktkennungen, die intern nicht in diesem Format vorliegen. Jedes dieser Probleme ist im Testlauf ein Lerneffekt. Im Ernstfall kostet es Stunden.

Die Meldefristen im Überblick

Frist	Inhalt
24 Stunden	Erstmeldung (Early Warning) nach Kenntniserlangung
72 Stunden	Folgemeldung mit technischen Details
14 Tage	Abschlussbericht nach Verfügbarkeit einer Abhilfemaßnahme

Was ein kleines IT-Team allein schafft und wo externe Unterstützung sinnvoll ist

Die Roadmap bis September 2026 ist machbar. Aber sie ist nicht für jedes Team gleich machbar. Ein SaaS-Anbieter mit einem dedizierten Security-Team und etablierten DevSecOps-Prozessen steht vor anderen Herausforderungen als ein Unternehmen mit drei Entwicklern und einem IT-Generalisten. Dieser Abschnitt gibt beiden Seiten eine realistische Einschätzung.

Für CTOs und IT-Security Manager: Was intern gut funktioniert

Wer bereits mit modernen Entwicklungspraktiken arbeitet, hat einen erheblichen Vorsprung. Folgende Aufgaben sind mit internen Ressourcen gut lösbar:

SBOM-Erstellung und Pflege: Die meisten modernen CI/CD-Umgebungen unterstützen die automatische Generierung von SBOMs über etablierte Tools wie Syft, CycloneDX CLI oder integrierte Funktionen in GitHub Advanced Security und GitLab. Der initiale Aufwand für die Einrichtung ist überschaubar. Aufwändiger ist die Disziplin, die SBOM bei jedem Release aktuell zu halten und transitive Abhängigkeiten konsequent zu erfassen.

Vulnerability Disclosure Policy: Eine solide VDP ist kein Rechtsdokument, das externe Anwalte erfordert. Mit einem guten Template und einer klaren internen Abstimmung lässt sich eine CRA-konforme VDP in wenigen Tagen erstellen und veröffentlichen. Wichtig ist, dass der Prozess dahinter organisatorisch verankert ist, nicht nur das Dokument.

Internes Runbook und Meldekette: Die Definition des Eskalationspfads, die Benennung von Verantwortlichen und die Erstellung vorbereiteter Meldetexte sind klassische IT-Security-Aufgaben. Ein erfahrenes IT-Security-Team kann diese Arbeit intern leisten, vorausgesetzt, es hat die Kapazität dafür.

Testlauf: Die Simulation des Meldeprozesses erfordert keine externe Begleitung. Sie erfordert Disziplin und einen festen Termin im Kalender.

Für CEOs und CFOs: Wo externe Begleitung den Unterschied macht

Aus der Entscheiderperspektive ist die zentrale Frage nicht, was technisch möglich ist, sondern wo das Risiko einer Fehleinschätzung am größten ist. Drei Bereiche stechen heraus.

Risikoklassifizierung: Die Einordnung eines Produkts in die CRA-Kategorien hat direkte Konsequenzen für den gesamten Compliance-Aufwand. Eine falsche Selbsteinschätzung bedeutet entweder unnötigen Mehraufwand oder, schlimmer, eine unerkannte Pflicht zur externen Konformitätsbewertung. Diese Einordnung ist eine rechtlich-technische Abwägung, bei der externe Expertise den Prozess absichert.

Konformitätsbewertung für höhere Risikoklassen: Wer sein Produkt korrekt als wichtiges Produkt nach Anhang I eingestuft hat, benötigt für die spätere Vollpflicht (Dezember 2027) eine akkreditierte Konformitätsbewertungsstelle. Diese Stellen sind bereits heute knapp und arbeiten mit Vorlaufzeiten. Wer jetzt Kontakt aufnimmt, sichert sich einen Platz im Prozess.

Erstmeldung im Ernstfall: Die erste CRA-Meldung an die ENISA ist kein Routinevorgang. Sie hat rechtliche Relevanz, sie dokumentiert den Kenntniszeitpunkt und sie setzt Fristen in Gang. Unternehmen ohne Erfahrung mit behördlicher Kommunikation in Sicherheitsvorfällen profitieren davon, diesen Schritt mit externer Begleitung vorbereitet zu haben.

Gesamtbild für die Geschäftsführung: CRA-Compliance ist kein reines IT-Projekt. Es berührt Produktstrategie, Lieferantenbeziehungen, Versicherungsschutz und Kundenkommunikation. Die Entscheidung, wie viel intern geleistet wird und wo externe Unterstützung hinzugezogen wird, ist eine unternehmerische Abwägung, keine technische.
[/av_textblock]

[/av_one_full]

Glossar: Wichtige Begriffe im Überblick

Begriff	Erklarung
SBOM (Software Bill of Materials)	Strukturierte, maschinenlesbare Aufstellung aller Softwarekomponenten eines Produkts, einschließlich Open-Source-Bibliotheken, Drittanbieter-Abhängigkeiten und deren bekannter Schwachstellen.
Vulnerability Disclosure Policy (VDP)	Offizielle Richtlinie eines Herstellers, die regelt, wie externe Meldungen über Sicherheitslücken entgegengenommen, bewertet und bearbeitet werden.
ENISA	Agentur der Europäischen Union für Cybersicherheit. Betreibt die zentrale Meldeplattform (SRP) für CRA-Meldungen und koordiniert den europaweiten Informationsaustausch zu Sicherheitsvorfällen.
CSIRT (Computer Security Incident Response Team)	Spezialisiertes Team zur Reaktion auf Sicherheitsvorfälle. In Deutschland nimmt das BSI diese Rolle als nationales CSIRT im Sinne des CRA wahr.
Single Reporting Platform (SRP)	Zentrale ENISA-Meldeplattform, über die Hersteller CRA-pflichtige Schwachstellen und Sicherheitsvorfälle fristgerecht melden.
Konformitätsbewertung	Formale Prüfung, ob ein Produkt die CRA-Anforderungen erfüllt. Je nach Risikoklasse als Selbstbewertung oder durch eine akkreditierte externe Prüfstelle durchzuführen.
CE-Kennzeichnung	Europäisches Konformitätskennzeichen. Unter dem CRA dürfen Produkte mit digitalen Elementen ab Dezember 2027 nur noch mit CE-Kennzeichnung in der EU in Verkehr gebracht werden.
Coordinated Vulnerability Disclosure	Vereinbartes Verfahren, bei dem ein Sicherheitsforscher eine entdeckte Schwachstelle zunächst vertraulich an den Hersteller meldet und erst nach einer definierten Frist veröffentlicht.
DevSecOps	Entwicklungsansatz, der Sicherheitsprozesse von Anfang an in den Softwareentwicklungszyklus integriert, anstatt sie nachträglich hinzuzufügen.
Security-by-Design	Prinzip, nach dem Sicherheitsanforderungen bereits in der Produktkonzeption und Architektur verankert werden, nicht erst im Nachgang.
SPDX / CycloneDX	Offene, standardisierte Formate zur Erstellung und Weitergabe von SBOMs. Beide sind von der ENISA anerkannt und werden von gängigen Entwicklungsumgebungen unterstützt.