Cyber Resilience Act: Wer ist betroffen und was gilt seit dem 11. September 2026?
Seit dem 11. September 2026 ist der Cyber Resilience Act keine Zukunftsmusik mehr. Die ersten Meldepflichten der EU-Verordnung greifen bereits. Viele Unternehmen, die Software oder vernetzte Geräte verkaufen, wissen aber noch nicht, ob sie überhaupt betroffen sind. Das gilt besonders für Unternehmen mit selbst entwickelter oder langjährig gewachsener Software, die leicht übersehen, dass auch sie unter die neue Verordnung fallen. Wer fällt unter den Cyber Resilience Act, was gilt bereits jetzt, und was kommt ab Dezember 2027 noch dazu?
Falls Sie Software entwickeln, vertreiben oder in Ihrem Unternehmen vernetzte Systeme betreiben, betrifft Sie die Antwort wahrscheinlich mehr, als Sie denken.
Was ist der Cyber Resilience Act überhaupt?
Der Cyber Resilience Act (CRA) ist die EU-Verordnung 2024/2847. Sie legt Mindeststandards für die Cybersicherheit von Produkten mit digitalen Elementen fest. Das klingt abstrakt, ist es aber nicht. Der Gesetzgeber reagiert damit auf eine Entwicklung, die längst Realität ist: Fast jedes Produkt, vom Türschloss bis zur Buchhaltungssoftware, ist heute vernetzt oder enthält Software, über die sich Angreifer Zugang verschaffen können.
Gemeint sind zwei Kategorien: vernetzte Hardware, etwa IoT-Geräte, Sensoren oder Maschinensteuerungen, und reine Software, die ein Unternehmen geschäftlich anbietet.
Entscheidend ist nicht die Größe des Unternehmens. Entscheidend ist, ob ein Produkt mit digitalen Elementen auf dem EU-Markt bereitgestellt wird. Ein Softwarehaus mit zehn Mitarbeitern fällt genauso unter den CRA wie ein internationaler Hardware-Hersteller.
Wer ist vom Cyber Resilience Act betroffen?
Das Gesetz unterscheidet drei Rollen. Hersteller entwickeln ein Produkt oder lassen es entwickeln und bringen es unter ihrem eigenen Namen auf den Markt. Importeure bringen Produkte aus Nicht-EU-Ländern in die EU. Händler vertreiben Produkte, die andere hergestellt haben, und müssen prüfen, ob der Hersteller die Konformität bereits nachgewiesen hat.
Die Pflichten der Hersteller sind dabei am umfangreichsten. Wer eine Webanwendung, eine SaaS-Lösung mit eigenem Softwarekern oder ein Plugin verkauft, zählt in der Regel zu dieser Gruppe.
Das betrifft in der Praxis auch kleinere Anbieter. Eine Agentur, die ein selbst entwickeltes Buchungssystem verkauft. Ein IT-Dienstleister mit eigener Fernwartungssoftware. Ein Unternehmen, das sein internes Warenwirtschaftssystem inzwischen auch an andere Firmen lizenziert. Sobald ein Produkt den eigenen Betrieb verlässt und an Dritte geht, zählt das in der Regel als Inverkehrbringen im Sinne des Gesetzes.
Diese Ausnahmen gibt es
Nicht-kommerzielle Open-Source-Software ist vom Cyber Resilience Act ausgenommen. Wer eine Software kostenlos und ohne kommerziellen Zweck pflegt, fällt nicht unter die Verordnung. Sobald aber kommerzieller Support, eine kostenpflichtige Enterprise-Version oder bezahlte Zusatzleistungen angeboten werden, greift der CRA in der Regel doch. Mehr zu dieser Abgrenzung lesen Sie in unserem Artikel zur Open-Source-Lizenz-Compliance.
Eigene Regelungen gelten außerdem für Medizinprodukte, Fahrzeuge und zivile Luftfahrt. Diese Branchen haben spezifische Gesetze, die Vorrang haben.
Individualsoftware, die ein Unternehmen ausschließlich intern nutzt und nicht auf dem Markt bereitstellt, fällt nach aktuellem Stand nicht unter die Meldepflichten. Sobald sie verkauft, lizenziert oder Kunden zur Verfügung gestellt wird, ändert sich das.
Für Legacy-Software gilt derselbe Grundsatz. Ein zehn Jahre altes PHP-System, das weiterhin aktiv an Kunden ausgeliefert oder gewartet wird, fällt unter den Cyber Resilience Act, auch wenn der ursprüngliche Entwickler das Unternehmen längst verlassen hat. Das Alter des Codes spielt für die Einordnung keine Rolle. Entscheidend ist allein, dass das Produkt heute noch auf dem Markt ist.
Was gilt seit dem 11. September 2026?
Seit diesem Datum müssen Hersteller zwei Arten von Vorfällen melden: Sicherheitslücken, die aktiv ausgenutzt wurden, und schwere Sicherheitsvorfälle, die Daten oder wichtige Funktionen gefährden.
Die Meldung läuft über die CRA Single Reporting Platform, die die europäische Agentur ENISA bereitstellt. In Deutschland ist das BSI die zuständige Marktüberwachungsbehörde.
Dafür gelten feste Fristen. Innerhalb von 24 Stunden nach Kenntnisnahme folgt eine erste Frühwarnung. Innerhalb von 72 Stunden folgt eine detaillierte Meldung mit weiteren Informationen und ersten Gegenmaßnahmen. Der Abschlussbericht folgt 14 Tage nach der Behebung einer aktiv ausgenutzten Sicherheitslücke, beziehungsweise einen Monat nach der Detailmeldung bei einem schweren Sicherheitsvorfall.
Diese Fristen sind kurz. Wer bisher keinen Prozess hat, um Sicherheitslücken im eigenen Code zu erkennen und zu dokumentieren, bekommt jetzt ein Problem. Ohne Monitoring verpasst man den Moment, in dem die 24-Stunden-Frist zu laufen beginnt.
Was kommt ab Dezember 2027 noch dazu?
Ab dem 11. Dezember 2027 gelten die vollständigen Anforderungen des Cyber Resilience Act. Sie sind Voraussetzung für die CE-Kennzeichnung. Ohne sie darf ein betroffenes Produkt ab diesem Zeitpunkt nicht mehr auf den EU-Markt gebracht werden.
Konkret bedeutet das für Hersteller: Sicherheit muss von Anfang an eingeplant werden, nicht nachträglich ergänzt. Das Prinzip heißt Secure by Design und Secure by Default. Produkte werden von Grund auf sicher entwickelt und sind im Auslieferungszustand bereits sicher konfiguriert.
Sicherheitsupdates müssen über einen festgelegten Supportzeitraum bereitgestellt werden, mindestens fünf Jahre lang. Käufer müssen vor dem Kauf erfahren, wie lange der Support läuft. Die Updates selbst müssen kostenlos und leicht zugänglich sein.
Hersteller brauchen außerdem eine Software Bill of Materials, kurz SBOM. Das ist eine vollständige Liste aller Komponenten und Abhängigkeiten, aus denen eine Software besteht, ähnlich einer Zutatenliste. Dazu kommt ein laufendes Schwachstellenmanagement.
Je nach Einstufung des Produkts reicht eine Selbstbewertung aus, oder es muss eine unabhängige Prüfstelle eingebunden werden. Standardprodukte dürfen sich meist selbst bewerten. Wichtige Produkte nach Anhang III und kritische Produkte nach Anhang IV brauchen strengere Verfahren.
Welche Konsequenzen drohen bei Verstößen?
Verstöße gegen den Cyber Resilience Act können teuer werden. Die Bußgelder reichen bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.
Das trifft nicht nur Großkonzerne. Auch ein mittelständisches Softwarehaus mit zwei Millionen Euro Jahresumsatz bewegt sich hier in einem Bereich, der ein Unternehmen ernsthaft gefährden kann. Erfahrungen mit DSGVO-Bußgeldern zeigen, dass Aufsichtsbehörden solche Rahmen durchaus ausschöpfen.
Hinzu kommt ein Reputationsrisiko. Ein gemeldeter, aber nicht fristgerecht behobener Sicherheitsvorfall wird sichtbar, sobald die Marktüberwachungsbehörde eingreift.
Die Marktüberwachungsbehörden können zudem eingreifen, bevor ein Bußgeld überhaupt im Raum steht. Sie können ein nicht konformes Produkt vom Markt nehmen lassen. Für ein Unternehmen, dessen Software dann plötzlich nicht mehr verkauft werden darf, ist das oft das größere Problem als die Geldstrafe selbst.
Was sollten kleine Softwareanbieter jetzt konkret tun?
Vier Schritte helfen, strukturiert vorzugehen.
Schritt 1: Prüfen, ob der CRA greift
Klären Sie, ob Ihre Software oder Ihr Produkt geschäftlich auf dem EU-Markt bereitgestellt wird und ob eine der Ausnahmen zutrifft. Im Zweifel lieber einmal zu viel geprüft als einmal zu wenig.
Schritt 2: Einen Meldeprozess aufbauen
Legen Sie fest, wer im Unternehmen für Sicherheitsmeldungen zuständig ist und wie die 24-Stunden-Frist in der Praxis eingehalten wird. Ohne klaren Ablauf verstreicht die Frist, bevor überhaupt jemand informiert ist.
Schritt 3: Abhängigkeiten dokumentieren
Erstellen Sie eine erste SBOM, auch wenn die volle Pflicht erst 2027 greift. Wer heute schon weiß, welche Bibliotheken und Komponenten im eigenen Code stecken, erkennt neue Schwachstellen deutlich schneller. Für den Anfang reicht eine einfache Liste: Welches Framework, welche Bibliotheken, welche Versionen stecken im Code? Spezialisierte Werkzeuge können diese Liste später automatisch aktuell halten. Gerade bei technischen Schulden in gewachsenem Code taucht hier oft die erste Überraschung auf.
Schritt 4: Code und Prozesse jetzt prüfen lassen
Ein Sicherheits-Audit zeigt, wo Ihr System heute steht und was bis Dezember 2027 noch fehlt. Das ist deutlich günstiger, als die Anforderungen kurz vor der Deadline hastig umzusetzen.
Gerne übernehmen wir diese Bestandsaufnahme für Sie. Unser Sicherheits-Audit prüft Ihren Code, Ihre Abhängigkeiten und Ihre Prozesse auf CRA-Tauglichkeit, bevor eine Behörde das für Sie tut.
Fazit: Jetzt klären, nicht im Dezember 2027
Der Cyber Resilience Act ist kein Randthema für Konzerne. Er betrifft jedes Unternehmen, das Software oder vernetzte Produkte auf dem EU-Markt anbietet, von der kleinen SaaS-Lösung bis zur Industriemaschine. Seit dem 11. September 2026 laufen die ersten Meldefristen. Ab Dezember 2027 kommen die vollständigen Anforderungen dazu.
Wer jetzt klärt, ob der Cyber Resilience Act greift, und einen Meldeprozess aufbaut, hat gut ein Jahr Vorlauf. Wer wartet, hat im Dezember 2027 einen sehr engen Zeitplan.
Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihre Software an und sagen Ihnen ehrlich, ob und wie der Cyber Resilience Act Sie betrifft.
