CRA-Sicherheitsupdates: Automatische Updates, Patch-Prozess und sichere Verteilung

Sicherheitsupdates sind unter dem Cyber Resilience Act kein optionaler Service, sondern ein zentraler Teil der Herstellerpflichten. Hersteller müssen Schwachstellen während des Supportzeitraums wirksam behandeln, Sicherheitsupdates ohne unnötige Verzögerung bereitstellen und die Verteilung so gestalten, dass Nutzer Updates sicher erhalten und installieren können. Für viele Produkte verlangt der CRA zudem Funktionen für automatische Sicherheitsupdates oder zumindest eine technisch belastbare Update-Logik.

Einordnung im CRA-Wissen: Dieser Fachartikel gehört zum Themenbereich Schwachstellen & Meldeprozesse. Dort finden Sie die angrenzenden Anforderungen und eine praktische Reihenfolge für die Umsetzung.

Die Veröffentlichung eines Sicherheitsupdates wird mit dem CVD-Prozess abgestimmt. Ein PSIRT mit klaren Zuständigkeiten koordiniert betroffene Versionen und Kommunikation; Signaturen und Schlüsselmanagement schützen die Integrität des Updates.

Was verlangt der CRA bei Sicherheitsupdates?

Der CRA verlangt, dass Hersteller bekannte Schwachstellen angemessen behandeln und verfügbare Sicherheitsupdates ohne unnötige Verzögerung verbreiten. Die Anforderungen stehen nicht isoliert neben dem Produkt, sondern gehören zum gesamten Vulnerability-Handling-Prozess. Das bedeutet: Ein Update muss aus einer erkannten Schwachstelle, einer bewerteten Auswirkung und einer dokumentierten Maßnahme entstehen.

Für die Praxis ist wichtig, zwischen einem normalen Funktionsupdate und einem Sicherheitsupdate zu unterscheiden. Ein neues Dashboard, zusätzliche Exportfunktion oder geänderte Bedienlogik kann warten. Eine Schwachstelle, die Vertraulichkeit, Integrität oder Verfügbarkeit beeinträchtigt, braucht dagegen einen eigenen Priorisierungs- und Freigabeweg. Die CRA-Risikobewertung liefert dafür den produktbezogenen Kontext.

Müssen Sicherheitsupdates automatisch installiert werden?

Bei vielen Produkten soll die technische Gestaltung automatische Sicherheitsupdates ermöglichen. Der CRA verfolgt damit das Ziel, dass bekannte Schwachstellen nicht jahrelang ungepatcht bleiben, nur weil Nutzer Updates übersehen oder aufschieben. Gleichzeitig ist die Pflicht nicht für jede Produktart identisch umzusetzen. Bei professionellen oder industriellen Systemen kann ein ungeprüftes automatisches Update selbst Betriebsrisiken verursachen.

Hersteller sollten deshalb dokumentieren, warum ein Produkt automatische Updates nutzt, eine Freigabe vor der Installation verlangt oder aus technischen Gründen einen anderen Mechanismus benötigt. Diese Entscheidung gehört in die Produktakte und sollte mit der Zweckbestimmung sowie der Betriebsumgebung zusammenpassen.

Dürfen Nutzer automatische Updates abschalten?

Ja. Der CRA sieht vor, dass Nutzer die automatische Installation von Sicherheitsupdates deaktivieren können, wenn das Produkt eine entsprechende Funktion bereitstellt. Der Mechanismus muss verständlich sein; eine versteckte Expertenoption ist keine gute Umsetzung.

Wichtig ist die Kommunikation der Folgen. Wer automatische Updates deaktiviert, sollte klar erkennen können, dass Sicherheitskorrekturen dann möglicherweise manuell installiert werden müssen. Das reduziert Missverständnisse und hilft gleichzeitig, Supportfälle sauber zu dokumentieren.

Müssen Sicherheitsupdates von Funktionsupdates getrennt werden?

Wo es technisch machbar ist, sollten Sicherheitsupdates getrennt von Funktionsupdates bereitgestellt werden. Der Grund ist praktisch: Nutzer sollen nicht gezwungen sein, neue Funktionen oder tiefgreifende Änderungen zu übernehmen, nur um eine kritische Sicherheitslücke zu schließen.

Für Hersteller folgt daraus eine Release-Strategie mit separaten Security-Patches oder klar abgegrenzten Wartungsreleases. Besonders bei Softwareprodukten kann eine solche Trennung die Akzeptanz von Sicherheitsupdates deutlich erhöhen und gleichzeitig die Nachweisführung verbessern.

