PEC Healthcare Perspektiven

Cyber Resilience Act: Ab 11. September 2026 zählt nicht nur Sicherheit, sondern Meldefähigkeit

Der Cyber Resilience Act wird häufig als Regelwerk für Ende 2027 wahrgenommen. Für Hersteller digitaler Produkte beginnt ein entscheidender Teil jedoch früher: Ab dem 11. September 2026 müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gemeldet werden. Damit wird aus technischem Schwachstellenmanagement ein verbindlicher Organisationsprozess mit sehr kurzen Reaktionszeiten.

Die erste Frist kommt vor der vollständigen Anwendung

Der Cyber Resilience Act ist am 10. Dezember 2024 in Kraft getreten. Die wesentlichen Produktanforderungen gelten grundsätzlich ab dem 11. Dezember 2027. Die Europäische Kommission weist die Meldepflichten jedoch bereits ab dem 11. September 2026 aus.

Betroffen sind Hersteller von „Produkten mit digitalen Elementen“, also grundsätzlich kommerziell bereitgestellte Hard- und Software mit direkter oder indirekter Verbindung zu Geräten oder Netzwerken. Im Healthcare-Umfeld kann das unter anderem Anbieter von Plattformen, Anwendungen, Komponenten und verbundenen Systemen betreffen.

Medizinprodukte und In-vitro-Diagnostika, auf die die MDR beziehungsweise IVDR Anwendung findet, sind nach Artikel 2 Absatz 2 ausdrücklich vom Anwendungsbereich des CRA ausgenommen. Bei Plattformen, allgemeiner Software, Infrastrukturkomponenten und verbundenen digitalen Diensten im Healthcare-Umfeld muss die Einordnung dagegen produktbezogen erfolgen.

Wichtig: Die Meldepflichten gelten nicht nur für neue Produkte. Artikel 69 Absatz 3 erfasst grundsätzlich auch Produkte im CRA-Anwendungsbereich, die bereits vor dem 11. Dezember 2027 in Verkehr gebracht wurden.

24 Stunden, 72 Stunden und ein belastbarer Abschlussbericht

Die Europäische Kommission beschreibt für meldepflichtige Fälle einen gestuften Ablauf:

  • Innerhalb von 24 Stunden nach Kenntnis des Herstellers ist eine Frühwarnung abzugeben.
  • Innerhalb von 72 Stunden nach Kenntnis des Herstellers folgt – sofern die relevanten Informationen nicht bereits vollständig übermittelt wurden – eine vertiefte Meldung. Je nach Fall umfasst sie verfügbare Informationen zum betroffenen Produkt, zur allgemeinen Art des Exploits beziehungsweise der Schwachstelle oder zur Art und ersten Bewertung des Vorfalls sowie bereits ergriffene oder empfohlene Korrektur- und Abhilfemaßnahmen.
  • Bei einem Sicherheitsvorfall folgt der Abschlussbericht spätestens einen Monat nach Abgabe der 72-Stunden-Meldung.
  • Bei einer aktiv ausgenutzten Schwachstelle gilt für den Abschlussbericht eine separate Frist: spätestens 14 Tage, nachdem eine Korrektur- oder Abhilfemaßnahme verfügbar ist.

Gemeldet wird über die von ENISA aufgebaute zentrale CRA-Meldeplattform. Sie soll zum 11. September 2026 betriebsbereit sein. Die Meldung wird an das zuständige Computer Security Incident Response Team adressiert und grundsätzlich auch ENISA zugänglich gemacht.

Warum das auch Krankenhäuser und Gesundheitsunternehmen betrifft

Die unmittelbare Meldepflicht liegt beim jeweiligen Hersteller. Krankenhäuser, MVZ, Gesundheitsunternehmen und andere Betreiber digitaler Systeme bleiben dennoch Teil des Prozesses. Sicherheitsvorfälle werden häufig zuerst im Betrieb erkannt. Ohne klare Kontaktwege, vertragliche Regelungen und verwertbare Protokolldaten kann der Hersteller die engen Fristen kaum einhalten.

Für Beschaffung und Lieferantensteuerung entsteht damit eine neue Qualitätsfrage: Nicht nur „Ist das Produkt sicher?“, sondern auch „Kann der Anbieter einen Vorfall innerhalb weniger Stunden erkennen, einordnen und regelkonform melden?“

Besonders kritisch sind unklare Verantwortlichkeiten zwischen Hersteller, Hosting-Partner, IT-Dienstleister und Betreiber. Wenn jeder nur einen Ausschnitt sieht, entsteht genau dort Zeitverlust, wo die Regulierung schnelle und belastbare Informationen verlangt.

CRA und NIS2: Wo liegt der Unterschied?

