Der Cyber Resilience Act (CRA) steht für einen grundlegenden Wandel von einer institutsorientierten Sicherheit hin zur Integrität der Lieferkette.
Jahrelang hat sich der Finanzsektor in seiner Verteidigung auf die operative Resilienz konzentriert – also die Stärkung der Institution selbst. Dies gipfelte im Digital Operational Resilience Act (DORA). Nun ist jedoch eine neue regulatorische Säule hinzugekommen: der EU Cyber Resilience Act (CRA). Während viele Führungskräfte den CRA als eine Verordnung für Hersteller betrachten, ist er in Wirklichkeit das „fehlende Glied” für Banken. Wenn DORA einer Bank vorschreibt, wie sie sicher fahren soll, stellt CRA sicher, dass die Komponenten des Fahrzeugs nicht von vornherein defekt sind.
Die Grundlagen
Der EU-Cyberresilienz-Akt (CRA) ist eine Verordnung, die einheitliche Cybersicherheitsanforderungen für Hardware- und Softwareprodukte einführt, die auf den EU-Markt gebracht werden, mit dem Ziel, Schwachstellen zu reduzieren und die langfristige Sicherheitsunterstützung zu verbessern.
Zweck und Ziele
- Stärkung der Cybersicherheit vernetzter Hardware- und Softwareprodukte während ihres gesamten Lebenszyklus.
- Verringerung der Anzahl und Schwere von Sicherheitslücken und Gewährleistung zeitnaher Sicherheitsupdates.
- Erhöhung der Transparenz, damit Nutzer Produkte identifizieren können, die ein angemessenes Sicherheitsniveau bieten (unter anderem durch die CE-Kennzeichnung).
Anwendungsbereich
- Gilt für„Produkte mit digitalen Elementen“ (PDE): vernetzte Hardware und Software, deren beabsichtigte oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung beinhaltet. Dazu gehören beispielsweise IoT-Geräte, Betriebssysteme, Anwendungen, Sicherheitssoftware,
Passwortmanager, VPN-Software und Webbrowser. - Gilt für Hersteller, Importeure, Händler und bestimmte Dienstleister, die solche Produkte auf dem EU-Markt in Verkehr bringen.
- Einige Branchen mit eigenen spezifischen Sicherheitsvorschriften (z. B. Medizinprodukte oder Automobilindustrie) sind ausgenommen, wenn diese Vorschriften bereits vergleichbare Risiken abdecken.
Wichtige Verpflichtungen für Hersteller
- Umsetzung von„Security by Design und Security by Default“: Cybersicherheit muss in die Konzeption, Entwicklung, Herstellung und Wartung des Produkts integriert sein.
- Durchführung und Dokumentation einer Cybersicherheits-Risikobewertung vor der Markteinführung des Produkts, die den Verwendungszweck, den vernünftigerweise vorhersehbaren Missbrauch, die Betriebsumgebung und die erwartete Lebensdauer umfasst.
- Einrichtung eines Schwachstellenmanagementprozesses, einschließlich kontinuierlicher Überwachung, Behandlung von Schwachstellen und Bereitstellung von Sicherheitspatches und Updates.
- Stellen Sie Sicherheitsupdates zeitnah bereit, ermöglichen Sie standardmäßig die automatische Installation, sofern dies sinnvoll ist, und unterscheiden Sie Sicherheitsupdates nach Möglichkeit klar von Funktionsupdates.
- Bewahren Sie technische Dokumentationen und relevante Aufzeichnungen (z. B. Risikobewertungen, Testnachweise, Prozesse zum Umgang mit Schwachstellen) mindestens 10 Jahre nach dem Inverkehrbringen des Produkts oder während des gesamten Supportzeitraums auf, je nachdem, welcher Zeitraum länger ist. Die CRA verlangt ausdrücklich von den Herstellern, dass sie als Teil der technischen Dokumentation für Produkte mit digitalen Elementen eine SBOM in einem gängigen, maschinenlesbaren Format erstellen. Eine SBOM (Software Bill of Materials) ist eine maschinenlesbare Liste aller Softwarekomponenten und Abhängigkeiten in einem Produkt.
- Stellen Sie die Konformitätsbewertung sicher, erstellen Sie eine EU-Konformitätserklärung und bringen Sie die CE-Kennzeichnung an, um die Einhaltung der CRA-Anforderungen nachzuweisen.
Meldung von Vorfällen und Schwachstellen
- Verpflichtung, ausgenutzte Schwachstellen und schwerwiegende Cybersicherheitsvorfälle innerhalb einer kurzen, festgelegten Frist nach deren Bekanntwerden den zuständigen Behörden (wie ENISA oder nationalen CSIRTs) zu melden.
- Richten Sie interne Prozesse zur Erkennung, Bewertung und Eskalation von Sicherheitsvorfällen und ausgenutzten Schwachstellen ein und stellen Sie sicher, dass diese Prozesse funktionsfähig sind, bevor die Meldepflichten in Kraft treten.
Zeitplan und Übergangsfristen
- Die CRA trat im Dezember 2024 als EU-Verordnung in Kraft.
- Ab September 2026 gelten die Meldepflichten für ausgenutzte Schwachstellen und schwerwiegende Vorfälle.
- Ab Dezember 2027 werden die wesentlichen materiellen Verpflichtungen (Sicherheitsanforderungen, Konformitätsbewertung, CE-Kennzeichnung usw.) vollständig anwendbar.
Durchsetzung und Sanktionen
- Die Marktüberwachungsbehörden in den EU-Mitgliedstaaten überwachen die Einhaltung der Vorschriften und können Korrekturmaßnahmen verlangen, darunter Produktrückrufe, Rücknahme vom Markt oder Verkaufsbeschränkungen.
- Die Nichteinhaltung kann zu erheblichen Geldbußen führen, die je nach Art und Schwere des Verstoßes bis zu einem erheblichen Prozentsatz des weltweiten Jahresumsatzes des Unternehmens oder zu einem hohen festen Geldbetrag betragen können, je nachdem, welcher Betrag höher ist.
Was bedeutet das für Finanzinstitute, die unter DORA reguliert sind?
Einige dieser Verpflichtungen kommen Ihnen vielleicht bekannt vor, aber das EU-Gesetz zur Cyberresilienz (CRA) ist eine horizontale, produktorientierte Cybersicherheitsverordnung, die neben bestehenden Rahmenwerken für den Finanzsektor wie DORA und NIS2 besteht. Es betrifft vor allem Banken, die als Hersteller oder Vertreiber von „Produkten mit digitalen Elementen” (PDE) auftreten, beispielsweise Zahlungskarten, Terminals oder Mobile-Banking-Anwendungen.
Stellung der CRA im regulatorischen Umfeld des Bankwesens
Im Gegensatz zu DORA und NIS2, die sich auf die operative Widerstandsfähigkeit, die Governance und das IKT-Risikomanagement von Finanzunternehmen konzentrieren, legt die CRA Mindestanforderungen an die Cybersicherheit für Hardware- und Softwareprodukte fest, die auf dem EU-Markt in Verkehr gebracht werden. Für Banken bedeutet dies, dass die CRA-Verpflichtungen greifen, wenn sie digitale Produkte unter ihrem eigenen Namen oder ihrer eigenen Marke auf den Markt bringen oder wenn sie solche Produkte wesentlich verändern.
Branchenverbände aus dem Finanzsektor (wie der BdB in Deutschland) haben auf das Risiko von Doppelungen hingewiesen, da sich die CRA-Anforderungen an das Schwachstellenmanagement, die sichere Entwicklung und die Meldung von Vorfällen mit den bereits im Rahmen von DORA und sektorspezifischen Richtlinien auferlegten Verpflichtungen überschneiden. Dennoch bleibt die CRA direkt anwendbar und muss in den Compliance-Rahmenwerken der Banken ausdrücklich berücksichtigt werden.
Typische CRA-relevante Produkte im Bankwesen
Banken sollten eine strukturierte Bestandsaufnahme aller Produkte mit digitalen Elementen durchführen, die sie entwickeln, vermarkten oder auf den Markt bringen. Typische Beispiele im Bankwesen sind:
- Zahlungskarten und Kartenlesegeräte, einschließlich POS-Terminals (Point-of-Sale) und möglicherweise Selbstbedienungsgeräte,
wenn diese als Produkte unter dem Namen der Bank vermarktet werden. - Mobile-Banking-Anwendungen und Online-Banking-Frontends, die Privat- oder Firmenkunden zur Verfügung gestellt werden, insbesondere wenn die Bank für Design, Entwicklung und Updates verantwortlich ist.
- Sicherheitsanwendungen, Authentifizierungstools oder SDKs (z. B. Apps für starke Kundenauthentifizierung, Transaktionssignierung oder sichere Nachrichtenübermittlung), die an Kunden verteilt werden.
- Andere proprietäre Softwarekomponenten oder Plattformen, die die Bank als eigenständiges Produkt an externe Kunden lizenziert oder vertreibt.
Wenn eine Bank als Hersteller qualifiziert ist oder PDE unter ihrem eigenen Namen auf den Markt bringt, muss sie alle oben beschriebenen CRA-Verpflichtungen erfüllen.
Überschneidungen mit DORA und NIS2
DORA und NIS2 regeln in erster Linie die operative Cyber-Resilienz von Finanzunternehmen und decken Bereiche wie IKT-Risikomanagement, Klassifizierung und Meldung von Vorfällen, Testverfahren und Risikomanagement durch Dritte ab. Die CRA konzentriert sich dagegen auf die intrinsische Sicherheit digitaler Produkte. Für Banken ergeben sich daraus sowohl Überschneidungen als auch Integrationsmöglichkeiten.
In der Praxis sollten Banken ihr IKT- und Sicherheitskontrollsystem so gestalten, dass Prozesse wie sichere Softwareentwicklung, Schwachstellenmanagement, Penetrationstests und Patch-Management
gleichzeitig die Anforderungen von DORA, NIS2 und CRA erfüllen. Dies reduziert Doppelarbeit und trägt dazu bei, eine konsistente, durchgängige Cyber-Resilienz sowohl für Produkte als auch für Betriebsabläufe nachzuweisen.
Die CRA führt spezifische Meldepflichten für ausgenutzte Schwachstellen und schwerwiegende Cybersicherheitsvorfälle im Zusammenhang mit Produkten ein. Diese Verpflichtungen bestehen neben der Meldepflicht für Vorfälle an die Finanzaufsichtsbehörden gemäß DORA, sodass Banken eine klare interne Zuweisung von Verantwortlichkeiten und harmonisierte Arbeitsabläufe benötigen.
Der Fahrplan für Führungskräfte: Maßnahmen ohne Reue
Da die ersten Berichtspflichten im September 2026 beginnen, muss die Unternehmensleitung jetzt handeln:
- Umfang und Zuständigkeiten definieren
Identifizieren Sie, welche „Produkte mit digitalen Elementen” Sie auf dem EU-Markt anbieten (z. B. Mobile-Banking-Apps, Karten, Geldautomaten, Terminals) und inwiefern sich CRA mit Ihrem DORA-Programm überschneidet. Weisen Sie klare Führungszuständigkeiten zu (CISO/CIO plus Produkt und Compliance) und integrieren Sie CRA in die bestehende ICT-Risikosteuerung. - Bestandsaufnahme erstellen und Produkte klassifizieren
Erstellen Sie eine bankweite Bestandsaufnahme aller Produkte, die in den Geltungsbereich fallen, einschließlich eingebetteter Software und wichtiger Komponenten von Drittanbietern, und klassifizieren Sie diese nach CRA-Risikokategorie und geschäftlicher Kritikalität. Verknüpfen Sie dies mit Ihrem DORA-ICT-Asset-Register, um einen einheitlichen Überblick über die operative und produktbezogene Resilienz zu erhalten. - Verbessern Sie Secure-by-Design und Dokumentation
Stärken Sie die Secure-by-Design-Entwicklungsstandards, Test- und Freigabekriterien für diese Produkte in Übereinstimmung mit den grundlegenden CRA-Anforderungen und der CE-Konformität. - Verschärfung des Umgangs mit Schwachstellen und Vorfällen
Verbessern Sie das Schwachstellenmanagement auf Produktebene (Erfassung, Triage, SLA für Behebung, Kundenbenachrichtigungen) und stimmen Sie es auf bestehende DORA-Prozesse für das Vorfalls- und Bedrohungsmanagement ab. Bereiten Sie sich darauf vor, die hohen Erwartungen der CRA hinsichtlich der schnellen Meldung ausgenutzter Schwachstellen und schwerwiegender Vorfälle an die Behörden zu erfüllen:- Festlegen, wann ein Problem in einem Bankprodukt als CRA-relevanter Produktvorfall gilt und wann es gleichzeitig eine Meldung gemäß DORA oder NIS2 auslöst.
- Richten Sie die Kriterien für Erkennung, Klassifizierung und Eskalation so aus, dass Sicherheitsabläufe, Produktteams und Compliance-Funktionen nach einem einheitlichen Leitfaden arbeiten.
- Stellen Sie sicher, dass die Berichterstattung an die zuständigen Cyberbehörden (z. B. CSIRTs, ENISA) und an die Finanzaufsichtsbehörden koordiniert, aber bei gesetzlicher Verpflichtung getrennt erfolgt.
- Ansprechen von Anbietern und Planung der Roadmap
Integrieren Sie CRA-konforme Cybersicherheits-, SBOM- und Patch-Verpflichtungen in wichtige Lieferantenverträge und Risikobewertungen von Drittanbietern. Genehmigen Sie eine mehrjährige Roadmap, die sich zunächst auf die kritischsten kundenorientierten Produkte konzentriert und vom wichtigsten CRA-Compliance-Datum im Dezember 2027 ausgehend rückwärts arbeitet.



