CRA Update-Archivierung: Security Updates, Altversionen und 10-Jahres-Verfügbarkeit

Security Updates müssen nach dem Cyber Resilience Act nicht nur veröffentlicht, sondern langfristig verfügbar gehalten werden. Für während des Supportzeitraums bereitgestellte Sicherheitsupdates gilt grundsätzlich: Sie müssen mindestens zehn Jahre ab Veröffentlichung oder für den verbleibenden Supportzeitraum verfügbar bleiben – je nachdem, welcher Zeitraum länger ist.

Den Zusammenhang erläutert der Cyber Resilience Act im Überblick. Weitere Fachthemen finden Sie in der zugehörigen CRA-Themenübersicht.

Welche Archiv- und Supportregeln gelten für Sicherheitsupdates?

Bereits veröffentlichte Sicherheitsupdates müssen nach der einschlägigen CRA-Regel langfristig verfügbar bleiben. Diese Verfügbarkeit ist von der aktiven Unterstützung alter Softwarezweige zu unterscheiden.

Wie lange müssen Security Updates verfügbar bleiben?

Artikel 13 verlangt, dass während des Supportzeitraums bereitgestellte Sicherheitsupdates mindestens zehn Jahre nach ihrer Ausgabe oder für den verbleibenden Supportzeitraum verfügbar bleiben, wenn dieser länger ist. Diese Regel beeinflusst Speicher, Release-Infrastruktur, Signaturschlüssel und Dokumentationsprozesse.

Der Zeitraum ist von der Frage zu unterscheiden, wie lange ein Produkt aktiv unterstützt werden muss. Der CRA-Supportzeitraum legt fest, wie lange Schwachstellen behandelt und Updates bereitgestellt werden müssen; die Archivpflicht bestimmt zusätzlich, wie lange bereits veröffentlichte Security Updates abrufbar bleiben.

Müssen alte Produktversionen weiterhin gepatcht werden?

Das hängt vom Supportstatus und den Voraussetzungen des Artikels 13 ab. Für Software mit wesentlich geänderten Folgeversionen kann der Hersteller die Vulnerability-Handling-Pflichten unter bestimmten Bedingungen auf die zuletzt in Verkehr gebrachte Version konzentrieren, wenn Nutzer älterer Versionen die aktuelle Version kostenlos erhalten und keine zusätzlichen Kosten für Anpassungen der Hardware- oder Softwareumgebung entstehen.

Diese Möglichkeit sollte nicht pauschal als Recht verstanden werden, jede ältere Version sofort einzustellen. Produktmodell, Supportzusagen, technische Migrationsfähigkeit und konkrete Änderungen müssen berücksichtigt und dokumentiert werden.

Was bedeutet „kostenlos auf die aktuelle Version wechseln“?

Die Regel soll verhindern, dass Nutzer für notwendige Sicherheitsunterstützung gezwungen werden, ein kostenpflichtiges Upgrade oder neue Infrastruktur zu erwerben. Wenn der Hersteller eine ältere Softwareversion nicht mehr eigenständig pflegt, muss der Wechsel auf die unterstützte Version unter den genannten Voraussetzungen ohne zusätzliche Kosten möglich sein.

Ist für die neue Version neue Hardware, ein anderes Betriebssystem oder eine kostenpflichtige Plattformmigration erforderlich, muss genauer geprüft werden, ob die Voraussetzungen tatsächlich erfüllt sind.

Wie behandelt man LTS- und normale Release-Kanäle?

Long-Term-Support-Kanäle können die Update-Strategie vereinfachen, wenn klar dokumentiert ist, welche Releases wie lange unterstützt werden. Nutzer müssen erkennen können, ob sie auf einem LTS-, Standard- oder bereits abgekündigten Kanal arbeiten.

Für jede unterstützte Linie sollte ein Security-Status existieren. Der Hersteller muss bei einer neuen Schwachstelle schnell bestimmen können, welche Linien betroffen sind und für welche ein Patch oder eine sichere Migration bereitgestellt wird.

Was gehört in ein nutzerfähiges Update-Archiv?

Ein nutzerfähiges Archiv verbindet das unveränderte Paket mit Version, Voraussetzungen und Sicherheitsinformationen. Ein gewöhnliches Backup allein ermöglicht diese Zuordnung nicht.

Was gehört in ein Update-Archiv?

Ein Archiv sollte eine Sicherheitskorrektur eindeutig einem Produkt und einer Version zuordnen. Neben dem eigentlichen Paket sind Release-Metadaten, unterstützte Ausgangsversionen, Installationsweg, bekannte Voraussetzungen und Integritätsinformationen wichtig.

