Ab dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen ihrem nationalen CSIRT und der ENISA melden – nach einer dreistufigen Uhr: eine Frühwarnung innerhalb von 24 Stunden, eine vollständige Meldung innerhalb von 72 Stunden und ein Abschlussbericht innerhalb von 14 Tagen, nachdem ein Fix verfügbar ist. Daneben verlangt die Verordnung eine Richtlinie zur koordinierten Schwachstellenoffenlegung (CVD) mit einer öffentlichen Anlaufstelle, damit Forscher Schwachstellen direkt melden können. Wer das verpasst, riskiert Bußgelder von bis zu 15.000.000 € oder 2,5 % des weltweiten Jahresumsatzes – je nachdem, welcher Betrag höher ist.

Wenn Sie Software in die EU ausliefern, fallen Sie höchstwahrscheinlich unter den Begriff „Hersteller“, der Stichtag ist näher, als Sie denken, und „Dafür haben wir noch keinen Prozess“ ist keine haltbare Antwort mehr. Hier kommt, was das Gesetz tatsächlich verlangt, welche zwei Fristen ständig verwechselt werden und welche operative Mindestausstattung ein kleines Team braucht, um vorbereitet zu sein.

## Die Uhr, von der Sie nicht wussten, dass sie läuft: 11. September 2026

