Der EU Cyber Resilience Act (CRA) für Digital Health: Pflichten, Fristen und was für DiGAs und Health-Software gilt
Der Cyber Resilience Act (CRA) ist keine Zukunftsmusik mehr – er ist geltendes EU-Recht. Ab dem 11. September 2026 greifen die ersten harten Pflichten, ab dem 11. Dezember 2027 gilt die Verordnung vollständig. Für Digital-Health-Anbieter stellt sich damit eine Frage, die viele noch unterschätzen: Wo genau betrifft mich der CRA – und was ist mit meiner Software-Lieferkette?
Dieser Artikel erklärt, was der CRA verlangt, welche Fristen gelten, wie er sich zur Medizinprodukte-Regulierung (MDR) verhält und was das konkret für DiGAs, Health-Apps und ihre Zulieferer bedeutet.
Was ist der Cyber Resilience Act?
Der CRA (Verordnung (EU) 2024/2847) ist die erste horizontale EU-Verordnung, die einheitliche Cybersicherheits-Anforderungen für „Produkte mit digitalen Elementen" (Products with Digital Elements, PDE) festlegt – also für nahezu jede Hard- und Software, die auf dem EU-Markt bereitgestellt wird. Ziel ist ein durchgängiges Sicherheitsniveau über den gesamten Produktlebenszyklus, nachgewiesen über die bekannte CE-Kennzeichnung.
Zwei Dinge sind wichtig zu verstehen:
- Der CRA wirkt global: Maßgeblich ist nicht, wo ein Produkt hergestellt wird, sondern ob es auf dem EU-Markt verfügbar gemacht wird.
- Er ist direkt anwendbar in allen Mitgliedstaaten – anders als eine Richtlinie braucht es keine nationale Umsetzung.
Der Zeitplan: Was bis wann gilt
Der CRA ist am 10. Dezember 2024 in Kraft getreten und wird gestaffelt anwendbar:
- 11. Juni 2026: Die Regeln zur Notifizierung von Konformitätsbewertungsstellen gelten.
- 11. September 2026: Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle greifen – zu melden über die zentrale Single Reporting Platform bei ENISA und dem zuständigen nationalen CSIRT.
- 11. Dezember 2027: Volle Anwendung aller übrigen Anforderungen – essenzielle Sicherheitsanforderungen, Konformitätsbewertung, CE-Kennzeichnung und technische Dokumentation.
Nach dem 11. Dezember 2027 dürfen Produkte ohne CE-konforme CRA-Nachweise nicht mehr auf dem EU-Markt in Verkehr gebracht werden.
Die Kernpflichten für Hersteller
Der CRA verlangt weit mehr als ein einmaliges Sicherheits-Audit. Zu den zentralen Pflichten gehören:
- Security by Design auf Basis einer dokumentierten Risikobewertung.
- Software Bill of Materials (SBOM): eine maschinenlesbare Stückliste zumindest der obersten Abhängigkeiten, aktuell gehalten und auf Anforderung den Marktaufsichtsbehörden vorzulegen.
- Schwachstellen-Management & Security-Updates über den gesamten Support-Zeitraum, inklusive Coordinated Vulnerability Disclosure.
- Meldepflichten mit engen Fristen: Frühwarnung binnen 24 Stunden, vollständige Meldung binnen 72 Stunden, Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme (bzw. ein Monat bei schwerwiegenden Vorfällen).
- Konformitätsnachweise: technische Dokumentation, EU-Konformitätserklärung und CE-Kennzeichnung.
Die Produkte werden dabei in Risikoklassen eingeteilt (Standard, „wichtig" und „kritisch"), mit strengeren Bewertungsverfahren für die höheren Klassen. Bei Verstößen gegen die essenziellen Anforderungen drohen Bußgelder von bis zu 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes – je nachdem, welcher Betrag höher ist.
CRA und Digital Health: Wo es für DiGAs und Health-Apps gilt
Hier liegt der entscheidende und oft missverstandene Punkt. Der CRA nimmt Produkte aus, die bereits eigenen sektoralen Regeln unterliegen – Medizinprodukte nach der MDR (Verordnung (EU) 2017/745) und In-vitro-Diagnostika nach der IVDR sind vom CRA ausgenommen, um Doppelregulierung zu vermeiden.
Das heißt aber nicht, dass Digital Health außen vor ist. Die Ausnahme greift produktbezogen, und der CRA bleibt an mehreren Stellen relevant:
- Nicht-Medizinprodukt-Software: Viele Health-Anwendungen (oder Teile davon) sind keine Medizinprodukte im regulatorischen Sinn – etwa Portale, Begleit-Apps, Verwaltungs- oder Infrastruktur-Software. Diese fallen unter den CRA.
- Remote-Datenverarbeitung und Infrastruktur: Backend-Dienste und ausgelagerte Verarbeitungslösungen können in den CRA-Anwendungsbereich fallen.
- Die Software-Lieferkette: Selbst wenn euer Hauptprodukt als Medizinprodukt der MDR unterliegt, sind die einzeln in Verkehr gebrachten Software-Komponenten eurer Zulieferer häufig CRA-pflichtig – und ihr braucht von ihnen entsprechende Nachweise.
Kurz: Der CRA betrifft Digital-Health-Anbieter selten „gar nicht" und selten „komplett", sondern gezielt an den Rändern des Medizinprodukte-Scopes – und in der Lieferkette.
Was das für eure Software-Lieferkette bedeutet
Der CRA macht Cybersicherheit zu einer Frage der Lieferketten-Sorgfalt. Wer Komponenten Dritter integriert, muss sich auf deren CRA-Konformität verlassen können – und das dokumentieren. In der Praxis heißt das: Zulieferer müssen CRA-Konformitätsnachweise (bzw. belastbare Compliance-Roadmaps), SBOMs und technische Dokumentation liefern, damit ihr eure eigene Sorgfaltspflicht erfüllen könnt.
Ein Baustein, der in nahezu jeder Digital-Health-Anwendung steckt, ist das Identitäts- und Zugriffsmanagement. Wird dieser über einen bereits CRA-konform entwickelten Dienst abgedeckt, entfällt für euch ein sicherheitskritischer Teil der Lieferketten-Nachweise. Die sicherheitsbezogenen Anforderungen überschneiden sich hier auch mit der BSI TR-03161, die für DiGAs ohnehin gilt.
CRA-Compliance operativ umsetzen
Der eigentliche Aufwand steckt nicht im Verstehen der Verordnung, sondern in ihrer operativen Umsetzung: SBOMs erzeugen und aktuell halten, Schwachstellen kontinuierlich überwachen, Melde-Workflows mit 24/72-Stunden-Fristen aufsetzen, Security-Updates über den Support-Zeitraum ausliefern und die Konformitätsnachweise prüffähig dokumentieren. Für Teams, die parallel ihr Produkt bauen, ist das ein erheblicher Daueraufwand.
Wie azuma nori bei der CRA-Compliance hilft
Genau an diesem operativen Aufwand setzt azuma nori an: Eine agentischer Compliance-Workstation, die lokal auf dem Entwickler-Rechner läuft und Quellcode automatisiert gegen vordefinierte Compliance-Matrizen prüft – ohne dass der Code jemals das Gerät verlässt. Für den Cyber Resilience Act bietet nori bereits heute 31 vordefinierte Controls, die typische CRA-relevante Anforderungen an Produkte mit digitalen Elementen automatisiert im Code nachvollziehen.
Damit ergänzt nori die bestehende BSI-TR-03161-Abdeckung um die horizontale EU-Produktsicherheitsebene – gerade für Teams, die sowohl ihr Hauptprodukt als auch die Software-Lieferkette im Blick behalten müssen. Wie bei jeder nori-Analyse bleibt der Quellcode dabei vollständig lokal; ausgewertet wird über LLM Sub-Agents, die ihr selbst konfiguriert (Claude, OpenAI, Gemini oder ein eigenes On-Premise-Modell).
Die CRA-Prüfung ist in nori aktuell als Beta verfügbar — ausprobieren lässt sie sich über den kostenlosen Self-Service Test-Zugang mit einem kuratierten Control-Satz.
Häufige Fragen
Gilt der Cyber Resilience Act auch für DiGAs?
Es kommt darauf an. Ist die DiGA ein Medizinprodukt nach MDR, ist sie vom CRA ausgenommen (keine Doppelregulierung). Nicht-Medizinprodukt-Software, Remote-Datenverarbeitung sowie die Software-Lieferkette können jedoch sehr wohl unter den CRA fallen.
Ab wann muss ich den CRA einhalten?
Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle gelten ab dem 11. September 2026. Alle übrigen Anforderungen – inklusive CE-Kennzeichnung und Konformitätsbewertung – gelten ab dem 11. Dezember 2027.
Was ist eine SBOM und brauche ich sie?
Eine Software Bill of Materials ist eine maschinenlesbare Stückliste der Software-Komponenten eines Produkts. Der CRA verlangt mindestens die Erfassung der obersten Abhängigkeiten, aktuell gehalten und auf Anforderung für die Marktaufsicht verfügbar.
Wie hängt der CRA mit der BSI TR-03161 zusammen?
Beide adressieren Produktsicherheit, aus unterschiedlichen Richtungen: Die BSI TR-03161 ist die health-spezifische Sicherheitsrichtlinie (u.a. für DiGAs), der CRA die horizontale EU-Produktcybersicherheit. In der Praxis überschneiden sich viele Maßnahmen – etwa Schwachstellen-Management und sichere Update-Prozesse.
Was passiert bei Nichteinhaltung?
Bei Verstößen gegen die essenziellen Sicherheitsanforderungen drohen Bußgelder von bis zu 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes.
Ihr wollt wissen, wie viel CRA-Abdeckung euer Code heute schon hat? Sichert euch kostenlosen Test-Zugang zu azuma nori oder vereinbart ein Gespräch mit unserem Team.
Stand: Juli 2026. Der CRA wird über Durchführungs- und delegierte Rechtsakte sowie harmonisierte Normen weiter konkretisiert – bitte vor Veröffentlichung den aktuellen Stand der Fristen und Detailvorgaben gegenchecken.