Warum reicht ein normales Backup des Downloadservers nicht?

Ein Backup schützt gegen Datenverlust, ist aber kein nutzerfähiges Archiv. Nutzer und Support müssen gezielt die richtige Fassung finden können. Außerdem muss nachvollziehbar bleiben, ob ein Paket unverändert und authentisch ist.

Deshalb braucht es einen gepflegten Katalog, Versionierung und Zugriffskonzept. Ein Backup kann Teil der technischen Resilienz sein, ersetzt aber nicht den geplanten Archiv- und Veröffentlichungsprozess.

Welche Metadaten sollten nie verloren gehen?

Besonders wichtig sind Produktname, Version, Build-ID, Veröffentlichungsdatum, unterstützte Plattform, Abhängigkeiten, Security-Bezug, Signaturstatus und EOL-/Supportstatus. Ohne diese Daten kann eine Datei Jahre später kaum noch sicher eingeordnet werden.

Auch die SBOM sollte versionsbezogen archiviert werden. Sonst lässt sich später nicht mehr rekonstruieren, welche Komponenten in einem historischen Release enthalten waren.

Wie trennt man interne Builds von veröffentlichten Releases?

Entwicklungsartefakte und offiziell veröffentlichte Produktversionen brauchen unterschiedliche Retention. Ein CI-System kann temporäre Builds nach kurzer Zeit löschen, während freigegebene Security Updates in einen geschützten Archivbereich überführt werden. Dieser Übergang sollte Teil der Release-Freigabe sein.

Damit wird verhindert, dass die Aufbewahrungspflicht von den Cleanup-Regeln eines Entwicklungssystems abhängt. Gleichzeitig bleibt das Archiv übersichtlich und enthält nur tatsächlich relevante, freigegebene Artefakte.

Wie bleiben Pakete und Bereitstellungsstände überprüfbar?

Herkunft, Integrität und Verteilung müssen langfristig nachvollziehbar bleiben. Zurückgezogene Pakete und geänderte Vertrauensanker benötigen eine ausdrücklich geregelte Behandlung.

Wie werden Signaturen und Prüfsummen langfristig behandelt?

Wenn Updates signiert werden, muss die Verifikationskette über lange Zeit funktionieren. Das betrifft Signaturschlüssel, Zertifikate, Zeitstempel und gegebenenfalls vertrauenswürdige Root-Schlüssel. Läuft ein Zertifikat ab, darf dadurch ein historisches Update nicht automatisch unverifizierbar werden.

Hersteller sollten deshalb bereits in Kryptografie und Schlüsselmanagement planen, wie historische Pakete geprüft werden können und wie kompromittierte oder rotierte Schlüssel behandelt werden.

Wie behandelt man zurückgezogene Updates?

Ein Update kann wegen eines Fehlers zurückgezogen werden. Das Archiv sollte diesen Zustand sichtbar machen, statt die Datei kommentarlos verschwinden zu lassen. Nutzer und Support müssen erkennen können, dass die Fassung nicht mehr empfohlen wird und welche Ersatzversion gilt.

Wenn das zurückgezogene Update eine Sicherheitskorrektur enthielt, muss bewertet werden, wie die Schutzwirkung anderweitig hergestellt wird. Ein Rollback auf eine bekannte verwundbare Fassung ist nicht automatisch eine ausreichende Lösung.

Was gilt für automatische Update-Server?

Ein Auto-Update-Dienst braucht neben dem aktuellen Kanal auch langfristige Speicherung und nachvollziehbare Metadaten. Manifeste, Signaturen, Rolloutregeln und verfügbare Pakete sollten versioniert sein. So kann später nachvollzogen werden, was ein Produkt zu einem bestimmten Zeitpunkt angeboten bekam.

Der Artikel CRA-Sicherheitsupdates behandelt sichere Verteilung, Rollback und automatische Installation im Detail.

Wie werden Altversionen und Migration verständlich kommuniziert?

Nutzer müssen zwischen unterstützten und nur historisch verfügbaren Fassungen unterscheiden können. Ein geeigneter Migrationsweg erklärt Voraussetzungen und Risiken statt nur eine neue Datei anzubieten.

Dürfen historische Softwareversionen öffentlich archiviert werden?

Ja. Der CRA lässt öffentliche Softwarearchive für historische Versionen grundsätzlich zu. Nutzer müssen jedoch klar über die Risiken informiert werden, wenn Software außerhalb des Supportzeitraums liegt oder bekannte Sicherheitsprobleme nicht mehr behoben werden.

