Der EU Cyber Resilience Act (Verordnung (EU) 2024/2847) verpflichtet Hersteller, Schwachstellen während des Supportzeitraums zu behandeln und verfügbare Sicherheitsupdates ohne Verzögerung und kostenlos zu verbreiten. 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, folgt den Sicherheitsupdate-Pflichten; eine neue Funktion tut das nicht.
- Sicherheitsfixes gehören nicht hinter Bezahlschranken. Verfügbare Sicherheitsupdates sollten ohne Verzögerung und kostenlos verbreitet werden, mit Hinweistexten, die Nutzer darüber informieren, was das Update behebt und welche Maßnahmen erforderlich sind, außer wenn für maßgeschneiderte Geschäftskundenprodukte etwas anderes vereinbart ist.
- Automatisch, soweit anwendbar. Automatische Sicherheitsupdates sind dort das Standarddesign, wo sie sinnvoll sind, mit sicheren Verteilmechanismen und klaren Nutzerkontrollen.
- Patch-Ziele sollten der Schwere folgen. Operative Branchenziele sind Tage für aktiv ausgenutzte kritische Probleme, 30 Tage für hohe Schwere, 90 Tage für mittlere Schwere und der nächste reguläre Zyklus für niedrige Schwere.
- 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.
- Meldungen greifen in den Update-Lebenszyklus ein. Wenn eine aktiv ausgenutzte Schwachstelle erkannt wird, läuft die 24-Stunden-Frühwarnung an das koordinierende CSIRT und ENISA parallel zum Patch-Prozess; der Update-Mechanismus muss den Meldeworkflow speisen.
Die vier Anker der CRA-Sicherheitsupdate-Compliance: Kostenregel, Verteilungsmodell, Update-Verfügbarkeit und Bußgeldmodell.
Für Bußgeldstufen siehe den Leitfaden zu Sanktionen und Durchsetzung.
Was als Sicherheitsupdate gilt
Die Updatepflicht beginnt bei der Cybersicherheitsrisikobewertung des Produkts und den anwendbaren Sicherheitseigenschaften. Sichere Standardkonfiguration, Vertraulichkeit, Integrität und Verfügbarkeit bestimmen, ob eine Änderung sicherheitsrelevant ist. Der Hersteller muss Schwachstellen anschließend während des Supportzeitraums wirksam behandeln.
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 Vertraulichkeit, Integrität oder Verfügbarkeit zu gefährden. Die Abgrenzung von einem Feature-Update ist aus zwei Gründen wichtig: Verfügbare Sicherheitsupdates müssen kostenlos sein und ohne Verzögerung verbreitet werden, während Feature-Updates keiner dieser Pflichten unterliegen.
| Update-Typ | Sicherheitsupdate-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 Verzögerung ist in der Verordnung nicht numerisch definiert. Hersteller sollten trotzdem schweregradbasierte operative Ziele festlegen, damit Patch-Entscheidungen konsistent, dokumentiert und erklärbar sind. Das Diagramm unten zeigt ein praktisches Patch-Fenster je Schweregrad, gemessen ab dem Zeitpunkt, zu dem der Hersteller von der Schwachstelle erfährt:
| Schweregrad | Praktisches operatives Ziel |
|---|---|
| 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 |
Dies sind keine CRA-vorgeschriebenen Fristen. Es sind interne Ziele, mit denen Hersteller zeigen können, dass Verzögerungen kontrolliert, risikobasiert und dokumentiert waren.
Wie CRA-Sicherheitsupdates bereitgestellt werden
Automatische Updates
Wo technisch machbar und angemessen, sind automatische Sicherheitsupdates das bevorzugte Design. Ein konformes automatisches Update-Modell sollte Sicherheitsupdates standardmäßig aktivieren, einen klaren Opt-out-Mechanismus bieten, Nutzer über verfügbare Updates informieren, eine vorübergehende Verschiebung ermöglichen, wo angemessen, und Updates sicher verteilen.
Ein robuster automatischer Update-Mechanismus sollte Folgendes bieten:
- 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 sollte der Hersteller jede nicht aufschiebbare Ausgestaltung in der Risikobewertung und der technischen Dokumentation begründen.
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 Support über fünf Jahre hinaus erfordern |
| 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 | Zuerst prüfen, ob der Dienst als Produkt mit digitalen Elementen oder als Remote-Datenverarbeitungslösung im Anwendungsbereich liegt |
| Hybrid (On-Premises-Agent + Cloud-Backend) | Agent-Updates liegen in der Hand des Herstellers; Backend-Updates sind transparent | Jede Komponente hat ihre eigene Supportzeitraum-Frist; der Agent ist das Produkt mit digitalen Elementen, und diese Frist ist maßgeblich |
Für breitere Schwachstellenbehandlung jenseits der Update-Bereitstellung (CVD-Richtlinie, öffentliche Offenlegung, Drittanbieter-Meldungen) siehe den Leitfaden zur Schwachstellenbehandlung.
Meldepflichten während der Update-Bereitstellung
CRA-Meldung enthält fristgebundene Pflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, die die Produktsicherheit betreffen. Der Updateprozess sollte die dafür benötigten Fakten erfassen, weil der Abschlussbericht Details zum Sicherheitsupdate oder zu anderen bereitgestellten Korrekturmaßnahmen enthalten muss.
Die zentrale Wechselwirkung ist operativ:
| Auslöser | Pflicht im Update-Workflow |
|---|---|
| Aktiv ausgenutzte Schwachstelle | Zeitpunkt der Kenntnis, betroffene Produkte, Exploit-Fakten, Minderungsstatus und Sicherheitsupdate-Details für die 24-Stunden-, 72-Stunden- und Abschlussmeldung erfassen. |
| Schwerwiegender Vorfall | Auswirkungen, vermutete rechtswidrige oder böswillige Ursache, erste Bewertung, Minderungsmaßnahmen und nutzerseitige Korrekturmaßnahmen erfassen. |
| Nutzerbenachrichtigung | Klare Anweisungen zu Risikominderung und Korrekturmaßnahmen für betroffene Nutzer und, soweit angemessen, alle Nutzer vorbereiten. |
Behandeln Sie Meldung nicht als separaten nachgelagerten Schritt. Erkenntnisse aus Support, PSIRT, Telemetrie, Kundendienst oder Deployment müssen schnell zur meldeverantwortlichen Person gelangen, wenn eine Meldeschwelle erreicht sein könnte.
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.
Verfügbarkeit von Sicherheitsupdates nach Veröffentlichung
Ein Patch ist nicht erledigt, sobald er einmal bereitsteht. Jedes Sicherheitsupdate, das Nutzern während des Supportzeitraums bereitgestellt wurde, muss nach seiner Veröffentlichung mindestens 10 Jahre lang oder für den Rest des Supportzeitraums verfügbar bleiben, je nachdem, welcher Zeitraum länger ist. Das verändert den Release-Betrieb: alte Pakete, Advisories, Signaturen, Hashes und Installationsanleitungen brauchen dauerhaftes Hosting und Versionsnachvollziehbarkeit.
Die öffentlichen Nutzerinformationen müssen außerdem angeben, welche technische Sicherheitsunterstützung angeboten wird und bis zu welchem Support-Enddatum Nutzer Schwachstellenbehandlung und Sicherheitsupdates erwarten können. Für das Vor-Kauf-Offenlegungsmodell siehe Offenlegung zum Support-Ende.
Häufige Fehler
Transitive Abhängigkeiten ignorieren. Die meisten Schwachstellen in vernetzten Produkten stammen aus Drittanbieterbibliotheken und -komponenten, nicht aus eigenem Code. Die Schwachstellenbehandlungspflicht erstreckt sich auf das gesamte Produkt einschließlich Komponenten. Ein SBOM ist die Voraussetzung. Den Rahmen für das Tracking transitiver Schwachstellen finden Sie im SBOM-Cluster-Leitfaden.
Für Sicherheitsupdates Geld verlangen. Sicherheitsfixes in eine kostenpflichtige Supportstufe zu bündeln, kollidiert mit dem grundlegenden CRA-Update-Modell, sofern nicht die Ausnahme für maßgeschneiderte Geschäftskundenprodukte greift. Grundlegende Sicherheitspatches müssen kostenlos sein.
Häufig gestellte Fragen
Müssen Sicherheitsupdates immer kostenlos sein?
Ja, verfügbare Sicherheitsupdates müssen kostenlos sein, sofern nicht die enge Ausnahme für maßgeschneiderte Geschäftskundenprodukte greift. Ein Hersteller darf einen Schwachstellenfix nicht in einem kostenpflichtigen Abonnement, einer Premium-Support-Stufe oder einem bezahlten Hauptversions-Upgrade bündeln und dies als normale CRA-Konformität behandeln. Feature-Updates, neue Funktionen und professionelle Dienstleistungen können separat berechnet werden. Entscheidend ist, ob die Änderung ein identifiziertes Sicherheitsproblem im Produkt behebt.
Wie schnell muss ein Hersteller ein Sicherheitsupdate gemäß dem CRA veröffentlichen?
Der CRA setzt keine feste Patch-Frist. Hersteller brauchen deshalb dokumentierte Ziele nach Schweregrad. Kritische aktiv ausgenutzte Schwachstellen sollten in Tagen behandelt werden, hohe Schwere ungefähr innerhalb von 30 Tagen, mittlere Schwere ungefähr innerhalb von 90 Tagen und niedrige Schwere im nächsten regulären Zyklus, sofern die Risikobewertung kein anderes Ziel rechtfertigt. Erfassen Sie die tatsächliche Zeit bis zum Patch je Schwachstelle, damit Verzögerungen sichtbar, risikobasiert und erklärbar bleiben.
Sind automatische Updates nach dem CRA vorgeschrieben?
Nicht in allen Fällen. Automatische Sicherheitsupdates sind erforderlich, soweit sie anwendbar sind; das Produkt sollte Nutzer außerdem über verfügbare Updates informieren und einen vorübergehenden Aufschub ermöglichen. Bei zuverlässig vernetzten Verbraucherprodukten sind automatische Updates meist die erwartete Ausgestaltung. Bei luftisolierten Industriesystemen, bestimmten Medizinprodukten oder sicherheitskritischen Geräten kann ein dokumentierter manueller Prozess gerechtfertigt sein. Die technische Dokumentation sollte den gewählten Ansatz erklären, und die Nutzerinformationen sollten erklären, wie sich die automatische Installation abschalten lässt.
Hat ein SaaS-Produkt einen CRA-Supportzeitraum?
Das hängt davon ab, ob der Dienst als Produkt mit digitalen Elementen oder als Remote-Datenverarbeitungslösung im Anwendungsbereich liegt. Reine eigenständige SaaS, die nicht an Hardware, herunterladbare Software oder vom Hersteller verantwortete Remote-Datenverarbeitung gebunden ist, fällt grundsätzlich nicht unter dieses Update-Modell. Enthält das Angebot einen On-Premises-Agenten, einen herunterladbaren Client, ein Hardware-Gateway oder erfasste Remote-Verarbeitung, müssen Supportzeitraum und Update-Mechanismus für die betroffene Komponente abgebildet werden. Die Nutzerinformationen brauchen weiterhin Art und Enddatum des Supports.
Was passiert mit Sicherheitsupdates nach Ablauf des CRA-Supportzeitraums?
Die normale Pflicht zur Schwachstellenbehandlung ist an den Supportzeitraum gebunden, aber bereits veröffentlichte Updates müssen verfügbar bleiben. Jedes während des Supportzeitraums bereitgestellte Sicherheitsupdate muss nach seiner Veröffentlichung mindestens 10 Jahre lang oder für den Rest des Supportzeitraums verfügbar bleiben, je nachdem, welcher Zeitraum länger ist. Hersteller sollten das Support-Ende vorab klar kommunizieren und Nutzerinformationen für den vorgeschriebenen Zeitraum verfügbar halten. Ohne fallbezogene rechtliche Prüfung sollte nicht behauptet werden, dass Meldungen nach Support-Ende ignoriert werden können.