Anwendungsbereich & Rollen
App ja, Browser nein: Der CRA knüpft an den Ausführungsort der Software an. Wer Hersteller ist, entscheidet die Marke, nicht der Vertrag.
Produkt und Rollen klärenGibt es eine CRA-Ausnahme für den Finanzsektor?
Nein. Der Cyber Resilience Act ist ein horizontaler Rechtsakt für Produkte mit digitalen Elementen. Art. 2 Abs. 2 bis 7 nennt die Ausnahmen abschließend: Medizinprodukte, Kraftfahrzeuge, zertifizierte Luftfahrtprodukte, Schiffsausrüstung, identische Ersatzteile sowie Produkte für nationale Sicherheit und Verteidigung. Der Finanzsektor steht nicht darin – es gibt keine Ausnahme für beaufsichtigte Unternehmen, keine für wesentliche Einrichtungen nach NIS-2 und keine für Häuser, die bereits nach anderen Regelwerken geprüft werden. Wer nicht genannt ist, ist erfasst.
Für Banken und Versicherungen entscheidet deshalb die Rollenfrage: Hersteller ist nach Art. 3 Nr. 13, wer ein Produkt entwickelt oder herstellt oder entwickeln lässt und es unter eigenem Namen oder eigener Marke vermarktet – gegen Bezahlung oder unentgeltlich. Die kostenlose Banking-App im Store, die ein Dienstleister gebaut hat, macht die Bank zum Hersteller.
| System | CRA-Prüffrage | Einordnung nach den Leitlinien der Kommission |
|---|---|---|
| Mobile Banking App | Wird die App unter eigener Marke bereitgestellt und vom Institut verantwortet? | Native App auf dem Endgerät: Produkt mit digitalen Elementen – plus Backend, soweit die App ohne es eine Funktion nicht erfüllen könnte. |
| Versicherungs-App (White Label) | Wer lässt entwickeln, wer veröffentlicht, unter wessen Marke? | Vermarktung unter eigener Marke genügt für die Herstellerrolle; der Anbieter der Basis ist Lieferant. |
| Online-Banking-Portal | Reine Browsernutzung oder Datenfernverarbeitung einer App? | Als eigenständiges Browser-Portal kein Produkt – dieselbe Plattform ist aber Datenfernverarbeitung der App und insoweit erfasst. |
| Kreditrechner mit Backend | Wird eine eigenständige Softwarekomponente bereitgestellt? | Nur ein lokal ausgeführter Client oder eine getrennt in Verkehr gebrachte Komponente ist Produkt. |
| Zugekaufte Kernsoftware | Wer ist Hersteller, was bleibt beim Institut? | Hersteller ist der Anbieter; das Institut steuert nach DORA und hat Sorgfalts- und Rückmeldepflichten bei Komponenten (Art. 13 Abs. 5 und 6), soweit es selbst Hersteller eines Produkts ist. |
Welche Fristen gelten beim CRA?
In Kraft seit 10. Dezember 2024, Meldepflichten seit 11. September 2026 (Art. 14), alle Hauptpflichten und CE-Kennzeichnung ab 11. Dezember 2027.
| Datum | Was gilt | Praxisfolge |
|---|---|---|
| 10. Dezember 2024 | CRA in Kraft getreten | Rollenklärung, Produktinventur und Entwicklungsprozesse vorbereiten. |
| 11. September 2026 | Meldepflichten nach Art. 14 CRA anwendbar – auch für Bestandsprodukte (Art. 69 Abs. 3) | Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über die ENISA Single Reporting Platform melden: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht nach 14 Tagen (Schwachstelle) bzw. einem Monat (Vorfall). |
| 11. Dezember 2027 | Volle Anwendung der Hauptpflichten | Grundlegende Anforderungen nach Anhang I, technische Dokumentation, Konformitätsbewertung, EU-Konformitätserklärung und CE-Kennzeichnung. |
Zwei weitere Daten werden regelmäßig missverstanden: Seit 11. Juni 2026 gilt das Notifizierungsregime für Konformitätsbewertungsstellen (Kapitel IV) – daraus folgt keine Herstellerpflicht. Bis 11. Dezember 2026 haben die Mitgliedstaaten für eine ausreichende Zahl notifizierter Stellen zu sorgen; in der englischen, französischen und italienischen Fassung ist das eine Bemühenspflicht, nur die deutsche formuliert eine Ergebnispflicht.
Stand 21. Oktober 2026: vier Befunde, die die Planung bestimmen
Erstens: Keine der 41 im Normungsauftrag M/606 beauftragten harmonisierten Normen ist im Amtsblatt zitiert; die Konformitätsvermutung nach Art. 27 Abs. 1 ist damit leer. Zweitens: Für den CRA ist keine Konformitätsbewertungsstelle notifiziert. Drittens: Der delegierte Rechtsakt nach Art. 27 Abs. 9, der ein europäisches Zertifizierungsschema (EUCC) anrechenbar machen würde, ist nicht erlassen; die Kommission kündigt ihn für das vierte Quartal 2026 an. Viertens: Der Zeitplan steht: Der Digital Omnibus (Verordnung (EU) 2026/1744) hat die KI-Verordnung verschoben, den CRA nicht. Verschoben wurden nur die Lieferfristen der Normungsgremien um zwei Monate – und auch das nur im Entwurf.
Was verlangt der CRA praktisch?
Security by Design, Schwachstellenbehandlung, einen Unterstützungszeitraum von mindestens fünf Jahren, technische Dokumentation und einen Meldeprozess für aktiv ausgenutzte Schwachstellen.
- Cybersecurity-by-Design und sichere Standardkonfigurationen (Anhang I Teil I, dreizehn Produkteigenschaften)
- Schwachstellenbehandlung über den gesamten Unterstützungszeitraum: Software-Stückliste, Behebung, Tests, koordinierte Offenlegung, Meldekontakt, sichere Verteilung von Updates (Anhang I Teil II)
- Unterstützungszeitraum nach der voraussichtlichen Nutzungsdauer, mindestens fünf Jahre (Art. 13 Abs. 8)
- technische Dokumentation nach Anhang VII und EU-Konformitätserklärung; CE-Kennzeichnung vor dem Inverkehrbringen
- Meldeprozess für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle – seit 11. September 2026 (Art. 14)
CRA und DORA: Wird das eine auf das andere angerechnet?
Nein. DORA reguliert das Finanzunternehmen als beaufsichtigte Einheit und sein IKT-Risikomanagement. Der CRA reguliert das Produkt und die Wirtschaftsakteure entlang der Produktkette. Ein Regelwerk, das die Organisation verpflichtet, stellt keine Produktanforderungen auf und kommt als Entlastung vom CRA nicht in Betracht. Ein sicherheitsrelevanter Vorfall in einer App kann deshalb zugleich die DORA-Meldung an die FMA und die CRA-Meldung über die ENISA-Plattform auslösen – mit zwei Fristenregimen und zwei Adressatenkreisen.
Fristen sauber trennen
CRA: Frühwarnung 24 Stunden und Meldung 72 Stunden ab Kenntnis; Abschlussbericht 14 Tage nach Verfügbarkeit einer Abhilfe (Schwachstelle) oder ein Monat nach der 72-Stunden-Meldung (Vorfall). DORA (Delegierte Verordnung (EU) 2025/301): Erstmeldung so bald wie möglich, spätestens 4 Stunden ab Klassifizierung als schwerwiegend und 24 Stunden ab Entdeckung; Zwischenmeldung binnen 72 Stunden ab Erstmeldung; Abschlussmeldung binnen eines Monats ab letzter Zwischenmeldung. Die Melde-Uhr auf der Fachseite rechnet beide Regime nebeneinander.
Die Fachseiten
Meldepflichten & DORA
Seit 11. September 2026: sechs Fristen, die ENISA-Plattform im Erstausbau, CERT.at, Rückfallverfahren – und die Melde-Uhr für CRA und DORA.
Meldeprozess durchgehenSBOM & Lieferanten
Software-Stückliste, Komponenten Dritter, Rückmeldung an Lieferanten, Open-Source-Steward – und warum ISO 27001 Arbeit erspart, aber keine Pflicht.
Nachweiskette aufbauenKonformität, Normen & CE
Produktklassen mit Beispielen, Module A/B+C/H, null von 41 Normen, keine notifizierte Stelle – und was an die Stelle der Vermutung tritt.
Bewertungsweg bestimmenSupport, Updates & Änderungen
Fünf Jahre sind eine Untergrenze. Wann ein Update eine wesentliche Änderung ist und wie der Unterstützungszeitraum zur Haftungsgrenze wird.
Lebenszyklus planenCRA in Österreich
Behördenaufbau, CERT.at, Begleitgesetz, Bußgeldrahmen, Produkthaftung ohne Entwurf und Organhaftung – der lokale Stand.
Österreich-Stand lesenDie CRA-Stichtage im Kontext des Meldewesens
Die Meldepflichten gelten seit 11. September 2026, die übrigen Herstellerpflichten ab 11. Dezember 2027. Beide Termine stehen – neben SREP, DORA, NISG 2026 und KI-Verordnung – im Fahrplan Meldewesen 2026–2028; was CRA-Meldungen mit dem aufsichtlichen Meldewesen verbindet, zeigt der Datenkern.
Was ist jetzt zu tun?
Fünf Schritte: Produktinventur, Rollenklärung, Meldefähigkeit, Gap-Analyse gegen Anhang I und begründete Produktklassifizierung.
- Produktinventur: Welche Apps, Clients und Komponenten stellt das Institut unter eigener Marke bereit – einschließlich der Bestandsprodukte im Store?
- Rollenklärung: Hersteller, Einführer, Händler, Bevollmächtigter, Nutzer – je Produkt und Gesellschaft, am Logo und am Vertrag.
- Meldefähigkeit herstellen: EU-Login-Konten, benannte Vertreter, CERT.at als Koordinator, geübter Ablauf – die Pflicht gilt seit 11. September 2026.
- Gap-Analyse gegen Anhang I und Aufbau der Nachweisführung nach Anhang VII Nr. 5, statt auf harmonisierte Normen zu warten.
- Produktklasse begründet feststellen: Sie entscheidet, ob eine notifizierte Stelle nötig ist – von denen es noch keine gibt.
Häufige Fragen
Betrifft der CRA eine Bank, die keine Software verkauft?
Ja, sobald sie ein Produkt mit digitalen Elementen unter eigener Marke bereitstellt – typischerweise die Banking-App im App-Store. Entgeltlichkeit ist nicht erforderlich. Für zugekaufte Kernsoftware ist der Anbieter Hersteller.
Ersetzt die DORA-Compliance die CRA-Pflichten?
Nein. DORA ist Organisationsrecht, der CRA Produktrecht. Keiner der Verknüpfungsmechanismen des CRA sieht eine Anrechnung sektoraler Aufsicht vor; beide Meldewege laufen nebeneinander.
Gelten die Meldepflichten für eine App, die schon seit Jahren im Store ist?
Ja. Art. 69 Abs. 3 CRA erstreckt die Meldepflichten des Art. 14 ausdrücklich auf Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Die übrigen Pflichten gelten für Bestandsprodukte erst bei einer wesentlichen Änderung.
Wurde der CRA wie die KI-Verordnung verschoben?
Nein. Der Digital Omnibus (Verordnung (EU) 2026/1744) ändert die KI-Verordnung, nicht den CRA. Zum 21. Oktober 2026 lag kein Vorschlag zur Verschiebung der CRA-Fristen vor.
Ing. Mag. Patrick Eiler
Patrick Eiler berät Banken und Versicherungen in Wien zu aufsichtlichem Meldewesen, Datenarchitektur und KI-Compliance. Über zwanzig Jahre in Banken, Versicherungen und Finanzdienstleistung; Vortragender beim Hypo-Verband (Fachsitzung 23. September 2026).