Ein öffentliches Archiv sollte deshalb nicht so aussehen, als seien alle dort angebotenen Fassungen gleichermaßen empfohlen oder unterstützt. Sichtbare Statushinweise und eine klare Empfehlung für die aktuelle sichere Version sind wichtig.

Wie warnt man bei nicht mehr unterstützten Altversionen?

Warnungen sollten unmittelbar bei der Downloadmöglichkeit stehen und verständlich erklären, dass die Version außerhalb des Supports liegt und Sicherheitsupdates möglicherweise fehlen. Eine versteckte Fußnote am Seitenende reicht für eine klare Risikokommunikation kaum aus.

Wo möglich sollte auf die aktuelle unterstützte Version oder einen sicheren Migrationspfad verwiesen werden. Bei besonders riskanten Altversionen kann zusätzlich ein Security Advisory sinnvoll sein.

Wie werden Nutzer bei einer Migration unterstützt?

Wenn ältere Softwarelinien nicht mehr separat gepflegt werden und Nutzer kostenlos auf die aktuelle Fassung wechseln können, braucht es verständliche Migrationshinweise. Diese sollten Voraussetzungen, Datensicherung, Kompatibilität und mögliche Rückfalloptionen erklären.

Eine technisch kostenlose Datei genügt nicht, wenn der Wechsel praktisch undokumentiert oder unnötig riskant ist. Die sichere Migration ist Teil einer glaubwürdigen Supportstrategie.

Welche Rolle spielt der Support bei historischen Versionen?

Supportmitarbeiter müssen erkennen können, ob eine alte Version noch unterstützt, nur archiviert oder ausdrücklich unsicher ist. Eine zentrale Versionsmatrix verhindert widersprüchliche Aussagen an Kunden und hilft, bei Sicherheitsfragen auf die richtige aktuelle Fassung zu verweisen.

Ändert sich ein Supportstatus, sollten Downloadseite, Advisory, Produktdokumentation und interne Wissensbasis gemeinsam aktualisiert werden.

Wie verhindert man Verwechslungen zwischen unterstützten und nur archivierten Versionen?

Der Status sollte technisch und visuell eindeutig sein. Ein archiviertes Paket kann verfügbar bleiben, ohne noch aktiv unterstützt zu sein. Downloadseiten sollten deshalb zwischen „aktuell unterstützt“, „Security Support“, „End of Support“ und „nur historisches Archiv“ unterscheiden.

Diese Kennzeichnung hilft Nutzern und Suchmaschinen gleichermaßen, nicht eine alte Fassung als aktuelle Empfehlung zu interpretieren. Für Support und Vertrieb reduziert sie außerdem das Risiko widersprüchlicher Aussagen.

Wie wird langfristige Verfügbarkeit technisch abgesichert?

Löschschutz, Redundanz und getestete Plattformwechsel verhindern vermeidbare Verluste. Stabile Links und kontrollierte Weiterleitungen halten ältere Hinweise praktisch nutzbar.

Wie verhindert man versehentliche Löschung historischer Releases?

Retention-Regeln sollten technisch erzwungen werden. Ein Cleanup-Skript darf Security-Pakete nicht nach denselben kurzen Speicherfristen löschen wie temporäre Builds. Sinnvoll sind getrennte Speicherklassen und Löschschutz für veröffentlichte Security Releases.

Zusätzlich sollte regelmäßig geprüft werden, ob Dateien tatsächlich abrufbar und verifizierbar sind. Ein Archiv, dessen Links nach Jahren ins Leere laufen, erfüllt seinen Zweck nicht.

Welche Rolle spielt Redundanz?

Langfristige Verfügbarkeit sollte nicht von einem einzigen Server oder Anbieter abhängen. Replizierte Speicherung, Backups und getestete Wiederherstellung reduzieren das Risiko, dass ein technischer oder geschäftlicher Ausfall das Updatearchiv zerstört.

Die Schutzmaßnahmen gehören zur Resilienzstrategie. Dabei müssen auch Integrität und Zugriffsschutz des Archivs berücksichtigt werden.

Wie behandelt man Produkte nach Unternehmens- oder Plattformwechsel?

Wechselt der Hersteller Downloadplattform, Domain, CDN oder Cloudanbieter, müssen historische Links und Updates weiter erreichbar bleiben. Redirects, neue Archivseiten oder Datenmigration sollten geplant und getestet werden.

Das gilt ebenso bei Firmenübernahmen oder Rebranding. Produktidentifikation und historische Nachweise dürfen nicht verloren gehen, nur weil Marketingnamen geändert werden.

Wie sollten Weiterleitungen und Download-URLs langfristig geplant werden?

