Artikel 13(8) des EU Cyber Resilience Act (Verordnung (EU) 2024/2847) verpflichtet Hersteller, Sicherheitsupdates kostenlos und ohne ungebührliche Verzögerung für den gesamten Unterstützungszeitraum bereitzustellen. Diese Seite behandelt die Bereitstellungsmechanik von Updates für eingebettete, eigenständige, SaaS- und hybride Architekturen. Zur Dauermechanik siehe CRA-Unterstützungszeitraum; zur vorvertraglichen Offenlegung des Support-Endes siehe Offenlegung des Support-Endes.
Zusammenfassung
- Sicherheitsupdates sind keine Feature-Updates. Eine Änderung, die eine Schwachstelle behebt, unterliegt den Kosten- und Fristeregeln aus Artikel 13(8); eine Änderung, die neue Funktionalität hinzufügt, nicht.
- Kostenlos gemäß Artikel 13(8). Hersteller dürfen Sicherheitsfixes nicht in kostenpflichtigen Abonnements, Premium-Stufen oder kostenpflichtigen Hauptversions-Upgrades bündeln.
- Automatisch wo möglich gemäß Anhang I Teil II. Buchstabe 7 verlangt sichere Verteilungsmechanismen mit automatischer Bereitstellung, soweit anwendbar; Buchstabe 8 verlangt die unverzügliche Verbreitung.
- "Ohne ungebührliche Verzögerung" richtet sich nach dem Schweregrad. Branchenübliche Erwartungen sind: Tage für aktiv ausgenutzte kritische Probleme, 30 Tage bei hohem Schweregrad, 90 Tage bei mittlerem Schweregrad und der nächste reguläre Zyklus bei niedrigem Schweregrad.
- Die Architektur bestimmt das Bereitstellungsmodell. Eingebettete Firmware, eigenständige Software, SaaS und hybride Produkte haben jeweils eigene Update-Mechaniken, die in der technischen Dokumentation beschrieben sein müssen.
- Artikel 14 und der Update-Lebenszyklus greifen ineinander. Wenn eine aktiv ausgenutzte Schwachstelle erkannt wird, läuft die 24-Stunden-ENISA-Frühwarnung parallel zum Patch-Prozess; der Update-Mechanismus muss in den Meldeworkflow eingebunden sein.
Die vier Ankerpunkte der CRA-Sicherheitsupdate-Compliance: Kostenregel, Verteilungspräferenz, Fristerwartung und Bußgeldobergrenze.
Für Sicherheitsupdates zu verlangen ist einer der direktesten Wege zu einem Befund der Nichteinhaltung. Wenn ein Fix, der eine Schwachstelle behebt, nur für Kunden einer kostenpflichtigen Support-Stufe, hinter einem Premium-Abonnement oder innerhalb eines als Neuprodukt bepreisten Hauptversions-Upgrades verfügbar ist, erfüllt diese Gestaltung Artikel 13(8) nicht. Grundlegende Sicherheits-Patches müssen für alle Nutzer des Produkts, wie es auf dem Markt bereitgestellt wurde, ohne zusätzliche Kosten und für die gesamte Dauer des Unterstützungszeitraums verfügbar sein. Feature-Releases, professionelle Dienstleistungen und optionale Funktionen können weiterhin berechnet werden. Die Trennlinie ist, ob die Änderung eine Schwachstelle behebt.
Was als Sicherheitsupdate gilt
Artikel 13(2) des CRA verpflichtet Hersteller, Produkte zu entwerfen und herzustellen, die "standardmäßig sicher" sind und "die Vertraulichkeit, Integrität und Verfügbarkeit von Daten" gewährleisten. Artikel 13(8) verlangt dann, dass nach der Marktbereitstellung entdeckte Schwachstellen für die Dauer des Unterstützungszeitraums behandelt werden.
Ein Sicherheitsupdate im Sinne des CRA ist eine Änderung, die eine Schwachstelle behebt, also eine Schwäche im Produkt, die ausgenutzt werden könnte, um die Vertraulichkeit, Integrität oder Verfügbarkeit zu gefährden. Die Abgrenzung von einem Feature-Update ist aus zwei Gründen wichtig: Sicherheitsupdates müssen kostenlos und ohne ungebührliche Verzögerung bereitgestellt werden, während für Feature-Updates keine dieser Pflichten gilt.
| Update-Typ | Artikel-13(8)-Pflicht | Kann berechnet werden? |
|---|---|---|
| Patch zur Behebung eines bekannten CVE | Ja (Sicherheitsupdate) | Nein |
| Härtungsmaßnahme zur Reduzierung der Angriffsfläche | Ja (Sicherheitsupdate) | Nein |
| Neues Feature ohne Sicherheitsrelevanz | Nein | Ja |
| Hauptversion mit neuen Funktionen | Nein (sofern keine Sicherheitsfixes enthalten) | Ja |
| Abhängigkeits-Update zur Beseitigung einer bekannten Schwachstelle | Ja (Sicherheitsupdate) | Nein |
| Konfigurationsänderung zum Schließen einer Sicherheitslücke | Ja (Sicherheitsupdate) | Nein |
"Ohne ungebührliche Verzögerung" ist in der Verordnung nicht numerisch definiert, aber die allgemeine Erwartung von Marktüberwachungsbehörden und ENISA-Leitlinien entspricht der Branchenpraxis. Das nachfolgende Diagramm zeigt das Patch-Fenster je Schweregrad-Stufe, gemessen ab dem Zeitpunkt der Offenlegung der Schwachstelle (T0):
| Schweregrad | Branchenübliche Erwartung |
|---|---|
| Kritisch (aktiv ausgenutzt) | Tage, nicht Wochen |
| Hoch (leicht aus der Ferne ausnutzbar) | Innerhalb von 30 Tagen |
| Mittel | Innerhalb von 90 Tagen |
| Niedrig | Im nächsten regulären Update-Zyklus enthalten |
Bei diesen Fristen handelt es sich nicht um CRA-vorgeschriebene Zeitrahmen, sie stellen jedoch den Standard dar, anhand dessen "ohne ungebührliche Verzögerung" in Durchsetzungsverfahren bewertet wird.
Wie CRA-Sicherheitsupdates bereitgestellt werden
Automatische Updates
Soweit technisch machbar und angemessen, bevorzugen Artikel 13(8) und Anhang I Teil II automatische Sicherheitsupdates. Das Produkt sollte in der Lage sein, Updates zu empfangen und anzuwenden, ohne dass der Nutzer manuell eingreifen muss.
Anforderungen an einen konformen automatischen Update-Mechanismus:
- Sicherer Download-Kanal (TLS, signierte Pakete)
- Integritätsprüfung vor der Installation
- Rollback-Funktion bei fehlgeschlagenem Update
- Fehlertolerante Handhabung von Konnektivitätsproblemen
- Sichtbarkeit des Update-Status für den Nutzer
Der Nutzer muss die Möglichkeit behalten, automatische Updates zu deaktivieren, verbunden mit einem klaren Hinweis auf die Sicherheitsfolgen. Für kritische Sicherheitsupdates kann der Hersteller das System so gestalten, dass das Update ohne Aufschub angewendet wird. Artikel 13(8) unterstützt dies, wenn das Risiko es rechtfertigt.
Manuelle Updates
Produkte, die keine automatischen Updates empfangen können (luftisolierte Industriesysteme, eingebettete Geräte ohne Konnektivität, bestimmte medizinische oder sicherheitskritische Geräte), erfordern einen manuellen Update-Bereitstellungsprozess:
- Herunterladbare Update-Pakete mit klarer Versionierung
- Kryptografische Signaturen und veröffentlichte öffentliche Schlüssel zur Verifizierung
- Installationsdokumentation
- Benachrichtigung über alle verfügbaren Kanäle (E-Mail, Webportal, Produktoberfläche, physischer Hinweis falls erforderlich)
Eingebettete und SaaS-Produkte: Unterschiedliche Update-Modelle
Der Update-Bereitstellungsmechanismus unterscheidet sich je nach Produktarchitektur erheblich:
| Produkttyp | Update-Modell | Wesentliche CRA-Anforderung |
|---|---|---|
| Eingebettete Firmware (IoT, Industrie) | Hersteller liefert signierte Firmware; Kunde wendet sie an | Muss OTA-Fähigkeit oder dokumentierten manuellen Prozess haben; lange Gerätelebensdauer kann den erwarteten Nutzungszeitraum nahe an fünf Jahre heranführen |
| Eigenständige Software (Desktop, Server) | Hersteller veröffentlicht Paket; Kunde installiert es | Automatischer Update-Agent bevorzugt; Versions-Pinning durch Unternehmenskunden erzeugt Mehrversions-Supportaufwand |
| SaaS / Cloud-gehostet | Hersteller kontrolliert die Umgebung; Updates sind für den Nutzer transparent | Die Frist beginnt weiterhin mit der Marktbereitstellung; der Unterstützungszeitraum ist hauptsächlich für On-Premises- oder Hybridkomponenten relevant; API-Versionierung schafft eigene Support-Verpflichtungen |
| Hybrid (On-Premises-Agent + Cloud-Backend) | Agent-Updates liegen in der Hand des Herstellers; Backend-Updates sind transparent | Jede Komponente hat ihre eigene Unterstützungszeitraum-Frist; der Agent ist das Produkt mit digitalen Elementen, und diese Frist ist maßgeblich |
Weitere Aspekte der Schwachstellenbehandlung gemäß Anhang I Teil II, die über die Update-Bereitstellung hinausgehen (CVD-Richtlinie, öffentliche Offenlegung, Drittanbieter-Meldungen), finden Sie im Leitfaden zur Schwachstellenbehandlung.
Meldepflichten bei Schwachstellen während und nach dem Unterstützungszeitraum
Artikel 14 legt Herstellern zeitgebundene Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle auf. Diese Pflichten gelten während des Unterstützungszeitraums.
Die wesentliche Wechselwirkung:
| Phase | Meldepflicht nach Artikel 14 |
|---|---|
| Während des Unterstützungszeitraums | Artikel 14 gilt vollständig: 24-Stunden-Frühwarnung, 72-Stunden-Meldung, 14-tägiger Abschlussbericht für aktiv ausgenutzte Schwachstellen; 24 Stunden / 72 Stunden / 1 Monat für schwerwiegende Vorfälle. Über die ENISA Single Reporting Platform. |
| Nach Ende des Unterstützungszeitraums | Keine Artikel-14-Meldepflicht für Schwachstellen, die nach dem EOL entdeckt werden. Wenn der Hersteller von einer kritischen, aktiv ausgenutzten Schwachstelle in einem nicht mehr unterstützten Produkt mit einer großen installierten Basis erfährt, besteht keine Meldepflicht. Verantwortungsvolle Offenlegung und Nutzerbenachrichtigung sind aus Reputations- und Marktüberwachungsgründen dringend zu empfehlen. |
Das Support-Enddatum ist damit auch der Artikel-14-Horizont. Sobald der Unterstützungszeitraum abläuft, hat der Hersteller keine Pflicht mehr, Schwachstellen in dieser Produktversion zu untersuchen, zu patchen oder zu melden. Marktüberwachungsbehörden können weiterhin nach Artikel 58 ermitteln, wenn das Produkt ein erhebliches Cybersicherheitsrisiko darstellt, doch die laufende Schwachstellenverwaltungspflicht nach Artikel 13(8) ist beendet.
Zur vollständigen Artikel-14-Fristmechanik, einschließlich des erforderlichen Inhalts jedes Berichts und der Unterschiede zwischen den beiden Meldeströmen (aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle), siehe den Leitfaden zur Schwachstellenmeldung.
Häufige Fehler
Transitive Abhängigkeiten ignorieren. Die meisten Schwachstellen in vernetzten Produkten stammen aus Drittanbieterbibliotheken und -komponenten, nicht aus eigenem Code. Die Artikel-13(8)-Pflicht erstreckt sich auf das gesamte Produkt, nicht nur auf den vom Hersteller geschriebenen Code. Ein SBOM ist die Voraussetzung. Den Rahmen für das Tracking transitiver Schwachstellen finden Sie im SBOM-Cluster-Leitfaden.
Für Sicherheitsupdates verlangen. Das Bündeln von Sicherheitsfixes in einer kostenpflichtigen Support-Stufe verstößt gegen Artikel 13(8). Grundlegende Sicherheits-Patches müssen kostenlos sein.
Häufig gestellte Fragen
Müssen Sicherheitsupdates immer kostenlos sein?
Ja. Artikel 13(8) verlangt, dass Sicherheitsupdates kostenlos bereitgestellt werden. Ein Hersteller darf einen Sicherheitsfix nicht in einem kostenpflichtigen Abonnement, einer Premium-Support-Stufe oder einem Hauptversions-Upgrade bündeln und dabei Artikel-13(8)-Konformität behaupten. Feature-Updates, neue Funktionen und kostenpflichtige professionelle Dienstleistungen sind davon getrennt und dürfen normal berechnet werden. Die Pflicht beschränkt sich auf Updates, die Schwachstellen beheben: Änderungen, die eine Sicherheitsschwäche im Produkt, wie es auf dem Markt bereitgestellt wurde, beheben.
Wie schnell muss ein Hersteller ein Sicherheitsupdate gemäß dem CRA veröffentlichen?
Artikel 13(8) des CRA verlangt Sicherheitsupdates "ohne ungebührliche Verzögerung", definiert aber keine numerische Frist. Marktüberwachungsbehörden und ENISA-Leitlinien orientieren sich an der Branchenpraxis, die nach Schweregrad gestaffelt ist: Kritisch aktiv ausgenutzte Schwachstellen sollten innerhalb von Tagen gepatcht werden, hoher Schweregrad innerhalb von etwa 30 Tagen, mittlerer Schweregrad innerhalb von 90 Tagen und niedriger Schweregrad im nächsten regulären Update-Zyklus. Dies sind keine CRA-vorgeschriebenen Fristen, stellen aber den Standard dar, anhand dessen "ohne ungebührliche Verzögerung" in Durchsetzungsverfahren bewertet wird. Hersteller sollten die tatsächliche Zeit bis zum Patch je CVE verfolgen, damit Abweichungen von diesem Richtwert sichtbar und begründbar sind.
Sind automatische Updates nach dem CRA vorgeschrieben?
Nicht in allen Fällen. Anhang I Teil II Buchstabe 7 verlangt von Herstellern, sichere Verteilungsmechanismen mit automatischer Bereitstellung "soweit anwendbar" bereitzustellen. Für Produkte mit zuverlässiger Konnektivität und ohne betrieblichen Grund für einen Aufschub sind automatische Updates der erwartete Standard. Für luftisolierte Industriesysteme, bestimmte Medizingeräte oder sicherheitskritische Geräte, bei denen eine automatische Patch-Installation den Betrieb stören könnte, ist ein dokumentierter manueller Update-Prozess akzeptabel. Die technische Dokumentation nach Anhang VII muss den gewählten Ansatz begründen. Nutzer müssen die Möglichkeit behalten, automatische Updates mit klaren Warnungen zu den Sicherheitsfolgen zu deaktivieren, es sei denn, das Risiko rechtfertigt einen nicht aufschiebbaren kritischen Fix.
Hat ein SaaS-Produkt einen CRA-Unterstützungszeitraum?
Das hängt davon ab, ob das SaaS-Produkt in den CRA-Anwendungsbereich als Produkt mit digitalen Elementen fällt. Reine SaaS-Dienste, die nicht mit einer Hardwarekomponente oder einem herunterladbaren Software-Agenten gebündelt sind, sind gemäß Artikel 2(1) grundsätzlich nicht im Anwendungsbereich. Wenn ein SaaS-Produkt einen On-Premises-Agenten, einen herunterladbaren Client oder ein Hardware-Gateway umfasst, das auf dem EU-Markt bereitgestellt wird, ist diese Komponente im Anwendungsbereich, und ihre Artikel-13(8)-Unterstützungszeitraum-Frist beginnt mit der Marktbereitstellung. Das Cloud-gehostete Backend, das unter der Kontrolle des Herstellers steht und kontinuierlich aktualisiert wird, erfüllt die Patch-Pflicht "ohne ungebührliche Verzögerung" typischerweise durch transparente Deployments, aber der Hersteller muss die Support-Verpflichtung weiterhin in den Anhang-II-Informationen für die im Anwendungsbereich liegende Komponente dokumentieren.
Was passiert mit Sicherheitsupdates nach Ablauf des CRA-Unterstützungszeitraums?
Die Artikel-13(8)-Pflichten enden mit dem Unterstützungszeitraum. Nach Ablauf des offengelegten Enddatums hat der Hersteller keine CRA-Pflicht mehr, Schwachstellen in dieser Produktversion zu untersuchen, zu patchen oder Sicherheitsupdates zu verteilen, und die Artikel-14-Meldepflichten erlöschen ebenfalls, da sie nur während des Unterstützungszeitraums gelten. Marktüberwachungsbehörden können weiterhin nach Artikel 58 ermitteln, wenn das Produkt nach dem End-of-Life ein erhebliches Cybersicherheitsrisiko darstellt, doch die tägliche Schwachstellenverwaltungspflicht ist beendet. Hersteller sollten das Support-Ende den Nutzern rechtzeitig klar kommunizieren; die Anhang-II-Buchstabe-k-Enddatum-Offenlegung ist das nutzerseitige Instrument dafür. Das freiwillige Fortführen von Patches nach dem EOL ist zulässig, aber nicht verpflichtend.