Wie sollte ein sicherer Update-Prozess aufgebaut sein?

Ein belastbarer Prozess beginnt lange vor dem Upload einer neuen Datei. Er umfasst die sichere Erstellung, Prüfung, Signierung oder anderweitige Integritätssicherung, kontrollierte Veröffentlichung, Nutzerinformation und Erfolgskontrolle.

Wie schützt man die Update-Infrastruktur selbst?

Die Update-Infrastruktur ist häufig eines der attraktivsten Angriffsziele eines Herstellers. Wer den Update-Server oder die Signaturkette kompromittiert, kann unter Umständen schädlichen Code an viele Kunden gleichzeitig verteilen. Deshalb muss die Infrastruktur mindestens so ernst genommen werden wie das Produkt selbst.

Praktisch relevant sind getrennte Berechtigungen, starke Authentisierung, geschützte Signaturschlüssel, nachvollziehbare Freigaben, Protokollierung und eine klare Trennung zwischen Entwicklung und Produktion. Auch die Lieferkette ist einzubeziehen. Das gilt besonders, wenn Build-Systeme, Paketquellen oder externe Dienstleister Teil des Release-Prozesses sind.

Wie schnell muss ein Sicherheitsupdate erscheinen?

Der CRA nennt für Sicherheitsupdates nicht pauschal „X Stunden für jeden Patch“. Entscheidend ist, dass Schwachstellen wirksam und ohne unnötige Verzögerung behandelt werden. Die Dringlichkeit hängt von Ausnutzbarkeit, Auswirkungen, Exposition, betroffenen Produktversionen und vorhandenen Minderungsmaßnahmen ab.

Unternehmen sollten deshalb eigene Prioritätsklassen definieren. Eine aktiv ausgenutzte Schwachstelle mit hohem Schadenspotenzial braucht einen anderen Prozess als ein theoretischer Fehler, der nur unter sehr speziellen lokalen Voraussetzungen relevant ist. Bei aktiv ausgenutzten Schwachstellen können zusätzlich die CRA-Meldepflichten greifen.

Müssen Sicherheitsupdates kostenlos sein?

Grundsätzlich sollen Sicherheitsupdates, die identifizierte Sicherheitsprobleme beheben, ohne zusätzliche Kosten bereitgestellt werden. Ein Hersteller sollte daher vermeiden, notwendige Sicherheitskorrekturen ausschließlich hinter ein kostenpflichtiges Funktionsupgrade zu stellen.

Für B2B-Produkte mit individuellen Vertragsmodellen können Sonderkonstellationen bestehen. Für die interne Planung ist dennoch eine klare Regel sinnvoll: Sicherheitskorrekturen gehören in den Supportprozess und werden nicht als zusätzliche Premium-Funktion behandelt.

Wie lange müssen veröffentlichte Security Updates verfügbar bleiben?

Während des Supportzeitraums bereitgestellte Sicherheitsupdates müssen langfristig verfügbar bleiben. Der CRA nennt dafür grundsätzlich mindestens zehn Jahre ab Bereitstellung oder die verbleibende Dauer des Supportzeitraums, wenn diese länger ist. Das beeinflusst Architektur, Download-Infrastruktur und Archivierung.

Ein Unternehmen sollte daher nicht nur den aktuellen Downloadserver betrachten, sondern auch definieren, wie historische Security Releases, Prüfsummen, Signaturen und zugehörige Hinweise langfristig erhalten bleiben. Der Beitrag zum CRA-Supportzeitraum erklärt die zeitliche Einordnung.

Was gehört in die Nutzerinformation zu Updates?

Nutzer müssen verstehen können, wie sicherheitsrelevante Updates installiert werden, welche Auswirkungen Änderungen haben und wie automatische Updates gegebenenfalls deaktiviert werden. Gute Nutzerinformationen beschreiben außerdem, wann ein Update dringend ist und welche Produktversionen betroffen sind.

Das gehört nicht nur in eine Support-Datenbank. Die Informationen müssen in die Produktdokumentation und in die nach CRA vorgesehenen Nutzerinformationen eingebettet werden. Der geplante Beitrag zur EU-Konformitätserklärung und Nutzerinformation vertieft diese Pflicht.

Wie dokumentiert man Sicherheitsupdates für die technische Dokumentation?

Die technische Dokumentation sollte nachvollziehbar zeigen, wie Updates erzeugt, geprüft und sicher verteilt werden. Dazu gehören Prozessbeschreibung, Rollen, technische Schutzmaßnahmen, relevante Tests und der Bezug zu konkreten Schwachstellen.

