CRA-Meldepflichten: Gelten sie seit 11. September 2026 auch für Apps, die längst im Store sind?

Welche Tatbestände und Fristen kennt Art. 14?

Art. 14 CRA kennt zwei Auslöser mit je drei Meldungen: die aktiv ausgenutzte Schwachstelle (Abs. 1 und 2) und den schwerwiegenden Sicherheitsvorfall mit Auswirkungen auf die Produktsicherheit (Abs. 3 und 4). Adressaten sind gleichzeitig das als Koordinator benannte CSIRT und ENISA, über die einheitliche Meldeplattform nach Art. 16. Die Uhr beginnt mit der Kenntnis – nach ENISA: mit hinreichender Gewissheit – und läuft auch am Wochenende.

Die häufig zitierte Formel „24/72 Stunden und 14 Tage“ gilt damit nur für Schwachstellen; für Vorfälle beträgt die Abschlussfrist einen Monat. Nicht meldepflichtig ist, was vor einer Ausnutzung behoben wird: Ein CVE-Eintrag oder ein öffentlicher Proof-of-Concept allein ist keine aktive Ausnutzung. Art. 14 Abs. 8 verpflichtet zusätzlich zur Unterrichtung der betroffenen Nutzer; Art. 13 Abs. 6 zur Rückmeldung festgestellter Schwachstellen an den Anbieter der Komponente.

Melde-Uhr: Wann laufen die CRA- und DORA-Fristen ab?

Geben Sie den Zeitpunkt ein, zu dem Ihr Haus hinreichende Gewissheit über die aktive Ausnutzung oder den Vorfall hatte. Die Uhr berechnet die CRA-Fristen und – falls der Sachverhalt zugleich ein schwerwiegender IKT-Vorfall nach DORA ist – die DORA-Fristen aus der Delegierten Verordnung (EU) 2025/301. Alle Eingaben bleiben im Browser; nichts wird gespeichert oder übertragen.

Was kann die ENISA-Plattform im Erstausbau?

Die Single Reporting Platform ist am 11. September 2026 in Betrieb gegangen – am selben Tag, an dem die Pflicht anwendbar wurde; Zugangsanleitung und Handbuch erschienen am Tag zuvor. ENISA spricht ausdrücklich von einer „initial operating capability“. Für die Meldefähigkeit sind vier Einschränkungen erheblich:

• Keine Programmierschnittstelle: Die Einreichung erfolgt ausschließlich über die Weboberfläche. Jede Werkzeugkette endet an einer Person, die im Browser ein Formular ausfüllt – bei 24 Stunden eine Verfügbarkeitsfrage für Personen, nicht für Systeme.
• Nur Englisch.
• Keine freiwilligen Meldungen nach Art. 15 im Erstausbau.
• Keine Statusseite: Ob die Plattform gerade erreichbar ist, lässt sich nicht belegen.

Zugang: EU-Login mit Mehrfaktor-Authentifizierung; ein Primärvertreter kann weitere Vertreter einladen. Eine vorherige Registrierung ist nicht erforderlich, Registrierung und Meldung sind nach Auskunft des BSI binnen weniger Minuten möglich. Welches CSIRT zuständig ist, bestimmt Art. 14 Abs. 7 nach der Hauptniederlassung – die Plattform setzt das aber nicht selbst um: Der Hersteller muss das koordinierende CSIRT auswählen; eine falsche Auswahl kann die Meldung unwirksam machen.

An wen meldet ein Institut in Österreich?

Für Österreich ist CERT.at als koordinierendes CSIRT benannt (ENISA-Liste vom 4. September 2026); Meldungen über die Plattform erreichen CERT.at und ENISA gleichzeitig. Einen österreichischen Rechtsakt, der die Benennung förmlich ausspricht, haben wir nicht gefunden – belegt ist sie über die ENISA-Liste und die Selbstauskunft von CERT.at.

Begründet eine CRA-Meldung eine höhere Haftung?

Nein. Art. 17 Abs. 4 stellt klar, dass eine Meldung als solche keine erhöhte Haftung begründet. Art. 64 Abs. 10 nimmt Kleinst- und Kleinunternehmen vom Bußgeld aus, wenn sie die Frühwarnfrist versäumen – die Meldepflicht selbst bleibt, und für Banken und Versicherungen greift die Ausnahme ohnehin nicht. Verstöße gegen Art. 14 fallen in den obersten Bußgeldrahmen: bis 15 Mio. Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.

Wie verhalten sich CRA- und DORA-Meldung zueinander?

Art. 14 CRA verpflichtet den Hersteller auf der Produktebene; DORA verpflichtet das Finanzunternehmen auf der Betreiberebene. Ein Vorfall kann beide Pflichten auslösen, und keine rechnet auf die andere an – das Unionsrecht sieht dafür keinen Mechanismus vor. Für NIS-2 gilt dasselbe (Art. 23 NIS-2); Erwägungsgrund 72 CRA legt den Mitgliedstaaten nationale Anlaufstellen lediglich nahe.

Wie wird ein Institut meldefähig?

Sechs Schritte: Bestand erheben, Entscheider benennen, MFA-Konten anlegen, Lieferantenverträge anpassen, Runbook führen und üben.

• Produkte im Bestand erheben, für die das Institut Hersteller ist – einschließlich Alt-Versionen im Store.
• Eine Person benennen, die die Entscheidung „hinreichende Gewissheit“ trägt; Triage durchgehend besetzen, nicht in Schichten bündeln.
• EU-Login-Konten mit MFA für Primär- und Sekundärvertreter anlegen; CERT.at als Koordinator vorab festhalten.
• Informationspflichten des Entwicklungspartners vertraglich auf die 24-Stunden-Uhr abstimmen (wer erkennt, wer informiert, wer meldet).
• Ein Runbook für CRA, DORA und DSGVO mit getrennten Uhren und Adressaten; Rückfallweg zu CERT.at dokumentieren.
• Mit fiktiven Unterlagen üben; keine Testmeldungen im Echtbetrieb.

Häufige Fragen

Beginnt die 72-Stunden-Frist erst nach der Frühwarnung?

Nein. Beide Fristen laufen ab dem Zeitpunkt, zu dem der Hersteller Kenntnis erlangt (Art. 14 Abs. 2 lit. b, Abs. 4 lit. b CRA). Die Frühwarnung verschiebt die 72-Stunden-Meldung nicht.

Muss jede Schwachstelle gemeldet werden?

Nein. Meldepflichtig sind nur aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Was vor einer Ausnutzung behoben wird, fällt unter die normale Schwachstellenbehandlung nach Anhang I Teil II.

Ersetzt die CRA-Meldung die DORA-Meldung an die FMA?

Nein. Beide Pflichten bestehen nebeneinander, mit eigenen Auslösern, Fristen und Adressaten. Eine Anrechnung sieht das Unionsrecht nicht vor.

Was gilt, wenn die ENISA-Plattform nicht erreichbar ist?

Nach der ENISA-FAQ ist die Wiederherstellung abzuwarten und die Meldung nachzuholen; bei Dringlichkeit kann das CSIRT direkt kontaktiert werden. Die Frist wird dadurch nicht gehemmt. Für Österreich ist kein eigenes Rückfallverfahren veröffentlicht.