Der CRA und NIS2 adressieren unterschiedliche Ebenen der Cybersicherheit. Der Cyber Resilience Act stellt Anforderungen an Produkte mit digitalen Elementen und richtet die hier beschriebenen Meldepflichten an deren Hersteller. NIS2 verpflichtet dagegen erfasste Einrichtungen und Unternehmen bestimmter Sektoren zu Cyberrisikomanagement und organisatorischer Reaktionsfähigkeit.

In der Praxis können sich beide Regime in der Lieferkette berühren: Ein Krankenhaus kann als NIS2-Einrichtung Sicherheitsvorfälle organisatorisch bewältigen müssen, während ein Hersteller für ein betroffenes digitales Produkt parallel CRA-Pflichten erfüllt. Entscheidend sind deshalb abgestimmte Rollen, Meldewege und belastbare Informationen zwischen Betreiber und Hersteller.

Was jetzt vorbereitet sein sollte

  1. Produkt- und Rollenklärung: Welche digitalen Produkte werden selbst hergestellt oder unter eigener Marke angeboten? Wo ist die Organisation lediglich Betreiber, Importeur, Distributor oder Dienstleister?
  2. Meldekette definieren: Wer bewertet eine Schwachstelle, wer entscheidet über die Meldung und wer stellt innerhalb von 24 beziehungsweise 72 Stunden die benötigten Informationen zusammen?
  3. Lieferantenprozesse prüfen: Verträge und Eskalationswege sollten sicherstellen, dass Betreiber, Hersteller und technische Partner relevante Vorfälle unverzüglich austauschen.
  4. Probelauf durchführen: Ein Tabletop-Test mit einem realistischen Schwachstellen- oder Vorfallszenario zeigt, ob Erkennung, Bewertung, Kommunikation und Dokumentation tatsächlich innerhalb der Fristen funktionieren.

Häufige Fragen zum Cyber Resilience Act

Gilt der Cyber Resilience Act für Krankenhäuser?

Nicht allein aufgrund des Krankenhausbetriebs. Die unmittelbaren Pflichten des CRA treffen vor allem Hersteller und weitere Wirtschaftsakteure von Produkten mit digitalen Elementen. Krankenhäuser können jedoch mittelbar über Beschaffung, Lieferantenkommunikation und die Erkennung von Vorfällen beteiligt sein – oder unmittelbar, wenn sie selbst ein erfasstes Produkt entwickeln und unter eigenem Namen in Verkehr bringen.

Fallen Medizinprodukte unter den CRA?

Produkte mit digitalen Elementen, auf die die MDR oder IVDR Anwendung findet, sind nach Artikel 2 Absatz 2 vom CRA ausgenommen. Für allgemeine Software, Plattformen, Infrastrukturkomponenten und verbundene Dienste im Healthcare-Umfeld ist die Einordnung dagegen produktbezogen vorzunehmen.

Welche CRA-Meldepflichten gelten ab 11. September 2026?

Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle grundsätzlich binnen 24 Stunden früh melden und binnen 72 Stunden vertiefte Informationen nachreichen, sofern diese nicht bereits vollständig vorliegen. Danach gelten je nach Fall die Fristen für den jeweiligen Abschlussbericht.

Was ist der Unterschied zwischen CRA und NIS2?

Der CRA fokussiert die Cybersicherheit digitaler Produkte und die Pflichten ihrer Hersteller. NIS2 fokussiert das Cyberrisikomanagement erfasster Einrichtungen und Unternehmen bestimmter Sektoren. In Lieferketten können beide Regelwerke gleichzeitig relevant sein.

Fazit: Compliance beginnt mit operativer Reaktionsfähigkeit

Der Cyber Resilience Act verlangt nicht nur sichere Produktentwicklung. Ab September 2026 wird sichtbar, ob Unternehmen Schwachstellen und Vorfälle unter Zeitdruck strukturiert bearbeiten können. Wer erst beim ersten realen Angriff Rollen, Zuständigkeiten und Informationswege klärt, verliert wertvolle Stunden.

Für Healthcare-Organisationen ist die Konsequenz eindeutig: Cybersecurity muss über Produkt-, Lieferanten- und Betriebsgrenzen hinweg organisiert werden. Meldefähigkeit ist damit keine reine Rechtsfrage, sondern ein Test der operativen Resilienz.

Nächster Schritt

Meldekette und Lieferantenschnittstellen testen

Ein sicherer Einstieg ist ein zeitlich begrenzter Tabletop-Test mit Rollen-, Informations- und Eskalationsprüfung – ohne daraus bereits eine Rechts- oder Compliance-Feststellung abzuleiten.

Cyberresilienz und Meldefähigkeit einordnen

Primärquellen und Gültigkeitsgrenze

Stand: 26. August 2026. Der konkrete Healthcare-Bezug einschließlich möglicher sektoraler Ausnahmen muss produktbezogen geprüft werden. Diese Einordnung ist keine Rechtsberatung. Sie wird bei Änderungen des Rechtsakts, der Plattform oder offizieller Leitlinien erneut geprüft.