Cyber Resilience Act: Was für Hersteller und Softwareanbieter jetzt gilt — und was bis Ende 2027 ansteht

Jahrelang war IT-Sicherheit in Produkten vor allem eine Marketingfrage: Wer wollte, warb damit — wer nicht, ließ es bleiben. Mit dem Cyber Resilience Act (CRA) dreht die EU dieses Prinzip um. Die Verordnung (EU) 2024/2847 ist seit Dezember 2024 in Kraft und macht Cybersicherheit zur Marktzugangsvoraussetzung: Produkte mit digitalen Elementen dürfen künftig nur noch mit CE-Kennzeichnung auf den EU-Markt, wenn sie definierte Sicherheitsanforderungen erfüllen. Das betrifft nicht nur Konzerne, sondern jeden, der Software oder vernetzte Hardware kommerziell anbietet — vom IoT-Hersteller bis zur kleinen Softwareschmiede.

Wen der CRA trifft

Der Anwendungsbereich ist bewusst breit gefasst: Produkte mit digitalen Elementen, also Hardware und Software, die direkt oder indirekt mit einem Netzwerk verbunden werden können. Darunter fallen:

• Software-Produkte — Standardsoftware, Apps, Betriebssysteme, aber auch kommerzielle Software-Bibliotheken und Komponenten
• Vernetzte Hardware — vom smarten Thermostat über Industriesteuerungen bis zum Router
• Fernverarbeitungslösungen, soweit sie für die Funktion des Produkts erforderlich sind

Wichtige Ausnahmen: Reine SaaS-Angebote ohne Produktbezug fallen grundsätzlich unter NIS-2 statt unter den CRA. Auch Open-Source-Software, die außerhalb einer kommerziellen Tätigkeit entwickelt und bereitgestellt wird, ist ausgenommen — sobald aber ein Unternehmen Open Source kommerziell monetarisiert, greift die Verordnung wieder. Für Medizinprodukte, Fahrzeuge und Luftfahrt gelten die jeweiligen Sektorregelungen.

Betroffen sind in erster Linie Hersteller, daneben aber auch Importeure und Händler mit eigenen Prüfpflichten. Wer Produkte unter eigener Marke vertreibt oder wesentlich verändert, gilt selbst als Hersteller — ein Punkt, den viele Reseller und Systemhäuser unterschätzen.

Die Kernpflichten im Überblick

Der CRA verlangt von Herstellern im Wesentlichen vier Dinge:

1. Security by Design und by Default. Produkte müssen ohne bekannte ausnutzbare Schwachstellen ausgeliefert werden, mit sicherer Standardkonfiguration, Zugriffsschutz und Verschlüsselung, wo angemessen. Die Sicherheitsanforderungen aus Anhang I sind Pflichtenheft für die Produktentwicklung — nicht Kür.

2. Schwachstellenmanagement über den Lebenszyklus. Hersteller müssen Schwachstellen systematisch erfassen, bewerten und beheben — inklusive einer SBOM (Software Bill of Materials) für die wichtigsten Abhängigkeiten, einer Kontaktstelle für Schwachstellenmeldungen (Coordinated Vulnerability Disclosure) und kostenloser Sicherheitsupdates über den Supportzeitraum. Der beträgt grundsätzlich mindestens fünf Jahre.

3. Meldepflichten. Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen binnen 24 Stunden (Frühwarnung) an die ENISA und die zuständige nationale Behörde gemeldet werden, gefolgt von einer detaillierteren Meldung nach 72 Stunden und einem Abschlussbericht. Wer NIS-2-Meldeprozesse bereits aufgebaut hat, kann hier viel wiederverwenden.

4. Konformitätsbewertung und technische Dokumentation. Für die meisten Produkte reicht die Selbstbewertung des Herstellers. „Wichtige” Produkte (etwa Passwortmanager, Firewalls, Betriebssysteme) und „kritische” Produkte (etwa Smart-Meter-Gateways, Hardware-Sicherheitsmodule) unterliegen strengeren Verfahren, teils mit Beteiligung benannter Stellen.

Die Fristen: Warum jetzt der richtige Zeitpunkt ist

