Cyber Resilience Act: Pflichten, Fristen und Umsetzung für KMU

1. Einleitung

Der Cyber Resilience Act, kurz CRA, verbindet die Sicherheit digitaler Produkte mit ihrem Zugang zum europäischen Markt. Wer Software, vernetzte Geräte oder digitale Komponenten entwickelt, importiert oder vertreibt, sollte deshalb nicht nur einzelne Sicherheitsfunktionen betrachten. Entscheidend ist ein nachvollziehbarer Prozess von der Produktentwicklung bis zum Ende des Unterstützungszeitraums.

Das zeigt ein einfaches Szenario: Eine Maschinensteuerung arbeitet seit mehreren Jahren beim Kunden, als eine Schwachstelle in einer eingebauten Softwarebibliothek bekannt wird. Jetzt muss der Hersteller erkennen können, welche Produktversionen betroffen sind, wer die Bewertung übernimmt und wie eine Sicherheitsaktualisierung bereitgestellt wird. Genau solche Abläufe rücken durch den CRA in den Mittelpunkt.

Stand: 23. September 2026. Die Meldepflichten für Hersteller nach Artikel 14 gelten bereits seit dem 11. September 2026. Die wesentlichen weiteren Produkt- und Prozessanforderungen gelten ab dem 11. Dezember 2027. Wer seine Vorbereitung ausschließlich auf Ende 2027 ausrichtet, übersieht damit bereits geltende Verpflichtungen.

Dieser Beitrag bietet eine allgemeine Orientierung für Unternehmen und ersetzt keine rechtliche Prüfung des konkreten Produkts oder Geschäftsmodells.

2. Kurzantwort

Der Cyber Resilience Act verpflichtet Hersteller erfasster Produkte mit digitalen Elementen zu sicherer Entwicklung, dokumentierter Risikobewertung und geregeltem Schwachstellenmanagement. Auch Importeure und Händler haben eigene Pflichten, während der konkrete Umfang von Produkt, Unternehmensrolle und möglichen Ausnahmen abhängt. Hersteller müssen die bereits geltenden Meldepflichten berücksichtigen und ihre Produkte sowie Prozesse auf die wesentlichen weiteren Anforderungen ab dem 11. Dezember 2027 vorbereiten.

3. Warum das wichtig ist

Cyber Resilience Act: Welche Unternehmen betroffen sein können

Der CRA betrachtet die Sicherheit von Produkten mit digitalen Elementen. Dazu können Hardware und Software gehören, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz einschließt. Eine unmittelbare Internetverbindung ist dafür nicht zwingend erforderlich.

Betroffen sein können beispielsweise Hersteller vernetzter Maschinensteuerungen, IoT-Geräte und Smart-Home-Produkte sowie Anbieter kommerzieller Software und mobiler Anwendungen. Eine allgemeine Ausnahme allein aufgrund geringer Unternehmensgröße gibt es nicht.

Hersteller, Importeure und Händler müssen ihre Rollen unterscheiden: Hersteller verantworten insbesondere die produktspezifischen Sicherheits- und Entwicklungsprozesse. Importeure und Händler haben eigene Prüf- und Mitwirkungspflichten. Wer ein Produkt unter eigenem Namen oder eigener Marke in Verkehr bringt oder wesentlich verändert, kann selbst Herstellerpflichten übernehmen.

Für bestimmte anderweitig regulierte Produkte bestehen Ausnahmen, beispielsweise für Medizinprodukte und In-vitro-Diagnostika unter den einschlägigen EU-Verordnungen. Auch freie und quelloffene Software außerhalb einer gewerblichen Tätigkeit ist gesondert zu betrachten. Der Einsatz von Open-Source-Komponenten in einem kommerziellen Produkt befreit dessen Hersteller jedoch nicht pauschal von seinen Pflichten.

Die fünf zentralen CRA-Anforderungen

