EU-Verordnung (EU) 2024/2847

Cyber Resilience Act:
Meldepflichten ab 11.09.2026

Wer Produkte mit digitalen Elementen in der EU auf den Markt bringt, braucht künftig mehr als CE-Konformität im klassischen Sinn. Der erste harte Termin ist nah: ab 11. September 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle.

30 Minuten · kostenlos · kein Verkaufsdruck · Sie bekommen danach eine schriftliche Einschätzung

Gilt das für uns?

„Wir sind kein Softwarehaus“
schützt nicht

Der CRA knüpft am Produkt an, nicht an der Branche. Sobald etwas mit digitalen Elementen in der EU auf den Markt kommt, greift die Verordnung.

Betrifft Sie sehr wahrscheinlich

  • Sie stellen Geräte mit Software her — Maschinen, Steuerungen, Sensoren, Haustechnik, Medizin- oder Messtechnik
  • Sie vertreiben Software als eigenständiges Produkt, auch als Anwendung oder Bibliothek
  • Sie importieren oder handeln mit solchen Produkten aus Drittländern in die EU
  • Ihr Produkt hat eine Netzwerkschnittstelle, eine App, ein Update-Verfahren oder eine Cloud-Anbindung

Betrifft Sie eher nicht

  • Reine Dienstleistungen ohne ein Produkt, das in Verkehr gebracht wird
  • Produkte, für die bereits gleichwertige sektorspezifische Regelungen gelten — etwa Teile der Medizinprodukte- oder Luftfahrtregulierung
  • Für quelloffene Software außerhalb kommerzieller Tätigkeit gelten Sonderregeln — die Abgrenzung ist im Einzelfall zu prüfen

Warum der 11.09.2026 der eigentliche Weckruf ist: Die großen Anforderungen — technische Dokumentation, Konformitätsbewertung, CE — greifen erst Ende 2027. Die Meldepflichten kommen aber deutlich früher, und sie verlangen etwas, das sich nicht in einer Woche aufbauen lässt: einen funktionierenden Prozess, der aktiv ausgenutzte Schwachstellen erkennt, bewertet und fristgerecht meldet. Wer das erst im Ernstfall aufsetzt, verpasst die Frist.

Was gefordert wird

Sicherheit über den
gesamten Lebenszyklus

Der CRA verlangt keinen einmaligen Nachweis zum Verkaufszeitpunkt, sondern Sicherheit über den gesamten Supportzeitraum. Das ist der eigentliche Bruch zu bisherigen Produktvorschriften.

1
Security by Design

Produkte müssen so entwickelt werden, dass sie ohne bekannte ausnutzbare Schwachstellen ausgeliefert werden — mit sicherer Standardkonfiguration statt unsicherer Voreinstellungen.

2
Schwachstellenmanagement

Ein dokumentierter Prozess, der Schwachstellen im eigenen Produkt und in den verwendeten Komponenten erfasst, bewertet und behebt — über den gesamten Supportzeitraum.

3
Softwarestückliste (SBOM)

Eine maschinenlesbare Übersicht der verwendeten Komponenten, mindestens auf oberster Ebene. Ohne sie lässt sich bei einer neuen Schwachstelle nicht sagen, ob das eigene Produkt betroffen ist.

4
Sicherheitsupdates

Updates müssen bereitgestellt werden, in der Regel unentgeltlich und zeitnah. Der Supportzeitraum ist festzulegen und gegenüber Nutzern klar zu kommunizieren.

5
Meldepflichten ab 11.09.2026

Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle sind gestuft zu melden — Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht binnen 14 Tagen.

6
Technische Dokumentation und CE

Ab Dezember 2027: Nachweisunterlagen, Konformitätsbewertung nach dem für Ihre Produktklasse vorgesehenen Verfahren und die CE-Kennzeichnung.

Was auf dem Spiel steht

Ohne Konformität
kein EU-Marktzugang

