Wenn Sie Software oder Hardware mit Software kommerziell in der EU verkaufen, dann gilt für Sie ab dem 11. September 2026 die Meldepflicht aus Artikel 14 des Cyber Resilience Act. Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen Sie dann innerhalb von 24 Stunden an die ENISA und Ihr nationales CSIRT melden. Das ist die kurze Antwort auf die Frage, die uns gerade am häufigsten erreicht. Und ja, die Pflicht gilt auch für Produkte, die längst auf dem Markt sind.
Der Rahmen dazu: Bußgelder von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.
Die eigentliche Entscheidung ist also nicht, ob Sie sich damit befassen. Sondern wie viel Sie jetzt investieren: gar nichts, ein paar Tage, oder ein volles Compliance-Programm. Wir gehen die drei Optionen durch, sagen klar, welche wir empfehlen, und genauso klar, für wen diese Empfehlung falsch wäre.
Was am 11. September 2026 tatsächlich beginnt
Zur Einordnung: Der Cyber Resilience Act ist seit Dezember 2024 in Kraft. Die meisten Pflichten, also CE-Kennzeichnung, Konformitätsbewertung und Security by Design, greifen erst mit der vollen Anwendung am 11. Dezember 2027. Eine Pflicht zieht der Gesetzgeber jedoch vor, und zwar ausgerechnet die mit der kürzesten Frist: die Meldepflicht.
Meldepflichtig sind zwei Dinge. Erstens aktiv ausgenutzte Schwachstellen, also Lücken, die nachweislich in echten Angriffen verwendet werden, nicht bloß theoretisch ausnutzbar wären. Zweitens schwerwiegende Vorfälle, die die Sicherheit Ihres Produkts beeinträchtigen. Ein CVE-Eintrag ohne Anzeichen für Ausnutzung löst die Pflicht nicht aus. Ein Kunde, der Ihnen einen laufenden Angriff über Ihre Software meldet, sehr wohl.
Empfänger sind die ENISA, die EU-Agentur für Cybersicherheit, und das CSIRT Ihres Mitgliedstaats, also das nationale Computer-Notfallteam. Gemeldet wird über eine gemeinsame Plattform, die Single Reporting Platform (SRP).
Die Fristen sind gestaffelt:
- Frühwarnung: innerhalb von 24 Stunden, nachdem Sie Kenntnis erlangt haben
- Ausführlichere Meldung: innerhalb von 72 Stunden
- Abschlussbericht: 14 Tage nach Bereitstellung der Korrektur bei einer Schwachstelle, 1 Monat bei einem Vorfall
Ein Detail, das viele überrascht: Die Pflicht knüpft nicht daran an, wann das Produkt auf den Markt kam. Auch die App, die Sie 2021 ausgeliefert haben und seither pflegen, fällt darunter, sobald dort eine aktiv ausgenutzte Schwachstelle auftaucht.
Und der Stand der Plattform? Ende August 2026 ist die SRP nicht live. Die ENISA hat am 31. Juli ihre Leitlinien veröffentlicht und verspricht, dass die Plattform zum 11. September betriebsbereit ist. Wichtig dabei: Die Validierung durch das CSIRT ist keine Voraussetzung dafür, dass Ihre Meldung als abgegeben gilt. Auf eine holprige Plattform zu hoffen ist also keine Strategie. Die Fristen laufen trotzdem.
Gilt das überhaupt für Sie?
Vier Regeln reichen für eine erste Einordnung:
- In den Anwendungsbereich fallen Sie, wenn Sie Software oder Hardware mit Software kommerziell in die EU verkaufen oder lizenzieren. Das umfasst Desktop-Software, mobile Apps, Firmware, IoT-Geräte und auch die individuell entwickelte Laravel-Anwendung, die Sie einem Kunden lizenzieren.
- Reines SaaS fällt nicht unter den CRA, dafür ist NIS2 zuständig. Eine wichtige Ausnahme: Eine Cloud-Komponente, ohne die das Produkt nicht funktioniert, etwa das Backend eines IoT-Geräts, zählt als Teil des Produkts und damit in den Anwendungsbereich.
- Open Source außerhalb kommerzieller Tätigkeit ist ausgenommen. Für sogenannte Open-Source-Stewards gelten leichtere Pflichten, und Bußgelder gibt es für sie nicht.
- Kleinst- und Kleinunternehmen müssen melden, können aber nicht mit einem Bußgeld belegt werden, wenn sie die 24-Stunden-Frühwarnung verpassen. Die übrigen Fristen und Pflichten bleiben.
Wenn Sie nach diesen vier Punkten unsicher sind, lohnt eine saubere Prüfung. Die Grenzfälle liegen fast immer bei der Frage, ob eine Cloud-Komponente Produktbestandteil ist oder eigenständiger Dienst.
Ihre drei Optionen
Option 1: Abwarten
Sie tun jetzt nichts und reagieren, wenn etwas passiert oder die Aufsicht sich meldet. Kostet heute null. Das ist ehrlicherweise nur für Unternehmen vertretbar, die klar außerhalb des Anwendungsbereichs stehen und das auch belegen können.
Option 2: Meldefähigkeit aufbauen. Unsere Empfehlung
Sie bauen das Minimum auf, das die Pflicht tatsächlich verlangt: Sie klären den Scope Ihrer Produkte, richten ein Monitoring für Ihre Abhängigkeiten und Schwachstellenquellen ein, schreiben ein kurzes Melde-Runbook mit Zuständigkeiten und Fristen und registrieren sich auf der SRP, sobald sie live ist. Kostenpunkt: 2 bis 4 Arbeitstage eines erfahrenen Entwicklers, verteilt über etwa zwei Wochen. Das passt für die meisten Softwareunternehmen, die an EU-Kunden liefern.
Unsere Haltung dazu ist einfach: Das Meldeformular ist nicht Ihr Problem. Das Wissen ist Ihr Problem. Unternehmen reißen die 24-Stunden-Frist nicht, weil ihr Runbook schlecht formuliert wäre, sondern weil niemand die Eingänge beobachtet, aus denen sie überhaupt erfahren würden, dass eine ihrer Schwachstellen aktiv ausgenutzt wird.
Option 3: Volles CRA-Programm jetzt
Sie ziehen die Vorbereitung auf Dezember 2027 vor: Konformitätsbewertung, Security-by-Design-Prozesse, Dokumentation, das ganze Paket, und die Meldefähigkeit gleich mit. Das kostet ein Vielfaches der Option 2 und bindet über Monate Kapazität. Sinnvoll ist es für Hersteller von Hardware und für Produkte, die in eine wichtige Produktklasse fallen und damit eine externe Konformitätsbewertung brauchen.
Woran jede Option scheitert
Abwarten klingt vernünftiger, als es ist. Ja, die Marktüberwachung muss 27 EU-Länder abdecken, und niemand steht am 12. September vor Ihrer Tür. Der Schlag kommt von woanders. Entweder wird eine Ihrer Schwachstellen tatsächlich ausgenutzt, und Sie stehen ohne Prozess vor einer 24-Stunden-Frist. Oder, viel banaler und viel früher: Die Einkaufsabteilungen Ihrer Kunden fragen in ihren Fragebögen bereits nach CRA-Konformität, und „daran arbeiten wir noch" kostet Sie den Auftrag.
Option 2 hat ihre eigene Falle: Papier als Ergebnis. Man bestellt ein Runbook, heftet es ab und fühlt sich fertig. Hier gehört auch das Zugeständnis hin, das wir jedem Interessenten machen: Das Monitoring ist der teure Teil, nicht das Dokument. Ein paar Tage Setup ergeben eine Alert-Pipeline, kein Sicherheitsteam. Ein Runbook ohne Monitoring dahinter ist ein Dokument, keine Fähigkeit. Wer Option 2 wählt, muss die Alerts auch tatsächlich jemandem auf den Tisch legen.
Und Option 3? Scheitert am häufigsten an Panik. Wer jetzt aus Angst das volle Programm kauft, zahlt Beraterhonorare für Pflichten, die erst am 11. Dezember 2027 greifen, und oft für Produkte, die am Ende gar keine externe Bewertung brauchen.
Die Entscheidung im Überblick
- Abwarten. Kosten jetzt: Keine. Risiko: Ausgenutzte Schwachstelle ohne Prozess, verlorene Ausschreibungen. Wählen Sie sie, wenn: Sie nachweislich außerhalb des Anwendungsbereichs stehen.
- Meldefähigkeit aufbauen. Kosten jetzt: 2 bis 4 Arbeitstage über ca. zwei Wochen. Risiko: Bleibt Papier, wenn das Monitoring fehlt. Wählen Sie sie, wenn: Sie Software kommerziell an EU-Kunden liefern.
- Volles CRA-Programm. Kosten jetzt: Ein Vielfaches, über Monate. Risiko: Überinvestition aus Panik. Wählen Sie sie, wenn: Sie Hardware herstellen oder in eine wichtige Produktklasse fallen.
Unser Urteil, je nach Ausgangslage
Sie sind ein Softwareunternehmen mit EU-Kunden? Option 2, und zwar noch diese Woche. Die 2 bis 4 Tage sind überschaubar, und der Abstand zum 11. September 2026 ist es auch.
Sie stellen Hardware her oder Ihr Produkt fällt in eine wichtige Produktklasse? Dann Option 3, jetzt. Die benannten Stellen, also die externen Prüforganisationen für die Konformitätsbewertung, werden 2027 ein Kapazitätsproblem haben. Das wird ein Verkäufermarkt, und wer spät kommt, wartet.
Sie betreiben reines SaaS? Halten Sie das Ergebnis Ihrer Prüfung schriftlich fest, damit Sie es Kunden und Auditoren zeigen können, und prüfen Sie stattdessen Ihre Pflichten unter NIS2. „Gilt nicht für uns" ist nur dann ein brauchbarer Satz, wenn er dokumentiert ist.
Wo Conimex IT ins Bild kommt
Wir entwickeln und betreuen Software für EU-Kunden, mit Laravel, React und React Native, und stehen damit selbst auf der Herstellerseite dieser Verordnung. Die Meldefähigkeit aus Option 2 ist genau das, was wir für Kunden aufsetzen: ein Scope-Assessment Ihrer Produkte, ein Monitoring für Abhängigkeiten und Schwachstellen, ein Melde-Runbook mit klaren Zuständigkeiten und die Begleitung durch die SRP-Registrierung.
Wenn Sie vor dem 11. September 2026 wissen wollen, wo Sie stehen, schreiben Sie uns an [email protected]. Eine erste Einschätzung Ihres Scopes ist schnell gemacht, und danach wissen Sie, ob Sie zwei Tage brauchen oder ein Programm.