1. Secure by Design und Secure by Default: Sicherheit muss bereits in die Konzeption und Entwicklung einfließen. Dazu gehören risikogerechte Schutzmaßnahmen, sichere Voreinstellungen, begrenzte Angriffsflächen und geeignete Zugriffsmechanismen. Sicherheitsfragen sollten deshalb Teil der Entwicklungsfreigabe sein und nicht erst kurz vor der Auslieferung auftauchen.
2. Risikobewertung und technische Dokumentation: Hersteller müssen die Cybersicherheitsrisiken ihrer Produkte bewerten und die Umsetzung der Anforderungen nachvollziehbar dokumentieren. Die technische Dokumentation richtet sich nach Anhang VII. Sie ist zusammen mit der EU-Konformitätserklärung mindestens zehn Jahre nach dem Inverkehrbringen oder für den längeren Unterstützungszeitraum verfügbar zu halten.
3. Software-Stückliste: Eine Software Bill of Materials, kurz SBOM, dokumentiert enthaltene Softwarekomponenten und ihre Beziehungen. Der CRA verlangt ein gebräuchliches, maschinenlesbares Format, das mindestens die direkten Abhängigkeiten des Produkts abdeckt. Die Stückliste sollte eindeutig einer Produktversion zugeordnet werden können.
4. Schwachstellenmanagement und Meldungen: Hersteller benötigen einen geregelten Ablauf für die Annahme, Bewertung und Behandlung von Sicherheitslücken. Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Produktsicherheit können Meldepflichten auslösen. Nicht jede entdeckte Schwachstelle ist automatisch ein meldepflichtiger Fall.
5. Unterstützungszeitraum und Sicherheitsupdates: Hersteller müssen festlegen, wie lange sie Schwachstellen behandeln. Der Zeitraum orientiert sich an der erwarteten Nutzung und beträgt grundsätzlich mindestens fünf Jahre; bei kürzer erwarteter Nutzung kann er entsprechend kürzer sein, bei langlebigen Produkten länger. Sicherheitsupdates sind grundsätzlich kostenlos bereitzustellen, wobei eng begrenzte vertragliche Ausnahmen für bestimmte Geschäftskundenprodukte bestehen.

Die EU-Kommission erläutert die Herstellerpflichten entlang der Phasen vor, beim und nach dem Inverkehrbringen. Die konkreten Anforderungen ergeben sich aus der Verordnung (EU) 2024/2847.

Meldepflichten: Welche Fristen bereits relevant sind

Für meldepflichtige aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle sind eine Frühwarnung spätestens innerhalb von 24 Stunden und eine Folgemeldung spätestens innerhalb von 72 Stunden nach Kenntniserlangung erforderlich. Die Meldung darf nicht unnötig verzögert werden.

Beim Abschlussbericht unterscheiden sich die Abläufe: Für aktiv ausgenutzte Schwachstellen gilt spätestens 14 Tage nach Verfügbarkeit einer Abhilfemaßnahme. Bei schwerwiegenden Sicherheitsvorfällen ist der Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung einzureichen.

Die Meldungen erfolgen über die Single Reporting Platform der ENISA an die zuständigen Stellen. Unternehmen sollten deshalb Zugänge, Vertretungsregelungen und interne Freigaben vorbereiten, bevor ein Vorfall eintritt. Einzelheiten erläutert die EU-Kommission zu den CRA-Meldepflichten.

Fristen, Konformitätsbewertung und Marktzugang

Für die Planung sind drei Termine zu unterscheiden: Seit dem 11. Juni 2026 gelten die Vorschriften zur Notifizierung von Konformitätsbewertungsstellen. Seit dem 11. September 2026 gelten die Hersteller-Meldepflichten nach Artikel 14. Ab dem 11. Dezember 2027 greifen die wesentlichen weiteren CRA-Anforderungen.

Die Aussage, ab Dezember 2027 dürften sämtliche älteren Produkte nicht mehr verkauft werden, wäre zu pauschal. Für bereits zuvor in Verkehr gebrachte Produkte bestehen Übergangsregelungen; insbesondere wesentliche Änderungen können eine neue Bewertung erforderlich machen. Die Meldepflichten können auch solche Bestandsprodukte erfassen.

Auch die Konformitätsbewertung ist nicht für jedes Produkt gleich. Bei Produkten der Standardkategorie ist eine interne Bewertung möglich. Für wichtige Produkte der Klasse I gelten zusätzliche Bedingungen; bei Klasse II und kritischen Produkten sind grundsätzlich strengere Verfahren vorgesehen. Betriebssysteme und Router sind dabei nicht pauschal der Klasse II zuzuordnen.