🚧
 
Verlorener Marktzugang

Das schwerwiegendste Risiko ist kein Bußgeld: Produkte, die die Anforderungen nicht erfüllen, dürfen in der EU nicht in Verkehr gebracht werden. Marktüberwachungsbehörden können Rücknahme und Rückruf anordnen.

💶
15 Mio. € / 2,5 %
Bußgelder

Bei Verstößen gegen die wesentlichen Sicherheitsanforderungen bis 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes. Für andere Pflichtverstöße gelten niedrigere Rahmen.

⏱️
24 h
Verpasste Meldefristen

Ab September 2026 läuft bei einer aktiv ausgenutzten Schwachstelle eine 24-Stunden-Frist für die Frühwarnung. Wer erst dann klärt, wer meldet und wohin, hat die Frist bereits verloren.

So gehen wir vor

Vom Produktscoping
zur Konformität

Wir arbeiten entlang der Fristen: zuerst der Meldeprozess für September 2026, danach die Unterlagen für Dezember 2027.

Woche 1–2
Produktscoping

Welche Ihrer Produkte fallen unter den CRA und in welche Kategorie? Die Einstufung entscheidet über das spätere Konformitätsbewertungsverfahren und damit über den Aufwand.

Woche 2–4
Meldeprozess aufsetzen

Priorität eins wegen der Frist im September 2026: Wer erkennt eine aktiv ausgenutzte Schwachstelle, wer bewertet sie, wer meldet innerhalb von 24 und 72 Stunden — und an wen.

Monat 1–3
Schwachstellenmanagement und SBOM

Prozess zur Erfassung und Behebung von Schwachstellen, Aufbau der Softwarestückliste, Festlegung des Supportzeitraums und des Update-Verfahrens.

Monat 3–6
Entwicklungsprozess anpassen

Sicherheitsanforderungen in Entwicklung, Test und Freigabe verankern. Das ist der Teil, der am längsten dauert, weil er Arbeitsweisen berührt.

Bis 12/2027
Dokumentation und Konformitätsbewertung

Technische Unterlagen erstellen, Bewertungsverfahren durchlaufen, Konformitätserklärung und CE-Kennzeichnung. Mit Vorlauf statt auf den letzten Metern.

Das bekommen Sie

Am Ende liegt etwas
auf dem Tisch — nicht nur ein Gefühl

Der CRA verlangt am Ende prüffähige Unterlagen. Diese hier entstehen im Projekt.

Produktscoping und KlassifizierungWelche Produkte fallen darunter, in welche Kategorie, mit welchem Bewertungsverfahren
MeldeprozessGestufte Meldekette 24 h / 72 h / 14 Tage mit Zuständigkeiten und Vorlagen
Schwachstellen-Handling-ProzessErfassung, Bewertung, Behebung und Kommunikation über den Supportzeitraum
SBOM-KonzeptAufbau, Format und Pflege der Softwarestückliste je Produkt
Update- und SupportkonzeptFestgelegter Supportzeitraum und Verfahren zur Bereitstellung von Sicherheitsupdates
Coordinated-Disclosure-RichtlinieEin definierter Weg, auf dem Externe Ihnen Schwachstellen melden können
Technische DokumentationStruktur und Inhalte für die Nachweisführung ab Dezember 2027
KonformitätsfahrplanPriorisierter Plan bis zur CE-Kennzeichnung, mit Zwischenterminen
Was wir geleistet haben

Erfahrung, die sich
nachrechnen lässt

XXHersteller bei der CRA-Vorbereitung begleitet
XXProdukte gescopt und klassifiziert
X Wochenim Schnitt bis zum funktionierenden Meldeprozess
  • Produktportfolios gescopt und in die Kategorien des CRA eingeordnet
  • Meldeprozesse für aktiv ausgenutzte Schwachstellen aufgesetzt und durchgespielt
  • Schwachstellenmanagement in bestehende Entwicklungsprozesse integriert statt danebengestellt
  • SBOM-Konzepte entwickelt, die im Build-Prozess automatisch mitlaufen
  • CRA-Anforderungen mit einem bestehenden ISMS verbunden, statt ein zweites System aufzubauen

