CRA-Meldepflicht 2026: Wer entscheidet in den ersten 24 Stunden?

Ein Softwarehersteller erhält am Freitagnachmittag einen Hinweis auf eine aktiv ausgenutzte Schwachstelle. Der Support kennt betroffene Versionen, das Entwicklungsteam prüft den Fehler, doch niemand kann verbindlich sagen, ob das Produkt in den Anwendungsbereich des Cyber Resilience Act fällt, welche Nutzer informiert werden müssen und wer eine Meldung freigibt. Ab dem 11. September 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle; die übrigen Hauptpflichten des CRA greifen überwiegend später. Gerade diese gestaffelte Anwendung macht einen frühen, begrenzten Auftrag sinnvoll. Kaufbar ist kein pauschales „CRA-Zertifikat“, sondern ein Meldebereitschafts-Check für eine Produktfamilie : Anwendungsbereich, Signalwege, Zeitlinie, Rollen, Datenfelder und ein simulierter Fall. Diese Lektüre zeigt, wie daraus eine verantwortbare Akquisitionsstrategie entsteht, ohne jede Sicherheitslücke zum meldepflichtigen Ereignis zu erklären oder die spätere Produktkonformität vorwegzunehmen.

Ab dem 11. September 2026 müssen Hersteller im CRA-Anwendungsbereich aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle nach Artikel 14 melden. Die erste Warnung kann binnen 24 Stunden erforderlich sein, weitere Informationen folgen gestuft. Die allgemeinen Produktanforderungen gelten überwiegend erst ab dem 11. Dezember 2027.

Die Europäische Kommission und das Bundesamt für Sicherheit in der Informationstechnik unterscheiden klar zwischen der Meldepflicht 2026 und der vollständigen Anwendung 2027. Unternehmen benötigen deshalb jetzt einen belastbaren Signal- und Entscheidungsprozess, dürfen aber nicht so tun, als sei damit bereits jede Konformitätsanforderung erfüllt.

Zuerst werden Produkte mit digitalen Elementen, ihre direkte oder indirekte Datenverbindung, Herstellerrolle und gesetzliche Ausnahmen abgegrenzt. Medizinprodukte, bestimmte Fahrzeuge und weitere sektoral geregelte Produkte können ausgenommen sein. Vertrieb, Import oder Integration machen ein Unternehmen nicht automatisch zum Hersteller; Änderungen und Vermarktung unter eigenem Namen können die Rolle beeinflussen.

Ein SaaS-Dienst, eine eingebettete Komponente und ein lokal installiertes Produkt können unterschiedliche Fragen auslösen. Der Check dokumentiert daher Produktversion, Bereitstellungsmodell, Verantwortlichen und relevante Lieferkette. Unklare Fälle werden nicht aus Marketinggründen in den Anwendungsbereich gezogen.

Besondere Aufmerksamkeit verdient die Herstellerrolle bei White-Label-Produkten und wesentlichen Änderungen. Ein Unternehmen kann fremde Komponenten verwenden und dennoch für das vermarktete Gesamtprodukt verantwortlich sein. Umgekehrt gehört nicht jeder interne Dienst in den CRA. Die Produktliste verknüpft deshalb Handelsname, technische Version, verantwortliche Gesellschaft, Marktbereitstellung und mögliche Ausnahme. So lässt sich ein eingehendes Signal dem richtigen Entscheidungsweg zuordnen, bevor die Uhr einer möglichen Meldung abläuft.

Der erste bezahlbare Auftrag ist ein Meldebereitschafts-Check für eine Produktfamilie. Er prüft Scope, Eingangskanäle, Schwellen, Rollen, erreichbare Daten und Freigaben; anschließend simuliert das Team einen Fall von der Meldung bis zur Kundeninformation. Das Ergebnis ist ein Maßnahmenplan, kein Konformitätszertifikat und keine Garantie für eine Behördenentscheidung.

Der Auftrag kann innerhalb von dreißig Tagen abgeschlossen werden, wenn Produktverantwortliche, Sicherheitsdaten und Entscheider verfügbar sind. Preis, Produktzahl, technische Tiefe und juristische Begleitung werden im Auftragsrahmen mit dem Partner festgelegt. Fehlen Zuständigkeit oder Ereignisprotokolle, ist der richtige Ausgang ein engerer Vorauftrag.

Ein Sicherheitssignal wird belastbar, wenn Eingang, Quelle, betroffene Produkte, bekannte Ausnutzung, Sicherheitsauswirkung und Zeitpunkt nachvollziehbar sind. Technik bewertet das Signal, Recht und Compliance ordnen die Pflicht ein, die Produktverantwortung bestätigt den Scope, und eine benannte Stelle gibt Meldung und Kommunikation frei.

Nicht jedes Ticket ist ein Vorfall; nicht jede Schwachstelle ist aktiv ausgenutzt. Trotzdem darf Unsicherheit nicht zum Stillstand führen. Der Prozess dokumentiert Annahmen, offene Belege und nächste Frist. Änderungen der Bewertung werden versioniert. Dadurch bleibt sichtbar, warum eine Meldung erfolgte, ergänzt oder verworfen wurde.

Die Übung sollte mindestens drei schwierige Übergaben testen: vom externen Hinweis zum Product Security Team, von der technischen Analyse zur rechtlichen Einordnung und von der Freigabe zur Plattform. Außerhalb der Bürozeiten braucht jede Rolle eine erreichbare Vertretung. Der Test misst nicht nur Geschwindigkeit, sondern auch Informationsqualität. Eine schnelle, aber unbelegte Einstufung ist ebenso wenig belastbar wie eine vollständige Analyse nach Ablauf der ersten Frist.