Eine vorhandene CE-Kennzeichnung aufgrund anderer Vorschriften ersetzt die CRA-Prüfung nicht. Welche Nachweise und gegebenenfalls welche externe Bewertung erforderlich sind, sollte anhand der konkreten Produktkategorie geprüft werden. Orientierung bietet die EU-Kommission zur CRA-Konformitätsbewertung.

Bei bestimmten Verstößen sieht der CRA Bußgeldobergrenzen von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres vor, je nachdem, welcher Betrag höher ist. Die konkrete Einordnung und besondere Ausnahmen hängen vom Verstoß und vom Unternehmen ab. Daneben können marktaufsichtliche Maßnahmen relevant werden.

Für die betriebliche Planung bedeutet das: Entwicklungsaufwand, Sicherheitsupdates, Lieferantenabhängigkeiten und Nachweise müssen gemeinsam betrachtet werden. Wer diese Aufgaben erst vor einer Produkteinführung zusammenführt, riskiert zusätzliche Abstimmungen, technische Nacharbeiten und verschobene Freigaben.

4. Schritt für Schritt

1. Produktportfolio und Unternehmensrolle erfassen: Legen Sie für jedes relevante Produkt ein Datenblatt mit Version, Funktion, Vertriebsmarkt, Datenverbindungen und Verantwortlichen an. Halten Sie fest, ob Ihr Unternehmen Hersteller, Importeur oder Händler ist und ob Eigenmarken oder wesentliche Änderungen eine zusätzliche Prüfung erfordern.
2. Bereits geltende Meldeprozesse absichern: Benennen Sie Verantwortliche und Vertretungen für die Bewertung von Produktsicherheitsvorfällen. Prüfen Sie den Zugang zur Meldeplattform und definieren Sie, wer Informationen zusammenträgt, Meldungen freigibt und Fristen überwacht.
3. Lückenanalyse durchführen: Vergleichen Sie bestehende Entwicklungs-, Test-, Support- und Dokumentationsprozesse mit den Anforderungen des CRA. Ordnen Sie jeder Lücke eine verantwortliche Person, eine Maßnahme und einen Zieltermin zu.
4. SBOM-Prozess in die Entwicklung integrieren: Erstellen Sie für jede freigegebene Produktversion eine zugehörige Komponentenübersicht. Prüfen Sie deren Vollständigkeit und Verwendbarkeit, statt lediglich eine Datei zu erzeugen. Berücksichtigen Sie auch Informationen zu eingebundenen Lieferantenkomponenten.
5. Sicherheitsanforderungen in Produktfreigaben aufnehmen: Legen Sie fest, welche Risiken bewertet, welche Tests durchgeführt und welche Ergebnisse dokumentiert werden müssen. Änderungen an Schnittstellen, Berechtigungen oder eingebundenen Bibliotheken sollten eine erneute Sicherheitsprüfung auslösen können.
6. Support und Lieferantenabhängigkeiten planen: Dokumentieren Sie den begründeten Unterstützungszeitraum und den vorgesehenen Updateweg. Klären Sie, wie lange eingesetzte Komponenten gepflegt werden und wie Sie reagieren, wenn ein Zulieferer Sicherheitsupdates einstellt.
7. Technische Unterlagen und Bewertungsverfahren vorbereiten: Führen Sie Produktbeschreibung, Risikobewertung, Sicherheitskonzept, Testnachweise und Schwachstellenprozesse zusammen. Lassen Sie die Produktkategorie und das geeignete Konformitätsbewertungsverfahren fachlich prüfen.
8. Abläufe praktisch erproben: Simulieren Sie eine Schwachstelle in einer verwendeten Softwarekomponente. Prüfen Sie, ob betroffene Versionen ermittelt, Zuständigkeiten erreicht, Meldungen vorbereitet und Kundeninformationen erstellt werden können. Überführen Sie erkannte Probleme in den Maßnahmenplan.

Bestehende Strukturen aus Informationssicherheitsmanagement, Patch-Management und Lieferantensteuerung können dabei helfen. Sie ersetzen jedoch nicht die produktspezifische Bewertung und Dokumentation.

5. Checkliste

