Wie wird der Unterstützungszeitraum bestimmt?
Art. 13 Abs. 8 bestimmt den Unterstützungszeitraum in zwei Schichten, und die Reihenfolge entscheidet. Die Regel steht in Unterabsatz 2: Der Hersteller legt den Zeitraum so fest, „dass er die Dauer der voraussichtlichen Nutzung des Produkts widerspiegelt“, und berücksichtigt dabei die angemessenen Erwartungen der Nutzer und die Art des Produkts. Erst Unterabsatz 3 nennt eine Zahl, und er beginnt mit „Unbeschadet Unterabsatz 2“: mindestens fünf Jahre; ist die voraussichtliche Nutzungsdauer kürzer, muss der Zeitraum ihr entsprechen. Die Gesichtspunkte, aus denen der Zeitraum bestimmt wurde, gehören nach Unterabsatz 5 in die technische Dokumentation; das Enddatum ist beim Kauf anzugeben (Art. 13 Abs. 19).
Ein Produkt, das nach vernünftiger Erwartung zehn Jahre im Einsatz steht, genügt der Vorschrift nicht schon dadurch, dass es fünf Jahre unterstützt wird. Umgekehrt verlängert, wer den Zeitraum großzügig bemisst, um im Markt gut auszusehen, die Zeit, in der ein unterlassenes Sicherheitsupdate eine Rechtspflicht verletzt. Die richtige Zahl ist die begründete. Für eine Banking-App ist die Nutzungsdauer einer Version kurz, die des Produkts lang – die Abschaltung alter Versionen ersetzt die Supportentscheidung nicht, sie ist Teil davon.
Wie müssen Sicherheitsupdates bereitgestellt werden?
Anhang I Teil II Nr. 2 und Nr. 8 verpflichten dazu, Schwachstellen unverzüglich zu beheben und Sicherheitsupdates unverzüglich und unentgeltlich zu verbreiten – über den gesamten Unterstützungszeitraum. Sicherheitsupdates sind, soweit technisch möglich, getrennt von Funktionsupdates bereitzustellen; Nutzer müssen Sicherheitsupdates nicht mit neuen Funktionen oder Bedingungen erkaufen. Für Bestandsversionen heißt das: Wer eine alte App-Version im Feld belässt, muss sie entweder aktualisieren oder ihr Supportende klar kommunizieren.
Wann ist ein Update eine wesentliche Änderung?
Art. 3 Nr. 30 definiert die wesentliche Änderung als Änderung nach dem Inverkehrbringen, die die Konformität mit den grundlegenden Anforderungen beeinträchtigt oder den bestimmungsgemäßen Zweck ändert. Die Leitlinien der Kommission konkretisieren: Eine Änderung ist wesentlich, wenn sie die Einhaltung der Cybersicherheitsanforderungen beeinflusst, das Risikoniveau verändert oder den Zweck ändert. Beispiele: Das Hinzufügen einer Fernverbindung eröffnet neue Angriffsvektoren und ist wesentlich; der Wechsel eines Verschlüsselungsprotokolls kann es sein. Eine Sicherheitskorrektur, die keine der drei Bedingungen erfüllt, ist nicht wesentlich. Jede wesentlich geänderte Version braucht eine neu erklärte Konformität und einen neu festgelegten Unterstützungszeitraum.
| Release-Situation | Zu klären | Regelfolge |
|---|---|---|
| Gezielte Sicherheitskorrektur | Bleiben Zweck, Funktionen und Risikoniveau unverändert? | in der Regel keine wesentliche Änderung; Nachweis der Tests in der Produktakte |
| Neue fachliche Funktion (z. B. Freigabe per Push, neue Schnittstelle) | Ändern sich Datenflüsse, Angriffsfläche oder Zweck? | Risikobewertung aktualisieren; bei neuem Risiko oder neuem Zweck: wesentliche Änderung, erneute Konformitätsbewertung |
| Wechsel einer Kernkomponente (Authentifizierung, Krypto-Bibliothek) | Berührt der Wechsel Anforderungen des Anhangs I Teil I? | häufig wesentlich; Nachweise je betroffener Anforderung erneuern |
| Abkündigung einer Komponente durch den Lieferanten | Wer erkennt das Supportende, wer bewertet, wer ersetzt? | Ersatz oder Abhilfe innerhalb des eigenen Unterstützungszeitraums; Lieferantenvertrag prüfen |
Sind Bestandsprodukte vom CRA ausgenommen?
Von den materiellen Anforderungen ja, bis zur ersten wesentlichen Änderung. Art. 69 Abs. 2 nimmt Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, von den materiellen Anforderungen aus – aber nur, soweit sie ab diesem Datum nicht wesentlich geändert werden. Die erste wesentliche Änderung nach dem Stichtag holt das Bestandsprodukt vollständig in den CRA. Die Meldepflichten nach Art. 14 gelten für Bestandsprodukte ohnehin seit 11. September 2026 (Abs. 3). Dokumentieren Sie deshalb den betrachteten Produktstand und jede Änderung, statt auf das Datum des ursprünglichen Projektstarts zu verweisen.
Wird der Unterstützungszeitraum ab 9. Dezember 2026 zur Haftungsgrenze?
Die Produkthaftungsrichtlinie (EU) 2024/2853 begründet selbst keine Update-Pflicht – Erwägungsgrund 51 sagt das ausdrücklich. Sie knüpft an das Fehlen von Sicherheitsupdates aber zwei Rechtsfolgen: Software ist Produkt (Art. 4 Nr. 1), und ein Produkt kann fehlerhaft sein, weil es sicherheitsrelevante Cybersicherheitsanforderungen nicht erfüllt (Art. 7 Abs. 2 lit. f). Die Einwendung, der Fehler sei erst nach dem Inverkehrbringen entstanden, ist gesperrt, wenn er auf fehlenden Updates beruht, die der Kontrolle des Herstellers unterliegen (Art. 11 Abs. 2 lit. c) – Kontrolle hat schon, wer Updates bereitstellen kann (Art. 4 Nr. 5 lit. b). Die Update-Pflicht liefert der CRA; die verschuldensunabhängige Haftung liefert die Richtlinie.
Die Richtlinie gilt für Produkte, die nach dem 9. Dezember 2026 in Verkehr gebracht werden – ein Jahr vor der CRA-Vollanwendung. Für ältere Produkte gilt die Richtlinie von 1985 weiter; sie werden vom CRA als installierte Basis (Meldepflicht) erfasst, von der neuen Haftung nicht. Die Haftung setzt ein nationales Umsetzungsgesetz voraus: In Österreich lag bei unserer Prüfung am 8. Oktober 2026 nicht einmal ein Entwurf vor. Einzelheiten auf der Seite CRA in Österreich.
Wie sehen wesentliche Änderungen in der Praxis aus?
Zwei Fälle: eine Bank-App mit neuer Push-Freigabe und eine Versicherungs-App, deren Upload-Komponente der Lieferant abkündigt.
Die App erhält eine Push-Freigabe für Überweisungen und ersetzt dabei das Authentifizierungsmodul. Neue Datenflüsse, neue Angriffsfläche, Kernkomponente gewechselt: wesentliche Änderung. Ergebnis: aktualisierte Risikobewertung, Nachweise je betroffener Anforderung des Anhangs I, neu erklärter Unterstützungszeitraum – und ab Dezember 2027 eine erneute Konformitätsbewertung für den neuen Stand.
Der Partner der Schaden-App kündigt die Upload-Komponente ab; der Ersatz verändert den Ablauf. Ergebnis: Der Ersatz muss innerhalb des zugesagten Unterstützungszeitraums der App erfolgen; der neue Ablauf ist auf Zweck- und Risikoänderung zu prüfen; der Lieferantenvertrag braucht künftig Vorankündigungsfristen für Abkündigungen.
Häufige Fragen
Sind fünf Jahre immer die richtige Supportdauer?
Nein. Fünf Jahre sind die Untergrenze. Der Zeitraum muss die voraussichtliche Nutzungsdauer widerspiegeln und ist in der technischen Dokumentation zu begründen; bei kürzerer Nutzungsdauer darf er kürzer sein.
Ist jede Sicherheitskorrektur eine wesentliche Änderung?
Nein. Wesentlich ist eine Änderung nur, wenn sie die Konformität mit den grundlegenden Anforderungen beeinträchtigt, das Risikoniveau verändert oder den Zweck ändert. Reine Sicherheitskorrekturen erfüllen das in der Regel nicht.
Dürfen Sicherheitsupdates an neue Funktionen gekoppelt werden?
Sicherheitsupdates sind, soweit technisch möglich, getrennt von Funktionsupdates und unentgeltlich bereitzustellen (Anhang I Teil II Nr. 2 und 8).
Gilt die neue Produkthaftung auch für die App, die heute im Store ist?
Nein, für Produkte, die vor dem 9. Dezember 2026 in Verkehr gebracht wurden, gilt das bisherige Recht weiter. Eine wesentlich geänderte neue Version nach diesem Datum ist dagegen ein neu in Verkehr gebrachtes Produkt.
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).