Historische Security Updates werden häufig über Links in alten Advisories, Handbüchern oder Kundentickets gefunden. Ändert sich die Website-Struktur, sollten diese Verweise möglichst erhalten oder dauerhaft weitergeleitet werden. Ein funktionierendes Archiv hilft wenig, wenn alle veröffentlichten Referenzen auf gelöschte URLs zeigen.

Für besonders langlebige Produkte sind stabile, versionsbezogene Downloadpfade sinnvoll. Redirect-Regeln sollten nach Relaunchs oder Domainwechseln getestet und nicht nach wenigen Monaten wieder entfernt werden.

Wie werden Archivbetrieb und Nachweise kontrolliert?

Eine gepflegte Richtlinie und praktische Abruf- und Installationstests zeigen, ob das Archiv seinen Zweck erfüllt. Änderungen und offene Fehler werden mit Verantwortlichen und Maßnahmen dokumentiert.

Wie dokumentiert man die Archivpflicht intern?

Eine kurze Archivrichtlinie sollte definieren, welche Releases geschützt werden, wie lange sie gespeichert bleiben, wer sie löschen darf, welche Metadaten verpflichtend sind und wie Integritätsprüfungen erfolgen. Für Security Updates gilt die längere CRA-Aufbewahrungslogik.

Die Richtlinie sollte mit Release-Management, Support, Security und IT abgestimmt sein. Sonst löscht möglicherweise ein Infrastrukturteam Dateien, die aus Produktsicherheitsgründen noch benötigt werden.

Welche Fehler treten häufig auf?

• Security Updates liegen nur im aktuellen Downloadordner und werden beim nächsten Release überschrieben.
• Historische Pakete haben keine eindeutige Produktzuordnung.
• Signatur- oder Verifikationsschlüssel laufen ohne Migrationsplan aus.
• EOL-Versionen werden ohne Risikowarnung weiter angeboten.
• SBOM und Release-Metadaten werden nicht gemeinsam archiviert.
• Alte Downloadlinks brechen nach Website-Relaunch oder Anbieterwechsel.
• Backup wird mit einem nutzerfähigen Archiv verwechselt.

Wie können KMU ein Updatearchiv pragmatisch aufbauen?

Ein KMU kann mit einem unveränderlichen Releaseordner pro Produkt und Version beginnen. Jede Veröffentlichung erhält Paket, Prüfsumme oder Signatur, Release Notes, Advisory und eine kleine Metadatendatei mit Supportstatus. Security-Releases werden durch eine Retention-Regel besonders geschützt.

Einmal jährlich werden Stichproben heruntergeladen und geprüft. Damit lässt sich mit überschaubarem Aufwand zeigen, dass historische Sicherheitsupdates tatsächlich weiterhin verfügbar und intakt sind.

Wie hängen Archivierung und wesentliche Änderungen zusammen?

Bei größeren Softwareänderungen kann eine neue Produktversion ein deutlich anderes Risikoprofil besitzen. Der Beitrag wesentliche Änderung nach CRA erläutert, wann eine Änderung zusätzliche Hersteller- und Konformitätsfragen auslösen kann.

Für das Archiv ist wichtig, dass alte und neue Produktstände eindeutig getrennt bleiben. Ein Update für eine neue Architektur darf nicht versehentlich als Sicherheitskorrektur für eine inkompatible Altversion erscheinen.

Wie sollte ein jährlicher Archivtest aussehen?

Ein Archiv sollte regelmäßig praktisch geprüft werden. Dafür werden stichprobenartig alte Security Releases ausgewählt, über den öffentlichen oder vorgesehenen Supportweg heruntergeladen, anhand ihrer Signatur oder Prüfsumme verifiziert und in einer passenden Testumgebung installiert. Gleichzeitig wird kontrolliert, ob Advisory, Produktbezug und Supportstatus noch verständlich sind.

Dieser Test erkennt nicht nur verlorene Dateien, sondern auch abgelaufene Links, defekte Zertifikatsketten und Dokumentationslücken. Das Ergebnis kann als kurzer Nachweis in der technischen Produktakte abgelegt werden.

Wo stehen Archivierung und Altversionen im CRA?

Die maßgeblichen Regeln ergeben sich insbesondere aus Artikel 13 Absätze 9 bis 11 der Verordnung (EU) 2024/2847. Dort werden langfristige Verfügbarkeit von Sicherheitsupdates, Bedingungen für Folgeversionen und öffentliche Archive historischer Software geregelt.

Quellen geprüft am 4. Oktober 2026. Redaktion: Jörn Poppenhäger.