Das entscheidende Datum ist der **11. September 2026** – der Tag, an dem die Meldepflicht des CRA zur Anwendung kommt. Ab diesem Tag müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über die zentrale Meldeplattform der ENISA melden. Das ist die erste materielle Frist der [Verordnung (EU) 2024/2847](https://digital-strategy.ec.europa.eu/en/policies/cra-summary), noch vor dem Rest der Regelung – und genau die, die kleine Anbieter am ehesten kalt erwischt.

Die meiste CRA-Berichterstattung richtet sich an Enterprise-Hardwarehersteller und große Produktsicherheitsteams: SBOMs, CE-Kennzeichnung, Konformitätsbewertung. Diese Rahmung hat viele Gründer überzeugt, der CRA sei das Problem von jemand anderem. Ist er nicht. Die Melde-Uhr startet für alle Betroffenen am selben Tag, und ein SaaS-Unternehmen mit 20 Leuten und einem herunterladbaren Agenten ist genauso gebunden wie ein Gerätehersteller.

Die praktische Konsequenz ist unbequem. Wird eine Schwachstelle in Ihrem Produkt in der Woche nach dem Stichtag aktiv ausgenutzt, haben Sie 24 Stunden Zeit, eine Frühwarnung einzureichen. Wenn Sie keine Annahmestelle, keine Sichtung und keine Ahnung haben, wer in Ihrem Unternehmen für diese Meldung zuständig ist, erfahren Sie all das unter dem denkbar größten Zeitdruck.

## Sind Sie ein „Hersteller eines Produkts mit digitalen Elementen“?

Wahrscheinlich ja. Der CRA definiert ein **Produkt mit digitalen Elementen** im Kern als jede Software oder Hardware, die sich mit einem Gerät oder Netzwerk verbindet, und legt die zentralen Pflichten dem **Hersteller** auf – ein Begriff, der ausdrücklich auch Softwareentwickler einschließt, die ein Produkt kommerziell vertreiben.

Das umfasst weit mehr als vernetzte Gadgets. Prüfen Sie, ob eine dieser Beschreibungen auf Sie zutrifft:

- Ein SaaS-Produkt mit einer herunterladbaren Desktop-App, einer Browser-Erweiterung oder einem lokalen Agenten.
- Ein vernetztes Gerät oder jegliche Hardware mit Firmware.
- Eine kommerzielle Softwarebibliothek, ein SDK oder ein selbst gehostetes Produkt, das in die EU verkauft oder lizenziert wird.
- Ein Solo-Gründer oder Maintainer, der Software, die in der EU genutzt wird, *kommerziell unterstützt*.

Importeure und Händler tragen leichtere Pflichten – aber wenn Sie das Produkt bauen und verkaufen, sind Sie der Hersteller. Die Open-Source-Nuance ist hier ebenfalls wichtig: rein nicht-kommerzielle Open Source liegt in der Regel außerhalb der Herstellerpflichten, doch in dem Moment, in dem Sie sie monetarisieren (bezahlter Support, eine kommerzielle Edition, eine gehostete Version), rutschen Sie in den Anwendungsbereich.

Beim CRA können Sie sich nicht durch die Rechtslage hindurchmogeln. Wenn Sie unsicher sind, ob ein bestimmtes Produkt in den Anwendungsbereich fällt, ist das ein Gespräch für Ihre Rechtsberatung. Doch die Standardannahme für ein Softwareunternehmen, das in die EU verkauft, sollte lauten: „im Anwendungsbereich, bis das Gegenteil bewiesen ist“ – nicht umgekehrt.

## Was der CRA für die Schwachstellenoffenlegung tatsächlich verlangt

Der EU Cyber Resilience Act verpflichtet Hersteller, eine Richtlinie zur koordinierten Schwachstellenoffenlegung mit einer öffentlichen Anlaufstelle zu betreiben, und ab dem 11. September 2026, aktiv ausgenutzte Schwachstellen ihrem CSIRT und der ENISA innerhalb von 24 Stunden (Frühwarnung), 72 Stunden (vollständige Meldung) und 14 Tagen (Abschlussbericht, nachdem ein Fix verfügbar ist) zu melden. Unter dieser Zusammenfassung liegen zwei eigenständige Pflichten, und sie stammen aus zwei verschiedenen Artikeln.

**Die CVD-Richtlinie und die Anlaufstelle (Artikel 13).** Artikel 13(8) verlangt von Herstellern „geeignete Strategien und Verfahren, einschließlich Strategien für die koordinierte Offenlegung von Schwachstellen … um potenzielle Schwachstellen zu bearbeiten und zu beheben …, die aus internen oder externen Quellen gemeldet werden“. Artikel 13(17) verlangt eine **zentrale Anlaufstelle**, damit jeder – auch Sicherheitsforscher – eine Schwachstelle direkt melden kann. Entscheidend: Sie muss den Meldenden die Wahl ihres Kommunikationskanals lassen; Sie dürfen nicht alle durch ein einziges automatisiertes Werkzeug zwingen.

**Die Meldepflicht (Artikel 14).** Das ist die 24/72/14-Uhr gegenüber den Behörden, und hier leben die festen Stundenfristen.

Ein Mythos gehört hier ausgeräumt. Mehrere Anbieter-Blogs behaupten, der CRA schreibe eine **48-Stunden-Frist zur Bestätigung einer Forschermeldung** vor. Tut er nicht. Der Gesetzestext von Artikel 13 enthält überhaupt keine feste Stundenfrist für die Bestätigung. Die einzigen festen Stunden-Uhren der Verordnung sind die Behörden-Meldefristen nach Artikel 14. Behandeln Sie ein Bestätigungs-SLA als Best Practice, die Ihre Richtlinie definieren sollte – nicht als Zahl, die Sie dem Gesetz zuschreiben.

## Der Meldetakt 24/72/14 und was ihn auslöst

Für eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall ist der Meldetakt eine dreistufige Uhr, jeweils gemessen ab dem Zeitpunkt, an dem Sie Kenntnis erlangen:

| Stufe | Frist | Worum es geht |
|---|---|---|
| Frühwarnung | **24 Stunden** | Ein erster Hinweis, dass Sie eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall haben. |
| Vollständige Meldung | **72 Stunden** | Ein umfassenderes Bild: Details, Status, ergriffene Korrektur- oder Eindämmungsmaßnahmen. |
| Abschlussbericht (Schwachstellen) | **14 Tage** nach Verfügbarkeit eines Fixes | Der abschließende Bericht, sobald eine Korrekturmaßnahme existiert. |
| Abschlussbericht (schwerwiegende Vorfälle) | **1 Monat** | Der abschließende Bericht für schwerwiegende Sicherheitsvorfälle. |

Sie melden einmal. Die **zentrale Meldeplattform**, die von der [ENISA](https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp) eingerichtet, verwaltet und betrieben wird, leitet Ihre Meldung gleichzeitig an das CSIRT, das im Mitgliedstaat Ihrer Hauptniederlassung als Koordinator benannt ist, und an die ENISA weiter. Dieses empfangende CSIRT verbreitet sie dann unverzüglich an andere relevante nationale CSIRTs. Die Plattform nimmt außerdem freiwillige Meldungen von Schwachstellen, Bedrohungen, Vorfällen und Beinahevorfällen von jedermann entgegen.

Der Auslöser ist eng gefasst, und ihn richtig zu treffen, zählt genauso viel wie die Fristen. Die 24-Stunden-Uhr startet nur bei einer **aktiv ausgenutzten Schwachstelle** – das heißt, es gibt belastbare Belege dafür, dass ein böswilliger Akteur sie ausgenutzt hat – oder bei einem **schwerwiegenden Sicherheitsvorfall**, also einer schwerwiegenden Auswirkung auf die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit des Produkts. Nicht jede Schwachstelle, die ein Forscher meldet, löst die Behörden-Uhr aus. Die meisten tun es nicht. Aber den Unterschied erkennen Sie nicht ohne einen Sichtungsschritt, der schnell einordnen kann, was gerade in Ihrem Posteingang gelandet ist – und genau deshalb ist eine laufende Pipeline von der Annahme bis zur Sichtung der operative Kern der CRA-Bereitschaft.

## Die zwei Fristen, die alle verwechseln: 2026 vs. 2027

Viel Sekundärberichterstattung verschmilzt zwei Daten zu einem, und diese Verwechslung erzeugt ein falsches Gefühl von Sicherheit. Halten Sie sie auseinander:

- **11. September 2026** – die Meldepflicht (Artikel 14) gilt. Die 24/72/14-Uhr gegenüber der ENISA und Ihrem CSIRT läuft.
- **11. Dezember 2027** – das Hauptanwendungsdatum des CRA, ab dem die dauerhaften Herstellerpflichten – einschließlich der CVD-Richtlinie und der zentralen Anlaufstelle nach Artikel 13 – für Produkte gelten, die auf dem Markt bereitgestellt werden.

Es ist verlockend, das Datum 2027 zu lesen und daraus zu schließen, dass Sie achtzehn Monate Luft haben. Haben Sie nicht. Die Melde-Uhr startet 2026, und Sie können eine 24-Stunden-Meldepflicht nicht erfüllen, ohne bereits die Annahme, die Sichtung und die Zuständigkeit zu haben, die die CVD-Richtlinie beschreibt. Die Pflicht von 2027 formalisiert den Prozess; die Pflicht von 2026 setzt voraus, dass Sie ihn bereits ausführen können. In der Praxis heißt das: Die Offenlegungsinfrastruktur muss noch dieses Jahr existieren.

## Was ein konformer CVD-Ablauf enthalten muss

Wenn man den Gesetzestext mit Praxisleitfäden zusammenführt – darunter [HackerOnes Leitfaden zur CRA-Bereitschaft](https://www.hackerone.com/blog/cyber-resilience-act-vdp-2026-reporting-readiness) –, hat ein haltbarer Ablauf zur koordinierten Offenlegung sechs Bestandteile:

1. **Öffentliche, dokumentierte Annahme.** Eine zentrale Anlaufstelle, in der Praxis eine [`security.txt`-Datei nach RFC 9116](https://www.rfc-editor.org/rfc/rfc9116) plus eine veröffentlichte Richtlinienseite, damit ein Forscher, der eine Schwachstelle findet, genau weiß, wohin er sie schicken soll.
2. **Deklarierter Geltungsbereich.** Welche Produkte und Versionen abgedeckt sind, was ausdrücklich außerhalb des Geltungsbereichs liegt und welche Schwachstellenklassen Sie nicht annehmen.
3. **Sichtung und Validierung.** Der Schritt, der entscheidet, ob eine Meldung eine aktiv ausgenutzte Schwachstelle oder ein schwerwiegender Sicherheitsvorfall ist – der Auslöser der 24-Stunden-Uhr.
4. **Koordination mit dem Meldenden.** Ein echter Kanal für den Dialog mit dem Forscher vor der öffentlichen Offenlegung.
5. **Behebung ohne ungebührliche Verzögerung und ein öffentliches Advisory**, sobald ein Fix ausgeliefert wird.
6. **Prüfbare Aufzeichnungen.** Nachvollziehbare Zuständigkeit und ein Zeitverlauf, den Sie einer Marktüberwachungsbehörde auf Anfrage vorlegen können.

Den letzten Punkt überspringen Teams und bereuen es. „Wir haben verantwortungsvoll koordiniert“ ist eine Behauptung. Ein mit Zeitstempeln versehener Verlauf, der zeigt, wann die Meldung eintraf, wann sie gesichtet wurde, wann der Meldende informiert wurde und wann der Fix ausgeliefert wurde, ist ein Beleg. Bei einer Verordnung mit umsatzabhängigen Bußgeldern ist der Unterschied zwischen einer Behauptung und einem Beleg das ganze Spiel.

## Der Preis, es falsch zu machen

Verstöße gegen die wesentlichen Anforderungen und die Pflichten aus Artikel 13/14 werden mit Bußgeldern von **bis zu 15.000.000 € oder bis zu 2,5 % des gesamten weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres geahndet – je nachdem, welcher Betrag höher ist**. Darunter liegen zwei niedrigere Stufen:

| Verstoß | Höchstbußgeld |
|---|---|
| Verstoß gegen wesentliche Anforderungen und Pflichten aus Artikel 13/14 | **15 Mio. € oder 2,5 % des weltweiten Umsatzes** |
| Sonstige Pflichten nach der Verordnung | 10 Mio. € oder 2 % des Umsatzes |
| Übermittlung unrichtiger oder irreführender Angaben an Behörden | 5 Mio. € oder 1 % des Umsatzes |

Die Konstruktion „je nachdem, welcher Betrag höher ist“ unterschätzen Gründer am meisten. Für ein kleines Unternehmen sehen die absoluten Euro-Beträge nach Enterprise-Problemen aus, doch die Prozentstufen skalieren mit Ihnen nach unten – und durch die Struktur der Verordnung sind genau die *Prozess*-Versäumnisse (keine CVD-Richtlinie, eine verpasste Meldung, eine irreführende Angabe) jene, die günstig zu verhindern und teuer zu ignorieren sind.

<div class="blog-inline-cta">
  <p><strong>Näher, als es aussieht.</strong> Die Melde-Uhr startet am 11. September 2026, und eine 24-Stunden-Frist erreichen Sie nicht, ohne dass Annahme, Sichtung und Prüfpfad bereits laufen. Das CSIRT-Modul von Kit liefert Ihnen alle drei direkt out of the box.</p>
  <p><a href="/users/sign_up">Kostenlose Testphase starten</a></p>
</div>

## Bauen Sie mit Kit einen CRA-tauglichen Prozess für koordinierte Offenlegung

Der CRA macht aus der koordinierten Schwachstellenoffenlegung ein Nice-to-have der Reife eine rechtliche Pflicht mit hartem Stichtag und umsatzabhängigem Risiko. Für die meisten Gründer ist die Lücke operativ, nicht philosophisch: Sie brauchen eine Annahme, einen Sichtungsprozess, eine SLA-Uhr, einen Koordinationskanal und einen Prüfpfad – und Sie brauchen sie vor September. Das alles unter Zeitdruck von Grund auf aufzustellen, ist die Falle. Die CSIRT-Sparte von Kit ist genau diese operative Schicht, und sie deckt sich fast eins zu eins mit dem, was die Verordnung verlangt.

- **Öffentliche VDP-Annahme.** Ein Live-Sicherheitsportal plus eine generierte `security.txt` nach RFC 9116 (mit Feldern für Kontakt, Richtlinie, Danksagungen und Verschlüsselung) liefert Ihnen die zentrale Anlaufstelle nach Artikel 13(17) und die veröffentlichte CVD-Richtlinie in einem Zug. Das ist dasselbe Fundament, das wir in [So richten Sie ein Schwachstellen-Offenlegungsprogramm ein](/blog/how-to-set-up-vulnerability-disclosure-program) behandelt haben – jetzt mit einer rechtlichen Frist im Nacken.
- **Geltungsbereichsprüfung.** Ein konfigurierbarer Geltungsbereich (Ziele im Geltungsbereich, Kategorien außerhalb des Geltungsbereichs, ausgeschlossene Schwachstellentypen) plus automatische Geltungsbereichsprüfung bei der Annahme liefert Ihnen die dokumentierte Richtlinie, die der Gesetzestext verlangt, und die Grundlage, um Meldungen schon beim Eingang zu validieren.
- **Schweregrad-Sichtung.** Eingebauter Schweregrad-Vorschlag, Bewertung und Duplikaterkennung bilden den Sichtungsschritt, der eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall erkennt – den präzisen Auslöser der Behörden-Uhr.
- **SLA-Tracking.** Ein Live-Timer mit schweregradbasierten Zielen und Compliance-Kennzahlen liefert Ihnen die Uhr und den Beleg, dass Sie sie eingehalten haben. Die Standard-SLAs von Kit für Bestätigung und Behebung greifen den Behörden-Takt bewusst auf – sind aber Best Practice, keine gesetzlichen Bestätigungsfristen.
- **Forscher-Koordination.** Threaded Messaging hält den koordinierten, vorab nicht-öffentlichen Dialog, den der Gesetzestext verlangt, an einem prüfbaren Ort zusammen.
- **Prüfbarer Meldungs-Zeitverlauf.** Eine exportierbare Chronologie macht aus „Wir haben verantwortungsvoll koordiniert“ den nachvollziehbaren Nachweis, nach dem eine Marktüberwachungsbehörde fragen kann.

Die ehrliche Einordnung zählt. Kit operationalisiert die Schicht aus Offenlegung, Koordination und Dokumentation. Es ist keine Rechtsberatung, es übermittelt nicht für Sie an die zentrale Meldeplattform, und es deckt nicht die Produktsicherheits- und Konformitätspflichten des CRA wie SBOMs und CE-Kennzeichnung ab. Dafür sprechen Sie mit Ihrer Rechtsberatung. Was Kit Ihnen gibt, ist das CVD-Rückgrat: der laufende Prozess, der dafür sorgt, dass Sie eine gemeldete Schwachstelle – oder eine, die sich als ausgenutzt herausstellt – annehmen, sichten, koordinieren und den Zeitverlauf erstellen können, statt am 11. September 2026 festzustellen, dass Sie keinen Prozess haben, an dem Tag, an dem eine Behörden-Uhr startet.

Koordinierte Offenlegung war schon immer das Richtige gegenüber den Forschern, die Ihre Schwachstellen finden. Der CRA hat sie nur zum Vertretbaren für Ihr Geschäft gemacht. Der Ablauf, der Sie zu einem guten Akteur gegenüber Forschern macht, ist derselbe Ablauf, der Sie konform macht – und der günstigste Zeitpunkt, ihn zu bauen, ist vor dem Stichtag, nicht nach der ersten ausgenutzten Schwachstelle. [Starten Sie Ihre kostenlose Testphase](/users/sign_up) und stellen Sie einen CRA-tauglichen Offenlegungsprozess auf, solange noch Luft in der Uhr ist.