Für Prüfungen ist eine saubere Kette hilfreich: Schwachstelle erkannt → Risiko bewertet → Maßnahme beschlossen → Update entwickelt → Test bestanden → Freigabe → Veröffentlichung → Nutzerinformation → Monitoring. Diese Kette ist deutlich belastbarer als einzelne Screenshots oder verstreute Tickets.

Welche typischen Fehler sollten Hersteller vermeiden?

Häufig scheitert der Update-Prozess nicht an fehlendem technischen Wissen, sondern an organisatorischen Lücken. Besonders kritisch sind nicht dokumentierte Zuständigkeiten, gemeinsame Admin-Konten, fehlende Trennung zwischen Security- und Funktionsupdates, unklare Altversionen und nicht getestete Rollback-Verfahren.

• Sicherheitsupdates nur im normalen Release-Zyklus veröffentlichen.
• Keine eindeutige Liste betroffener Produktversionen führen.
• Update-Artefakte ohne Integritäts- oder Herkunftsschutz verteilen.
• Nutzer nicht aktiv über relevante Sicherheitsupdates informieren.
• Historische Sicherheitsupdates zu früh löschen.
• Keine technische Dokumentation des Update-Prozesses pflegen.

Wie können KMU den Update-Prozess pragmatisch starten?

Ein kleines Unternehmen braucht nicht sofort ein komplexes Release-System wie ein Großkonzern. Es braucht aber einen reproduzierbaren Ablauf. Ein praktikabler Start besteht aus einem Security-Label im Ticketsystem, einer Prioritätsmatrix, festen Freigabeverantwortlichen, einem definierten Patch-Kanal und einer Vorlage für Security Advisories.

Zusätzlich sollte einmal testweise eine Schwachstelle vom Eingang bis zur Veröffentlichung eines Updates durchgespielt werden. Dabei zeigt sich schnell, wo Informationen fehlen oder Entscheidungen hängen bleiben.

Wo steht die Pflicht im CRA?

Die verbindlichen Anforderungen ergeben sich vor allem aus Artikel 13 sowie Anhang I Teil II der Verordnung (EU) 2024/2847 bei EUR-Lex. Für die konkrete Umsetzung müssen Zweckbestimmung, Produktart und Risikobewertung gemeinsam betrachtet werden.

Wie geht man mit mehreren gleichzeitig unterstützten Versionen um?

Viele Hersteller pflegen parallel eine aktuelle Hauptversion, eine Long-Term-Support-Version und ältere Releases. Für den CRA muss klar sein, welche davon innerhalb des zugesagten Supportzeitraums liegen und daher noch sicherheitsrelevant gepflegt werden. Eine bloße interne Bezeichnung wie „legacy“ oder „deprecated“ beendet die Verpflichtung nicht automatisch.

Praktisch braucht jede veröffentlichte Version einen Status: unterstützt, nur noch Security Support, End of Support angekündigt oder beendet. Dieser Status sollte mit dem Produktinventar, der SBOM und dem Updatekanal verknüpft sein. So lässt sich bei einer neuen Schwachstelle sofort erkennen, welche Releases einen Patch benötigen und welche Nutzer über ein Supportende informiert werden müssen.

Wie sollte ein Rollback bei fehlerhaften Sicherheitsupdates funktionieren?

Ein Security Patch kann selbst Fehler verursachen. Deshalb gehört ein kontrollierter Rollback- oder Recovery-Plan zum Updateprozess. Der Hersteller muss abwägen, ob eine Rückkehr zur verwundbaren Version sicherheitlich vertretbar ist oder ob eine alternative Zwischenlösung erforderlich ist.

Der Plan sollte festlegen, wer einen Rollback freigibt, wie Nutzer informiert werden und wie verhindert wird, dass Geräte dauerhaft auf einer bekannten unsicheren Version bleiben. Besonders bei automatisch verteilten Updates ist ein getesteter Wiederherstellungsweg wichtig, weil ein fehlerhafter Rollout sehr viele Systeme gleichzeitig betreffen kann.

Welche Rolle spielen Signaturen, Hashes und sichere Transportwege?

Der CRA schreibt nicht für jedes Produkt eine bestimmte kryptografische Signaturtechnik vor. Hersteller müssen aber sicherstellen, dass Updates sicher verteilt werden. In der Praxis bedeutet das, Herkunft und Integrität des Update-Artefakts technisch abzusichern und Manipulationen während Transport oder Speicherung zu verhindern.