Platzhalter: Die drei Kennzahlen oben sind noch nicht belegt. Vor dem Livegang durch echte Werte ersetzen — oder den Zahlenblock entfernen und nur die Liste stehen lassen. Markierung entfernen: class="todo" im Quelltext löschen.

FAQ

Häufige Fragen zu CRA

Was genau gilt ab dem 11. September 2026?
Ab diesem Datum greifen die Meldepflichten: Aktiv ausgenutzte Schwachstellen in Ihren Produkten und schwerwiegende Sicherheitsvorfälle mit Auswirkung auf deren Sicherheit sind gestuft zu melden — eine Frühwarnung binnen 24 Stunden, eine ausführlichere Meldung binnen 72 Stunden und ein Abschlussbericht binnen 14 Tagen. Die übrigen Hauptpflichten folgen erst am 11.12.2027.
Wir liefern nur an andere Unternehmen, nicht an Verbraucher. Ändert das etwas?
Nein. Der CRA unterscheidet nicht nach Abnehmergruppe, sondern knüpft daran an, dass ein Produkt mit digitalen Elementen in der EU in Verkehr gebracht wird. Business-to-Business-Produkte sind genauso erfasst — häufig sogar in strengeren Kategorien, weil sie in kritischeren Umgebungen eingesetzt werden.
Wir kaufen Komponenten zu. Haften wir für deren Schwachstellen?
Als Hersteller des Endprodukts sind Sie für dessen Sicherheit verantwortlich, einschließlich der eingebundenen Komponenten. Genau deshalb ist die Softwarestückliste kein Selbstzweck: Sie ist die Voraussetzung dafür, bei einer neu bekannt gewordenen Schwachstelle überhaupt beantworten zu können, ob Ihr Produkt betroffen ist.
Was ist eine SBOM und in welchem Format brauchen wir sie?
Eine Softwarestückliste listet die in einem Produkt enthaltenen Komponenten maschinenlesbar auf. Der CRA verlangt sie mindestens für die oberste Ebene der Abhängigkeiten. In der Praxis haben sich etablierte Formate durchgesetzt; welches für Sie sinnvoll ist, hängt von Ihrer Build-Umgebung ab. Sinnvoll wird eine SBOM erst, wenn sie automatisch im Build entsteht statt manuell gepflegt zu werden.
Wie verhält sich der CRA zu unserer bestehenden CE-Kennzeichnung?
Der CRA ergänzt die bestehenden Produktvorschriften um Cybersicherheitsanforderungen; die CE-Kennzeichnung deckt künftig auch diese ab. Wo bereits sektorspezifische Regelungen mit gleichwertigen Anforderungen bestehen, gibt es Abgrenzungsregeln. Für die meisten Hersteller bedeutet es zusätzliche Nachweise im selben Verfahren, nicht ein zweites Verfahren.
Wir haben ISO 27001. Hilft uns das?
Ja, aber nur teilweise. Die ISO 27001 sichert Ihre eigene Organisation ab, der CRA Ihr Produkt — das sind zwei verschiedene Blickrichtungen. Übertragbar sind Risikomanagement, Vorfallsbehandlung und Lieferantensteuerung. Produktspezifisch neu aufzubauen sind Security by Design, SBOM, Update-Konzept und die technische Dokumentation.
Immer noch unsicher?

Klären Sie es
in 60 Sekunden

Kostenlos starten

Prüfen wir, ob Ihr Meldeprozess
bis September steht

In 30 Minuten wissen Sie, ob und wie CRA Sie trifft, was zuerst dran ist — und was Sie sich sparen können. Ohne Fachchinesisch, ohne Verkaufsdruck.