CRA zwingt Hersteller zur Meldung binnen 24 Stunden

Am 11. September 2026 greift Artikel 14 des Cyber Resilience Act. Ab diesem Tag müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle binnen fester Fristen melden. Für CIOs und CDOs liegt die eigentliche Nachricht im Einkauf: Die Meldepflicht gilt für den Hersteller. Wer Produkte von Herstellern bezieht, deren Prozesse noch nicht stehen, erfährt von einer aktiv ausgenutzten Schwachstelle im eigenen Bestand zu spät oder gar nicht.

VerwandtEU Data Act: Switching-Pflichten für Cloud-Portfolios  /  KI-Verordnung: bis zu 3 Prozent vom Konzernumsatz

Vier Wochen bis Artikel 14: Die Lage für den Einkauf

Der Cyber Resilience Act ist am 10. Dezember 2024 in Kraft getreten. Die Hauptpflichten gelten ab dem 11. Dezember 2027. Dazwischen liegt der Stichtag, der den Betrieb jetzt beschäftigt: Artikel 14 greift am 11. September 2026. In größeren Organisationen steuern CIOs, CDOs und IT-Strategen Budgets, Lieferantenbeziehungen und Architekturentscheidungen. Genau dort landet die Wirkung der Meldepflicht, obwohl die Organisation selbst in der Regel nicht meldepflichtig ist.

Was ist der Cyber Resilience Act? Der Cyber Resilience Act ist ein EU-Rechtsrahmen für die Cybersicherheit von Produkten mit digitalen Elementen. Er verpflichtet Hersteller zu Sicherheitsanforderungen über den Lebenszyklus und zu Meldepflichten bei aktiv ausgenutzten Schwachstellen sowie bei schweren Sicherheitsvorfällen. Der CRA ist am 10. Dezember 2024 in Kraft getreten. Artikel 14 gilt ab dem 11. September 2026, die Hauptpflichten ab dem 11. Dezember 2027.

Für den CIO ist die Zuordnung der Pflichten die zentrale Botschaft. Die Meldepflicht trifft den Hersteller. Der Betreiber kauft Produkte, die in Netzen, Steuerungen und Fachanwendungen laufen. Wenn der Hersteller seine Melde- und Informationswege nicht beherrscht, fehlt dem Betrieb die rechtzeitige Information über aktiv ausgenutzte Schwachstellen im eigenen Bestand. Die Handlungsperspektive liegt deshalb in Verträgen, Lieferantengesprächen und der Steuerung der Lieferkette.

Wer meldet, wohin und wofür der Hersteller haftet

Hersteller müssen gleichzeitig an die koordinierende CSIRT und an die ENISA melden. Dafür steht eine gemeinsame Meldeplattform. Technische Details dieser Plattform sind öffentlich noch nicht geklärt. Für den Betrieb zählt der Ablauf in der Lieferbeziehung: Der Hersteller bleibt der Adressat der Meldepflicht und der Ansprechpartner für den Käufer.

Die Verantwortung endet nicht an der Stückliste des Herstellers. Der Hersteller bleibt für die Gesamtkomponente verantwortlich, auch wenn er Teile einkauft. Die Fristen von 24 und 72 Stunden gelten für den Hersteller. Sie gelten nicht pauschal für jeden Lieferanten in der Kette. Wer als CIO eine mehrstufige Lieferkette steuert, muss deshalb klären, wie Informationen vom Unterlieferanten zum Hersteller und vom Hersteller in den eigenen Betrieb gelangen.

Auch das Supportende ändert die Verantwortungszuordnung nur begrenzt. Bei Supportende einer Komponente bleibt der Hersteller für die Schwachstellenbehebung verantwortlich, mindestens fünf Jahre. Für Architekturen mit langen Betriebszeiten bedeutet das: Ein Produkt, das aus dem aktiven Support fällt, fällt damit nicht aus der Sicherheitsverantwortung des Herstellers. In Beschaffungsentscheidungen gehört dieses Zeitfenster in die Bewertung von Produktlebenszyklus und Ersatzstrategie.