Je nach Produkt kann das durch signierte Pakete, verifizierte Boot- oder Updateketten, kryptografische Hashes und geschützte Transportkanäle geschehen. Entscheidend ist, dass das Produkt oder der Updateclient ein manipuliertes Artefakt erkennt und nicht installiert. Die eingesetzte Lösung sollte in der technischen Dokumentation beschrieben und getestet sein.

Was muss bei Offline- oder Industrieprodukten berücksichtigt werden?

Nicht jedes Produkt ist dauerhaft mit dem Internet verbunden. Maschinen, Steuerungen oder Systeme in abgeschotteten Netzen benötigen deshalb andere Verteilwege. Ein USB- oder Wartungsupdate kann zulässig sein, muss aber ebenfalls sicher, nachvollziehbar und für die Nutzer praktikabel sein.

Hersteller sollten dokumentieren, wie Nutzer von einem Sicherheitsupdate erfahren, wie das Update authentifiziert wird und welche Mindestschritte für eine sichere Installation nötig sind. Wenn automatische Updates aus Betriebsgründen ungeeignet sind, sollte diese Entscheidung aus der Risikobewertung ableitbar sein und nicht nur auf Gewohnheit beruhen.

Wie prüft man, ob Nutzer ein Sicherheitsupdate wirklich erhalten?

Ein veröffentlichtes Update ist nicht automatisch ein erfolgreich verteiltes Update. Hersteller sollten, soweit technisch und datenschutzrechtlich vertretbar, beobachten können, welche unterstützten Versionen noch im Feld sind und ob kritische Security Releases angenommen werden.

Bei Produkten ohne Telemetrie kann der Hersteller andere Signale nutzen: Supportanfragen, Downloadzahlen, Geräteverwaltung beim Geschäftskunden oder gezielte Kundenkommunikation. Ziel ist keine lückenlose Überwachung der Nutzer, sondern eine realistische Einschätzung, ob ein erhebliches Sicherheitsproblem tatsächlich gemindert wurde.

Welche Informationen sollten in einem Security Advisory stehen?

Ein gutes Advisory nennt Produkt und betroffene Versionen, Sicherheitswirkung, Schweregrad oder Priorität, verfügbare Korrektur, temporäre Maßnahmen und Installationshinweise. Es sollte außerdem klar sagen, ob aktive Ausnutzung bekannt ist und ab welcher Version das Problem behoben ist.

Marketingformulierungen wie „kleine Stabilitätsverbesserungen“ sind bei sicherheitsrelevanten Updates kontraproduktiv. Nutzer brauchen genügend Information, um die Dringlichkeit zu verstehen. Gleichzeitig sollten Details, die unmittelbar neue Angriffe erleichtern, nicht voreilig veröffentlicht werden.

Wie passt der Updateprozess zur CRA-Konformität?

Die Konformität eines Produkts ist kein einmaliger Zustand am Tag der CE-Kennzeichnung. Der Hersteller muss während des Supportzeitraums auf neue Schwachstellen reagieren und seine Prozesse wirksam halten. Deshalb gehört der Updateprozess zur laufenden Produkt-Compliance.

Bei wesentlichen Änderungen kann zusätzlich eine neue Konformitätsbewertung relevant werden. Der geplante Beitrag zur wesentlichen Änderung nach CRA grenzt normale Security Patches von Änderungen ab, die Zweckbestimmung oder Risikoprofil grundlegend verändern.

Wie sollte die Verantwortung zwischen Entwicklung, Security und Support verteilt sein?

Entwicklung baut und testet den Fix, Security bewertet Risiko und Angriffsrelevanz, Support sorgt für verständliche Kommunikation und Rückmeldungen aus dem Feld. Product oder Release Management koordiniert Versionen und Rollout. Diese Aufteilung verhindert, dass ein Security Patch ausschließlich als technisches Ticket behandelt wird.

Für kritische Fälle sollte zusätzlich klar sein, wer die finale Veröffentlichung freigibt und wer bei einem fehlgeschlagenen Rollout eskaliert. Eine kurze RACI-Matrix reicht oft, solange sie mit realen Zuständigkeiten hinterlegt ist.

Wie lässt sich ein Updateprozess regelmäßig prüfen?

Mindestens einmal pro Jahr und nach größeren Prozessänderungen sollte ein vollständiger Test stattfinden. Dabei wird ein fiktiver Security-Fall von der Entdeckung über Patchentwicklung und Freigabe bis zur Nutzerinformation durchgespielt.

Besonders aufschlussreich sind die Übergaben zwischen Teams. Wenn Entwicklung den Fix fertig hat, aber niemand weiß, wer Advisory, Downloadbereich oder Kundeninformation aktualisiert, zeigt der Test genau die Lücke, die im Ernstfall Zeit kostet.