• Sind alle möglicherweise erfassten Produkte und Produktversionen dokumentiert?
• Ist Ihre Rolle als Hersteller, Importeur oder Händler je Produkt geklärt?
• Sind mögliche Ausnahmen und besondere Produktkategorien fachlich geprüft?
• Liegt eine nachvollziehbare produktspezifische Cybersicherheits-Risikobewertung vor?
• Sind sichere Voreinstellungen und Sicherheitsprüfungen in der Entwicklung verankert?
• Kann jeder freigegebenen Produktversion eine passende SBOM zugeordnet werden?
• Sind Annahme, Bewertung und Bearbeitung von Schwachstellen organisatorisch geregelt?
• Sind Meldezugänge, Fristen, Zuständigkeiten und Vertretungen einsatzbereit?
• Sind Unterstützungszeitraum, Sicherheitsupdates und Lieferantenabhängigkeiten geplant?
• Sind technische Dokumentation, Konformitätsbewertung und Nachweispflege verbindlich zugeordnet?

6. Häufige Fehler

• „Wir haben bis Ende 2027 Zeit“: Korrektur: Trennen Sie die wesentlichen weiteren Produktanforderungen von den bereits seit September 2026 geltenden Hersteller-Meldepflichten.
• „Als kleines Unternehmen sind wir ausgenommen“: Korrektur: Prüfen Sie Produkt und Unternehmensrolle. Die geringe Unternehmensgröße allein schafft keine allgemeine Befreiung.
• „Unser Zulieferer kümmert sich um alle Sicherheitslücken“: Korrektur: Klären Sie eigene Verantwortlichkeiten, Informationswege und Abhängigkeiten. Zugekaufte Komponenten müssen in die Betrachtung des eigenen Produkts einfließen.
• „Eine einmal erstellte SBOM reicht“: Korrektur: Ordnen Sie Komponentenübersichten konkreten Versionen zu und aktualisieren Sie sie bei Änderungen. Eine veraltete Liste hilft bei einem aktuellen Sicherheitsvorfall nur begrenzt.
• „Fünf Jahre Support sind immer ausreichend“: Korrektur: Begründen Sie den Unterstützungszeitraum anhand der erwarteten Nutzung. Gerade langlebige Produkte können längere Zeiträume erfordern.
• „CE oder ISO 27001 erledigen den CRA automatisch“: Korrektur: Prüfen Sie die produktspezifischen Sicherheitsanforderungen und das zulässige Bewertungsverfahren gesondert. Vorhandene Nachweise können unterstützen, ersetzen aber nicht die notwendige Einordnung.

7. Praxisbeispiel

Fiktives Beispiel: Ein mittelständischer Maschinenbauer vertreibt vernetzte Steuerungen unter eigener Marke. Die Geräte enthalten zugekaufte Softwarekomponenten, deren Versionsstände bisher in unterschiedlichen Entwicklungsunterlagen stehen. Bei einer Übung zu einer gemeldeten Bibliotheksschwachstelle kann das Team deshalb nicht sofort feststellen, welche ausgelieferten Steuerungen betroffen wären. Das Unternehmen ordnet zunächst jede Produktversion einer geprüften Komponentenübersicht zu. Anschließend legt es Verantwortliche für die technische Bewertung, mögliche Meldungen und die Kundenkommunikation fest. Parallel werden Unterstützungszeiträume und Updatezusagen mit den wichtigsten Zulieferern abgeglichen. Eine weitere Übung prüft den gesamten Ablauf vom Eingang einer Schwachstellenmeldung bis zur Vorbereitung eines Sicherheitsupdates. Das Ergebnis ist ein dokumentierter Arbeitsprozess mit erkennbaren Restaufgaben, nicht automatisch eine bestätigte CRA-Konformität.

9. Fazit

Der Cyber Resilience Act verlangt, Produktsicherheit, Softwarekomponenten, Schwachstellenbearbeitung und Support als zusammenhängenden Prozess zu organisieren. Eine strukturierte Bestandsaufnahme zeigt, welche Produkte betroffen sein können, welche Meldeabläufe bereits funktionieren müssen und welche Nachweise bis zur Anwendung der weiteren Anforderungen vorbereitet werden sollten.

Planen Sie Ihre CRA-Bestandsaufnahme mit optimIT und schreiben Sie an info@optimit.de.