Die Verordnung wirkt gestaffelt: Die Meldepflichten gelten seit dem 11. September 2026. Die vollständigen Produktanforderungen greifen ab dem 11. Dezember 2027. Das klingt nach viel Zeit, ist es aber nicht: Wer heute ein Produkt entwickelt, das 2028 noch verkauft werden soll, entwickelt bereits für die CRA-Welt. Entwicklungszyklen, Lieferantenverträge und Support-Zusagen reichen fast immer über den Stichtag hinaus.

Die Sanktionen orientieren sich an der DSGVO-Logik: bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes bei Verstößen gegen die grundlegenden Anforderungen. Schwerer wiegt in der Praxis oft die Marktfolge — ohne Konformität keine CE-Kennzeichnung, ohne CE-Kennzeichnung kein Verkauf im EU-Binnenmarkt.

Womit man sinnvoll anfängt

Aus unserer Projektpraxis hat sich eine schlichte Reihenfolge bewährt:

1. Produktinventur. Welche Produkte mit digitalen Elementen bringen wir in Verkehr? Welche sind „wichtig” oder „kritisch” im Sinne der Anhänge? Schon diese Einordnung entscheidet über das Konformitätsverfahren.
2. SBOM-Fähigkeit herstellen. Wer seine Abhängigkeiten nicht kennt, kann weder Schwachstellen bewerten noch Meldepflichten erfüllen. Moderne Build-Pipelines erzeugen SBOMs weitgehend automatisch — das ist der günstigste Einstiegspunkt.
3. Schwachstellenprozess aufsetzen. Eine erreichbare Meldestelle, definierte Bewertungs- und Patchwege, dokumentierte Supportzeiträume. Wer bereits ein ISMS nach ISO 27001 betreibt, dockt den Prozess dort an, statt Parallelstrukturen zu bauen.
4. Entwicklungsprozess anpassen. Threat Modeling, Security-Reviews und Update-Mechanismen gehören in den Entwicklungsalltag, nicht in ein nachgelagertes Audit. Das ist der Teil, der am längsten dauert — deshalb zuerst planen.
5. Lieferkette prüfen. Zugekaufte Komponenten und eingebettete Bibliotheken bleiben in der Verantwortung des Herstellers. Verträge mit Zulieferern sollten Update- und Informationspflichten regeln.

CRA, NIS-2 und ISO 27001: drei Regelwerke, ein System

Der häufigste Fehler ist, jede Regulierung isoliert abzuarbeiten. Dabei überlappen sich die Anforderungen erheblich: NIS-2 adressiert die Sicherheit der eigenen Organisation, der CRA die Sicherheit der Produkte, ISO 27001 liefert das Managementsystem, das beides trägt. Ein sauber aufgesetztes ISMS mit Schwachstellen- und Incident-Prozessen erfüllt bereits einen großen Teil der CRA-Pflichten — es muss nur um die Produktperspektive erweitert werden. Fristen, Meldewege und Umsetzungsschritte im Detail zeigt unser Partnerportal in der Übersicht zum Cyber Resilience Act.

Für Softwareentwickler heißt das konkret: Der CRA ist keine reine Compliance-Übung, sondern verändert, wie Produkte gebaut werden. Wer Individualsoftware entwickelt oder entwickeln lässt, sollte die Anforderungen schon heute in Pflichtenhefte und Verträge schreiben — nachträgliche Security-Sanierung ist immer teurer als eingebaute Sicherheit.

Fazit

Der Cyber Resilience Act macht aus „Security by Design” eine Rechtspflicht mit CE-Relevanz. Die Meldepflichten gelten seit September 2026, die Produktanforderungen folgen Ende 2027 — wer jetzt mit Produktinventur, SBOM und Schwachstellenprozess beginnt, verteilt den Aufwand auf ein gutes Jahr statt auf zwei Quartale. Und profitiert nebenbei: Die meisten CRA-Maßnahmen sind schlicht gutes Software-Engineering, das auch ohne Verordnung Ausfälle, Sicherheitsvorfälle und Reputationsschäden verhindert.