Fristen, Meldeinhalte und Sanktionen

Artikel 14 trennt zwei Fälle: aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle. Beide Pfade beginnen mit einer Frühwarnung binnen 24 Stunden. Die Fristen richten sich an den Hersteller. Für den Betreiber gelten diese Stundenfristen nicht als eigene gesetzliche Meldepflicht aus Artikel 14. Sie markieren dennoch die Geschwindigkeit, mit der Informationen im Herstellerumfeld laufen müssen, wenn der eigene Bestand betroffen ist.

Bei aktiv ausgenutzten Schwachstellen folgen weitere Informationen binnen 72 Stunden und ein Abschlussbericht binnen 14 Tagen nach Verfügbarkeit einer Korrekturmaßnahme. Bei schweren Sicherheitsvorfällen folgen die Vorfallmeldung binnen 72 Stunden und der Abschlussbericht binnen eines Monats nach der Vorfallmeldung. Wer als CIO mit Herstellern über Incident- und Vulnerability-Prozesse spricht, braucht diese Stufen als Gesprächsgrundlage: Wann erfährt der Kunde von der Frühwarnung, wann von der Folgemeldung, wann von der Korrekturmaßnahme?

Der CRA sieht Geldbußen bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes vor. Die Sanktion trifft den Adressaten der Pflichten, also den Hersteller in der Meldelogik von Artikel 14. Für den einkaufenden CIO ändert die Bußgeldhöhe die Verhandlungsmacht: Ein Hersteller mit unklaren Prozessen trägt ein regulatorisches Risiko, das in der Lieferbeziehung als Ausfall-, Verzögerungs- und Informationsrisiko ankommt. Prognosen zur Durchsetzungspraxis der Behörden gehören nicht in die Planung, weil sie hier nicht belegt sind. Belegt sind die Fristen, die Adressaten und der Sanktionsrahmen.

Was jetzt in Verträge und Lieferantengespräche gehört

Eine allgemeine Zusicherung von Gesetzestreue reicht nicht. In Lieferantenverträge gehören Nachweise, Meldewege, Updates und ein definiertes Supportende. Diese Punkte sind als Anforderung belegt. Konkrete Vertragsklauseltexte als amtliches Muster gibt es nicht. Einkauf, Legal und Security müssen die Anforderungen in die eigene Vertragssprache übersetzen und sie in bestehende Lieferantenbeziehungen nachziehen.

Nachweise klären, ob der Hersteller seine CRA-relevanten Prozesse überhaupt steuert. Meldewege klären, wie der Betrieb von einer aktiv ausgenutzten Schwachstelle erfährt und wer intern die Information empfängt. Updates klären, wie Korrekturmaßnahmen bereitgestellt und dokumentiert werden. Ein definiertes Supportende klärt, ab wann der aktive Support endet und wie die mindestens fünfjährige Verantwortung für die Schwachstellenbehebung nach Supportende in der Beziehung abgebildet wird.

In Lieferantengesprächen eignet sich ein einfacher Prüfrahmen. Wer ist im Herstellerunternehmen für die Meldung an die koordinierende CSIRT und die ENISA zuständig? Wie gelangt die Information parallel in den Kundenkanal? Welche Unterlieferanten fließen in die Gesamtkomponente ein, für die der Hersteller verantwortlich bleibt? Wie lange läuft der Support und wie ist die Behebungspflicht danach organisiert? Diese Fragen bleiben im Rahmen des Belegten und vermeiden Spekulation über behördliche Praxis oder Umsetzungskosten.

Architekturentscheidungen hängen an denselben Punkten. Produkte mit unklarem Supportende, undeutlichen Updatepfaden oder fehlenden Meldewegen erhöhen das Betriebsrisiko. Artikel 14 verpflichtet den Hersteller zur Meldung aktiv ausgenutzter Schwachstellen und schwerer Vorfälle an das koordinierende CSIRT und an ENISA. Betroffene Nutzer sind parallel zu informieren. Supportende und Updatepfade regeln andere Teile des CRA. Der CIO steuert das Risiko über Auswahl, Vertragsgestaltung und Eskalationswege, auch wenn die gesetzliche Meldepflicht beim Hersteller liegt.