Seriöse Kaufsignale sind vernetzte Produkte, ein öffentliches Sicherheitskontaktfeld, neue Produktlinien, internationale Vermarktung, fehlende 24-Stunden-Rufbereitschaft oder ein geplantes Vulnerability-Disclosure-Programm. Sie zeigen möglichen Vorbereitungsbedarf, aber keinen Verstoß. Die Ansprache bietet einen simulierten Prozesscheck statt einer Angstkampagne.

Fachinhalte zu Artikel 14, Rollen und Zeitlinien erreichen aktive Suche. Produkt- und Branchenverbände schaffen Vertrauen. Gezielte Ansprache funktioniert nur bei erkennbarer Marktrolle; eine beliebige Firmenliste ohne Produktbezug verschwendet Fachkapazität.

Der CRA richtet sich an Produkte mit digitalen Elementen und ihre Herstellerpflichten. NIS 2 ordnet betroffene Einrichtungen und ihre Sicherheitsorganisation; DORA betrifft Finanzunternehmen und deren IKT-Dienstleistungsbeziehungen. Dasselbe Unternehmen kann mehrere Regime berühren, doch Scope, Meldetatbestand, Adressat und Nachweis dürfen nicht in einem Universalpaket vermischt werden.

Nach der Hälfte ergänzt die NIS-2-Lektüre die Einrichtungs- und Managementperspektive. Die DORA-Lektüre behandelt Finanzkunden, Register und IKT-Verträge. Der CRA-Check bleibt produktbezogen und verkauft weder NIS-2-Registrierung noch DORA-Vertragsprüfung unter anderem Namen.

Echte Meldefähigkeit zeigen Zeit bis zur Triage, Anteil eindeutig zugeordneter Produkte, erreichbare Entscheider, Vollständigkeit der Pflichtfelder und dokumentierte Übungen. Für den Anbieter zählen bezahlte Checks, geschlossene Maßnahmen und Folgeaufträge. Anzahl gescannter Schwachstellen oder versandter Warnmails beweist allein keine Meldebereitschaft.

Ausgangswerte werden vor der Übung erfasst. Ein Testfall erhält Zeitstempel und feste Annahmen. Nach der Übung wird nur verglichen, was mit derselben Definition gemessen wurde. Reale Schwachstellen, Kunden und Produktdaten bleiben vertraulich; öffentliche Darstellungen enthalten keine beobachteten Ergebnisse.

Für die Angebotskalkulation zählen Zahl der Produktfamilien, unterstützte Versionen, internationale Verantwortungen, notwendige Rufbereitschaft und Tiefe der technischen Analyse. Ein kleiner Hersteller mit einem klaren Produkt kann schneller entscheiden als eine Gruppe mit vielen Marken und übernommenen Komponenten. Der Partner muss diese Unterschiede vor der Kampagne in Qualifikationsfragen übersetzen. Sonst erzeugt hohes Leadvolumen genau in dem Moment Überlastung, in dem ein Sicherheitsereignis Fachkapazität bindet.

Vor dem Skalieren führt der Partner einen internen Musterfall mit echter Produktdokumentation und fiktivem Ereignis durch. Dabei werden Nacht- und Wochenendkontakt, Vertretung, Plattformzugang, Kundenkommunikation und technische Nachweise geprüft. Aus den Engpässen entstehen klare Ablehnungsregeln für die Akquisition. Ein Anbieter ohne erreichbare Produktverantwortung oder sichere Fallablage ist nicht kampagnenbereit. Erst wenn der simulierte Fall innerhalb der vereinbarten Zeit zu einer nachvollziehbaren Entscheidung führt, werden Kanäle, Zielsegmente und Budget ausgeweitet.

Eine laufende Leistung entsteht durch neue Produkte, Komponenten, Meldeleitlinien, Organisationsänderungen und regelmäßige Übungen. Sie entsteht nicht durch einen unveränderten Bericht ohne Entscheidung. Jeder Zyklus braucht einen definierten Testfall, neue Evidenz oder einen geänderten Scope und endet mit akzeptierter Maßnahme oder begründetem Stopp.

Ein Quartalsrhythmus kann für dynamische Portfolios sinnvoll sein; bei einem stabilen Einzelprodukt genügt möglicherweise eine jährliche oder anlassbezogene Übung. Wiederkehrender Umsatz folgt dem tatsächlichen Änderungs- und Prüfbedarf.

Die Verordnung (EU) 2024/2847, die CRA-Seiten der Europäischen Kommission, die Hinweise des BSI und dessen technische Richtlinie TR-03183 begrenzen diese Lektüre. Sie legen Termine, Rollen und Anforderungen fest, liefern aber keine automatische Produktklassifizierung, keine Meldentscheidung für einen Einzelfall und keine kommerzielle Erfolgszahl.

Die offiziellen Adressen bleiben im privaten Recherchepaket. Vor jeder Kampagne werden Kommissionsleitlinien, Plattformbetrieb und deutsche Zuständigkeiten erneut geprüft. Diese Lektüre ersetzt weder technische Incident Response noch Rechtsberatung.

Der kostenfreie Eignungstest prüft Produktfokus, ersten bezahlten Check, Fachgrenzen, Datensicherheit und Lieferkapazität. Er zeigt, ob getfishnet mit Ihrem Team eine maßgeschneiderte Akquisitionsstrategie für CRA-Meldebereitschaft entwickeln kann. Bei unklarem Scope oder fehlender Fachverantwortung lautet das Ergebnis konsequent „noch nicht geeignet“.

Fachstand: 7. August 2026. Veröffentlichung, CMS-Import und Übersetzung bleiben bis zur menschlichen Freigabe gesperrt.