Während der Mittelstand noch mit der NIS2-Umsetzung beschäftigt ist, steht die nächste EU-Cybersicherheitsverordnung vor der Tür — und diesmal geht es nicht um den Betrieb von IT, sondern um Produkte. Der Cyber Resilience Act (Verordnung (EU) 2024/2847, kurz CRA) ist seit Dezember 2024 in Kraft und entfaltet seine erste konkrete Pflicht am 11. September 2026: die Meldepflicht nach Artikel 14.
Ehrlich: Viele Unternehmen, die betroffen sind, wissen es noch nicht. Der CRA zielt nicht nur auf Softwarehäuser und Elektronikhersteller — er trifft jeden Maschinenbauer, der eine vernetzte Steuerung ausliefert, jeden Anlagenbauer mit Fernwartungsmodul und jeden Händler, der Fremdprodukte unter eigenem Namen verkauft. In einer Region wie Oberfranken mit ihrer dichten Zulieferer- und Maschinenbaulandschaft ist das keine Nische, sondern der Normalfall.
Das Wichtigste in einem Satz: Ab dem 11.09.2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle in ihren Produkten binnen 24 Stunden melden — bei Verstößen drohen Bußgelder bis 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes. Die Pflicht gilt auch für Produkte, die bereits im Markt sind.
Was der Cyber Resilience Act regelt — und was nicht
Der CRA ist eine EU-Verordnung, keine Richtlinie. Das heißt: Er gilt unmittelbar in jedem Mitgliedstaat, ohne nationales Umsetzungsgesetz. Das Hin und Her, das wir bei NIS2 in Deutschland erlebt haben (Inkrafttreten erst im Dezember 2025, Jahre nach der EU-Frist), gibt es hier nicht. Die Fristen stehen fest und verschieben sich nicht durch Berliner Gesetzgebungsverzug.
Reguliert werden „Produkte mit digitalen Elementen" — Hardware und Software, die direkt oder indirekt mit einem Gerät oder Netzwerk verbunden werden kann. Das ist bewusst breit gefasst: vom Smart-Home-Sensor über die SPS-Steuerung bis zur kommerziellen Standardsoftware. Erstmals bekommen digitale Produkte damit eine CE-Kennzeichnungspflicht für Cybersicherheit, so wie es sie für Maschinensicherheit oder EMV längst gibt.
Was ausgenommen ist
- Medizinprodukte (MDR/IVDR), Kfz (UNECE R155/156) und Luftfahrt — hier gelten eigene, bereits strengere Regime
- Reine Cloud-/SaaS-Dienste ohne Produktbezug — die fallen unter NIS2, nicht unter den CRA. Grenzfall: „Remote Data Processing", das für die Produktfunktion notwendig ist (z. B. die Cloud hinter einer Smart-Kamera), gehört zum Produkt und damit in den CRA-Scope
- Unentgeltliche Open-Source-Software außerhalb einer kommerziellen Tätigkeit — wer Open Source aber kommerziell in ein Produkt integriert und verkauft, trägt als Hersteller die volle Verantwortung, inklusive der Komponenten
Die Timeline: Warum der 11. September 2026 der kritische Termin ist
Der Dezember 2027 klingt weit weg — der September 2026 ist es nicht. Und die Meldepflicht ist tückischer als sie aussieht: Sie setzt voraus, dass Sie überhaupt wissen, dass eine Schwachstelle in Ihrem Produkt aktiv ausgenutzt wird. Ohne funktionierendes Schwachstellenmanagement und ohne Monitoring läuft die 24-Stunden-Uhr ab, bevor Sie den Vorfall bemerkt haben.
Wer betroffen ist — die unterschätzte Reichweite
Der CRA adressiert primär Hersteller, daneben mit abgestuften Pflichten Importeure und Händler. Entscheidend ist die wirtschaftliche Rolle, nicht die Selbstwahrnehmung:
- Klassische Hersteller: Softwarehäuser, Geräte- und Komponentenhersteller — der offensichtliche Fall
- Maschinen- und Anlagenbauer: Wer eine Maschine mit vernetzter Steuerung, Ethernet-Schnittstelle oder Fernwartungszugang ausliefert, liefert ein Produkt mit digitalen Elementen
- White-Label-Verkäufer: Wer Fremdprodukte unter eigenem Namen oder eigener Marke vertreibt, gilt rechtlich als Hersteller — mit allen Pflichten
- Wesentliche Modifikation: Wer ein bestehendes Produkt substanziell verändert (z. B. eigene Firmware aufspielt), rückt ebenfalls in die Herstellerrolle
- Importeure: Wer Produkte aus Drittstaaten (etwa Asien) in die EU einführt, muss prüfen, ob der Hersteller CRA-konform ist — und haftet bei Verstößen mit
Die Produktklassen
Rund 90 % aller Produkte fallen in die Standardkategorie und dürfen die Konformität per Selbstbewertung nachweisen. Darüber liegen die „wichtigen Produkte" der Klasse I (u. a. Passwort-Manager, Firewalls, Router, VPN-Produkte, Smart-Home-Sicherheitstechnik) und Klasse II (u. a. Hypervisoren, Betriebssysteme, Container-Runtimes, manipulationssichere Mikroprozessoren) sowie „kritische Produkte" (z. B. Smart-Meter-Gateways, Smartcards). Klasse II und kritische Produkte erfordern grundsätzlich eine Drittprüfung durch eine benannte Stelle — und genau da wird es eng: Die Akkreditierung der Prüfstellen läuft erst seit Juni 2026 an, Prüfkapazität wird 2027 ein knappes Gut.
In der Praxis: Die häufigste Fehleinschätzung, die wir in Gesprächen hören, ist „wir sind doch kein Softwarehersteller". Die zweite ist „das gilt doch erst 2027". Beides falsch: Die Meldepflicht ab September 2026 gilt für alle Hersteller von Produkten mit digitalen Elementen, die in der EU im Markt sind — unabhängig von Produktklasse und CE-Übergangsfrist.
Die Meldekaskade ab 11.09.2026 im Detail
Meldepflichtig sind zwei Ereignistypen: aktiv ausgenutzte Schwachstellen (eine CVE in Ihrem Produkt, die nachweislich in freier Wildbahn angegriffen wird) und schwerwiegende Sicherheitsvorfälle, die die Sicherheit des Produkts beeinträchtigen. Die Meldung erfolgt über die zentrale Single Reporting Platform (SRP) der ENISA und wird von dort automatisch an das national zuständige CSIRT geroutet — in Deutschland das BSI.
| Frist | Aktiv ausgenutzte Schwachstelle | Schwerwiegender Vorfall |
|---|---|---|
| 24 Stunden | Frühwarnung an ENISA/CSIRT | Frühwarnung an ENISA/CSIRT |
| 72 Stunden | Folgemeldung: Details zur Schwachstelle, verfügbare Korrektur- und Abhilfemaßnahmen | Folgemeldung: Erste Bewertung, Schweregrad, Auswirkungen, Gegenmaßnahmen |
| 14 Tage | Abschlussbericht: Beschreibung, beteiligte Akteure, Fix, Mitigation | — |
| 1 Monat | — | Abschlussbericht: Vorfall, Root Cause, ergriffene Maßnahmen |
Zusätzlich müssen Hersteller die betroffenen Nutzer ihrer Produkte informieren — inklusive verfügbarer Gegenmaßnahmen. Wer schon einmal ein NIS2- oder DSGVO-Meldeschema aufgebaut hat, erkennt das Muster: Die Fristen sind bewusst so kurz, dass sie ohne vorbereitete Prozesse, klare Zuständigkeiten und eine erreichbare Ansprechstelle nicht zu halten sind. 24 Stunden inklusive Wochenende und Werksferien.
Ehrlich: Stand Juli 2026 ist die ENISA-Meldeplattform noch nicht produktiv — sie soll pünktlich zum 11. September live gehen, eine Testphase ist angekündigt. Das ist kein Grund zur Entwarnung, sondern zur Sorge: Sie werden kaum Gelegenheit haben, den Meldeweg vorher zu üben. Umso wichtiger, dass der interne Prozess — Erkennen, Bewerten, Entscheiden, Formulieren — vorher steht und geprobt ist.
CRA vs. NIS2: Zwei Regime, ein Unternehmen
Viele Mittelständler werden ab September von beiden Regelwerken gleichzeitig erfasst — NIS2 als Betreiber, CRA als Hersteller. Die Abgrenzung:
| NIS2 / BSIG | Cyber Resilience Act | |
|---|---|---|
| Reguliert | Den IT-Betrieb von Einrichtungen | Das Produkt über seinen Lebenszyklus |
| Rechtsform | Richtlinie, national umgesetzt (BSIG) | Verordnung, gilt EU-weit unmittelbar |
| Betroffen | Ab 50 MA / 10 Mio. € Umsatz in 18 Sektoren | Jeder Hersteller/Importeur/Händler, ohne Größenschwelle |
| Meldung an | BSI (Meldeportal) | ENISA-SRP → BSI als CSIRT |
| Meldefrist | 24h / 72h / 1 Monat (Vorfälle im Betrieb) | 24h / 72h / 14 Tage bzw. 1 Monat (Produkt) |
| Max. Bußgeld | 10 Mio. € / 2 % Umsatz | 15 Mio. € / 2,5 % Umsatz |
Wichtig: Eine Meldung ersetzt nicht die andere. Wird ein Produkt Ihres Hauses angegriffen und dadurch auch Ihr eigener Betrieb beeinträchtigt, können CRA-Meldung, NIS2-Meldung und im Fall von Personendaten eine DSGVO-Meldung parallel fällig werden — mit drei verschiedenen Empfängern und Formaten. Genau deshalb gehört das in ein gemeinsames Incident-Response-Playbook, nicht in drei getrennte Ordner. Wie man so einen Prozess aufsetzt, haben wir im Artikel zum Incident Response Plan beschrieben.
Was ab Dezember 2027 zusätzlich kommt
Die Meldepflicht ist nur der Anfang. Ab dem 11.12.2027 dürfen nur noch Produkte neu in Verkehr gebracht werden, die die grundlegenden Anforderungen aus Anhang I erfüllen. Die wichtigsten Punkte, weil sie lange Vorlaufzeit brauchen:
- Security by Design: Risikobewertung als Teil der Produktentwicklung, sichere Default-Konfiguration, keine bekannten ausnutzbaren Schwachstellen bei Auslieferung
- SBOM-Pflicht: Eine Software-Stückliste mindestens der obersten Abhängigkeitsebene — Sie müssen wissen und dokumentieren, welche Komponenten und Bibliotheken in Ihrem Produkt stecken
- Kostenlose Sicherheitsupdates über den Support-Zeitraum — erwartete Nutzungsdauer, im Regelfall mindestens 5 Jahre
- Koordinierte Schwachstellen-Offenlegung: Eine öffentliche Kontaktstelle für Schwachstellenmeldungen (Coordinated Vulnerability Disclosure Policy) ist Pflicht
- Technische Dokumentation inklusive Risikoanalyse und Testnachweisen, aufzubewahren für 10 Jahre
- CE-Kennzeichnung auf Basis der Konformitätsbewertung — je nach Produktklasse Selbstbewertung oder benannte Stelle
Wer heute eine Produktlinie plant, die 2027 oder später ausgeliefert wird, entwickelt bereits jetzt unter CRA-Bedingungen — ob er will oder nicht. Ein nachträglich „drangeflanschtes" Schwachstellenmanagement ist teurer und schlechter als eines, das von Anfang an in der Entwicklungs- und Build-Pipeline steckt.
Die To-do-Liste bis zum 11. September
Sieben Wochen sind wenig, aber genug für das Nötigste. Priorisiert nach Wirkung:
- 1. Produktinventur: Welche Ihrer Produkte haben digitale Elemente und sind in der EU im Markt? Inklusive Altprodukte, White-Label und OEM-Komponenten. Ohne diese Liste ist alles Weitere Raten.
- 2. Rollenklärung: Sind Sie für jedes Produkt Hersteller, Importeur oder Händler? Bei zugekauften Komponenten: Wer meldet — Sie oder Ihr Lieferant? Das gehört vertraglich geregelt.
- 3. Meldeprozess definieren: Wer erkennt, wer bewertet, wer entscheidet, wer meldet — mit Stellvertreterregelung und 24/7-Erreichbarkeit. Ein Template für Frühwarnung und Folgemeldung vorbereiten, solange kein Echtfall drängt.
- 4. Schwachstellen-Monitoring aufsetzen: CVE-Feeds für die eigenen Produktkomponenten, eine erreichbare security@-Adresse und ein Prozess für eingehende Meldungen von außen. Wer keine SBOM hat, fängt mit der obersten Abhängigkeitsebene an.
- 5. Detektion prüfen: „Aktiv ausgenutzt" setzt voraus, dass Sie Ausnutzung erkennen können — Telemetrie, Logging, im Zweifel ein SOC, das rund um die Uhr hinschaut.
- 6. Übung: Einen Probefall durchspielen: fiktive CVE, Uhr läuft, 24-Stunden-Meldung formulieren. Die Lücken, die dabei auftauchen, sind die echten.
Fazit: Produktsicherheit wird meldepflichtig — und das ist erst der Anfang
Der 11. September 2026 macht aus einer abstrakten EU-Verordnung eine operative Pflicht mit 24-Stunden-Frist. Die gute Nachricht: Wer für NIS2 bereits Incident-Response-Prozesse, Monitoring und Meldewege aufgebaut hat, erweitert diese um die Produktdimension, statt bei null anzufangen. Die schlechte: Wer beides vor sich herschiebt, hat jetzt zwei Baustellen mit scharfen Fristen und empfindlichen Bußgeldern.
Die meisten KMU brauchen dafür keinen Compliance-Apparat, sondern drei Dinge: Klarheit über die eigene Betroffenheit, einen geübten Meldeprozess und eine Detektionsfähigkeit, die den Namen verdient. Bei den ersten beiden hilft eine ehrliche Bestandsaufnahme, beim dritten ein Partner, der 24/7 hinschaut — denn die 24-Stunden-Uhr kennt keine Werksferien.