Die Gegenposition: Belastung kleiner und mittlerer Hersteller

Der DIHK warnt vor erheblichen Belastungen für kleine und mittlere Unternehmen durch die CRA-Umsetzung. Viele kleinere Hersteller wissen nicht, ob der CRA für sie überhaupt gilt. Einzelne erwägen, Produkte vom Markt zu nehmen. Für den CIO ist das kein abstrakter Mittelstandsbericht. Es ist ein Beschaffungsproblem, sobald ein Nischenlieferant aussteigt oder sein Portfolio bereinigt.

In größeren Organisationen sitzen oft Spezialkomponenten: Steuerungsmodule, Sensorik, Branchensoftware, eingebettete Systeme. Wenn ein kleiner Hersteller die CRA-Pflichten als zu schwer bewertet und ein Produkt einstellt, fehlen Ersatz, Know-how und Migrationspfad. Die Handlungsperspektive liegt darin, kritische Nischenlieferanten früh zu identifizieren, deren CRA-Fähigkeit zu prüfen und Alternativen oder Übergangsstrategien vorzubereiten.

Die Gegenposition gehört deshalb in jedes Lieferantengespräch mit kleineren Anbietern. Die Frage lautet, ob der Hersteller die Melde- und Sicherheitsprozesse bis zum 11. September 2026 und zu den Hauptpflichten ab dem 11. Dezember 2027 tragen kann. Wenn die Antwort unklar bleibt, steigt das Risiko eines Produktabbruchs. Der Betrieb trägt dann die Folgen in Architektur und Betriebskontinuität, auch wenn er selbst außerhalb der Meldepflicht steht.

Orientierung an der BSI TR-03183 und nächste Schritte

Die technische Richtlinie BSI TR-03183 bündelt Anforderungen in drei Teilen: allgemeine Anforderungen, Software-Stückliste und Schwachstellenmeldungen. Teil 1 und Teil 3 liegen in Version 1.0.0 vor. Teil 2 liegt in Version 2.1.0 vor. Die erste Kommentierungsphase endete am 30. November 2024. Teil 1 führt das BSI seither als lebendes Dokument, Teil 3 erschien im September 2025. Die Fassungen 0.9.0 und 2.0.0 stehen nur noch im Archiv.

Für CIOs und IT-Strategen ist die Richtlinie ein Orientierungsrahmen in Gesprächen mit Herstellern, die Produkte mit digitalen Elementen liefern. Allgemeine Anforderungen, Software-Stückliste und Schwachstellenmeldungen bilden die Themen, an denen sich Nachweise und Prozesse festmachen lassen. Wer die Versionsstände kennt, vermeidet falsche Erwartungen: Alle drei Teile sind freigegeben, Teil 1 wird als lebendes Dokument laufend fortgeschrieben.

Die nächsten Wochen bis zum 11. September 2026 eignen sich für eine gezielte Lieferantenrunde. Priorisieren Sie Produkte mit hoher Betriebsrelevanz und langer Lebensdauer. Fordern Sie Nachweise, Meldewege, Updatezusagen und ein definiertes Supportende. Klären Sie die Rollen in der Kette, weil die 24- und 72-Stunden-Fristen den Hersteller treffen und der Hersteller für die Gesamtkomponente verantwortlich bleibt. Beobachten Sie kleinere Lieferanten auf Anzeichen, dass Produkte vom Markt genommen werden. So steuern Sie das Risiko, bevor Artikel 14 greift und bevor die Hauptpflichten ab dem 11. Dezember 2027 die nächste Stufe setzen.

Häufig gestellte Fragen

Mehr aus dem MBF Media Netzwerk

Bildquelle: KI-generiert (August 2026)