ENISA-Leitfaden zu sicheren Update-Mechanismen: was der CRA verlangt

ENISA bittet bis zum 10. Juli 2026 um Ihr Feedback. Der zweite Technical Advisory zur Produktsicherheit, Secure Update Mechanisms, liegt als Entwurf vor, und die Konsultation läuft jetzt.

Darum ist der Entwurf wichtig. Er nimmt die CRA-Pflicht zur sicheren Bereitstellung von Aktualisierungen und zerlegt sie in sieben Schritte, jeder davon an ein reales Versagen geknüpft. Vier waren Angriffe: SolarWinds, ASUS, Notepad++ und Trivy. Einer, der CrowdStrike-Ausfall von 2024, war ein fehlerhaftes Release, kein Angriff. ENISA ordnet jedem Schritt dann Kontrollen zu, die Wahrscheinlichkeit oder Wirkung der Bedrohung senken. Dieser Leitfaden holt die Teile heraus, die ein Kleinst-, Klein- oder mittlerer Hersteller braucht, knüpft sie an Ihre CRA-Pflichten, ergänzt unsere eigene Sicht auf Werkzeuge und Prioritäten und geht das Thermostat-Beispiel durch, mit dem ENISA alles zusammenbindet.

Was der Advisory ist, und was nicht

Der ENISA Technical Advisory on Secure Update Mechanisms ist ein Entwurf vom Mai 2026, in den Seitenköpfen als Version 0.1 ausgewiesen. Die veröffentlichte Datei heißt v0.6, was ein Tippfehler zu sein scheint. ENISA hat den Entwurf zur öffentlichen Konsultation freigegeben, die Feedback-Umfrage schließt am 10. Juli 2026.

Er richtet sich an Hersteller von Produkten mit digitalen Elementen, besonders an die Teams, die Update-Mechanismen entwerfen, bauen oder betreiben. ENISA hat ihn für Kleinst-, Klein- und mittlere Hersteller geschrieben, die gängige Update-Bedrohungen verstehen und eine Reihe von Kontrollen umsetzen müssen, ohne ein großes Sicherheitsteam aufzubauen.

Seien Sie sich über die Grenzen im Klaren. ENISA nennt drei davon direkt.

Was er Ihnen liefert, ist eine gemeinsame Landkarte. Derselbe Sieben-Schritte-Lebenszyklus zieht sich durch den Bedrohungsteil und den Kontrollteil, eine Kontrolle verweist also immer auf die Bedrohung, die sie beantwortet.

Der Update-Lebenszyklus in sieben Schritten

ENISA beschreibt jedes Update, ob Firmware, Binary, Delta-Patch, Signaturdatei oder Konfigurationsänderung, als denselben Ablauf in sieben Schritten. Fünf Akteure tragen sie: der Producer (Hersteller), der Publication Service, das Update-Repository, der Client-Updater und der Endpunkt.

Die sieben Schritte laufen über drei Vertrauenszonen. Die Producer-Vertrauenszone ist der Ort, an dem das Update gebaut und signiert wird. Die Distributionszone, die Repositories und CDNs umfasst, gilt als weniger vertrauenswürdig. Die Geräte-Vertrauenszone ist der Ort, an dem das Update geprüft und installiert wird.

Die nützlichste Idee des Dokuments steht hinter dieser Grafik.

Wie Updates wirklich auf das Gerät kommen

Der Lebenszyklus ist überall gleich. Wer jeden Schritt ausführt, nicht. ENISA nennt vier Auslieferungsmodelle, und das Modell entscheidet, wo Ihre Kontrollen liegen müssen. Die Matrix unten zeigt, wer jeden Schritt ausführt, damit Sie sehen, welche Felder Sie selbst bauen.

Die Beispiele von ENISA: In-Band deckt Desktop-App-Updater, In-Product-Plugin-Updater und Browser-Auto-Update ab. Plattformverwaltet deckt mobile App-Stores, Linux-Paket-Repositories, MDM-Plattformen und Browser-Extension-Stores ab. Manuelles Out-of-Band deckt einen Installer von der Hersteller-Website, einen Patch über ein sicheres Portal oder ein per E-Mail versandtes Paket ab. Enterprise oder gestuft deckt WSUS-artiges Staging, Enterprise-Mirrors, Patch-Management-Server und Air-Gap-Transfer ab.

Für einfache Designs beschreibt ENISA ein Gerät, das einem öffentlichen Root-Schlüssel plus einem operativen Signaturschlüssel vertraut. Fortgeschrittenere Designs trennen die Signaturrollen, und Deployments mit höherem Sicherheitsbedarf ergänzen Schwellensignaturen, bei denen mehr als ein Schlüsselinhaber eine sensible Änderung freigeben muss. TUF und Uptane formalisieren diese Rollentrennung. Sie müssen keines von beiden übernehmen, um den Basisschutz zu erreichen.

Sieben Wege, wie der Update-Kanal angegriffen wird

Diesen Teil lesen Sie zweimal. ENISA geht jeden Lebenszyklus-Schritt durch, nennt Bedrohung, Wirkung und einen realen Vorfall. Das Muster ist gleich: Eine Kompromittierung früh in der Kette bleibt unsichtbar, wenn spätere Schritte alles als normal behandeln. Die Tabelle unten ist Abschnitt 3 des Advisory, verdichtet, ergänzt um die wichtigste Kontrolle aus Abschnitt 4.

Das Bedrohungsmodell von ENISA ist breit. Angreifer können Build-Pipelines, Signaturschlüssel, Publication Services, Repositories, CDNs, DNS, Metadaten-Replay, den Client-seitigen Update-Zustand oder den Installations-Workflow ins Visier nehmen. Die Mischung aus schädlichen Fällen (SolarWinds, ASUS) und einem nicht schädlichen (CrowdStrike) ist Absicht. Ein sicherer Update-Mechanismus muss sowohl einen Angreifer als auch ein schlechtes Release überstehen.

STRIDE auf einen Blick

Anhang 1 des Advisory bildet die Bedrohungen auf die Microsoft-STRIDE-Kategorien ab. Es ist eine indikative Zuordnung, nicht erschöpfend, und mehrere Bedrohungen reichen über mehr als eine Kategorie. Wenn Sie dieses Jahr eine Threat-Modeling-Sitzung machen, nutzen Sie diese Tabelle als Agenda: Gehen Sie Ihren Update-Kanal Schritt für Schritt durch und fragen Sie, welche STRIDE-Kategorie an jeder Stelle am härtesten zubeißt. Für ein schlankes Team verdienen die Zeilen Manipulation und Spoofing bei den Schritten Abrufen und Prüfen die meiste Zeit, denn dort landeten die Angriffe ASUS und Notepad++.

Die Kontrollen, so gruppiert, wie ENISA sie gruppiert

Abschnitt 4 fasst die Kontrollen in vier Stufen und richtet sie am ENISA-Playbook Secure by Design and Default aus. Der vollständige Advisory listet 36 benannte Empfehlungen. Die Tabellen unten behalten je Stufe die mit dem höchsten Wert. Für den vollständigen Satz lesen Sie die Quelle.

Vorbereitung und Veröffentlichung

Diese Stufe deckt das Bauen, Autorisieren und Veröffentlichen des Updates und seiner Metadaten ab.

Discovery und Abruf

Diese Stufe entscheidet, wie Clients Updates finden und herunterladen, ohne umgeleitet oder mit veralteten Daten versorgt zu werden.

Verifikation und Installation

Das ist der zentrale Punkt der Vertrauensentscheidung. Versagt er, werden frühere Kompromittierungen zu gültigen Updates.

1. Signaturprüfung. Prüfen Sie die Echtheit der Metadaten und bestätigen Sie, dass das Artefakt kryptografisch an sie gebunden ist.
2. Anwendbarkeitsprüfung. Bestätigen Sie vor der Installation, dass das Update zu diesem Produkt, dieser Version und dieser Konfiguration passt.
3. Integritätsdurchsetzung. Validieren Sie den Artefakt-Hash und lehnen Sie beschädigte oder veränderte Inhalte vor der Installation ab.
4. Versionskontrolle und Anti-Rollback. Blockieren Sie die Installation älterer oder unautorisierter Versionen über Rollback-Zähler oder monoton steigende Sequenznummern.
5. Autorisierter Installationskontext. Nur vertrauenswürdige, autorisierte Komponenten dürfen die Installation starten und ausführen, mit Least-Privilege-Beschränkungen. Das ist die Kontrolle gegen die Bedrohung durch erhöhte Rechte beim Installationsschritt.
6. Atomares Update-Verhalten. Das System wechselt vollständig auf die neue Version oder bleibt sicher auf der vorherigen, mit Recovery bei einem Fehler.

Beobachtbarkeit und Recovery

Diese Stufe protokolliert Ergebnisse, macht Fehler sichtbar und lässt das Gerät sich erholen.

Wie Teams das mit Open-Source-Werkzeugen bauen

ENISA hält den Advisory technologieneutral und nennt Frameworks und Leitlinien wie TUF, Uptane, SLSA, in-toto und NIST SP 800-40, ohne konkrete Werkzeuge zu empfehlen. Für eine Behörde ist das richtig, lässt aber die praktische Frage offen. Die Zuordnung unten ist unsere, nicht die von ENISA. Keines dieser Werkzeuge ist ein Konformitätszertifikat. Sie setzen die Technik um. Den Nachweis verantworten Sie weiterhin selbst.

Bauen Sie den Updater in Abhängigkeitsreihenfolge

Dieser Teil ist unsere Empfehlung, nicht die von ENISA. Ein Vorbehalt zuerst: Das ist keine Auswahlliste zum Aufhören. Der CRA verlangt jede anwendbare grundlegende Cybersicherheitsanforderung, die auf Ihr Produkt zutrifft, nach Ihrer Risikobewertung gemäß Anhang I, das Ziel ist also der vollständige Satz an Kontrollen. Was folgt, ist die Reihenfolge, in der wir sie bauen würden, damit ein kleines Team nicht an 36 Empfehlungen erstarrt. Die Grundlage macht die späteren Kontrollen erst sinnvoll, die Reihenfolge zählt also.

1. Metadaten signieren und auf dem Gerät prüfen. Richten Sie einen Root-Vertrauensanker ein und prüfen Sie die Signatur, bevor etwas installiert wird. Tun Sie das zuerst, denn jede andere Kontrolle setzt voraus, dass das Gerät nur echte Updates akzeptiert. Ohne sie ist der Rest Dekoration.
2. Den Transport absichern. TLS für Discovery und Abruf, und jedes CDN oder jeden Mirror als nicht vertrauenswürdig behandeln. Das ist meist Konfiguration, also günstig, und es schließt den ASUS-artigen Abruf-Angriff.
3. Hash- und Anwendbarkeitsprüfungen ergänzen. Kleine Ergänzungen beim Prüfschritt: bestätigen, dass der Artefakt-Hash zum signierten Manifest passt und dass das Update zu diesem Modell und dieser Version passt. Geringer Aufwand, sobald die Signierung steht.
4. Anti-Rollback früh einplanen. Es ist die am schwersten nachzurüstende Kontrolle, weil sie geschützten Zähler-Zustand und Bootloader-Mitwirkung braucht, planen Sie sie also jetzt, auch wenn sie später landet. Es ist die Freeze- und Downgrade-Abwehr, die ENISA am stärksten betont.
5. Installationen atomar machen, mit Rollback. A/B oder redundante Slots, damit ein schlechtes Release (der CrowdStrike-Fehlerfall) das Gerät nicht unbrauchbar macht. Das ist ein großer Aufwand, wenn handgebaut, weshalb hier meist ein gepflegtes Framework gewinnt.
6. Ergebnisse protokollieren und melden. Ein manipulationssicheres Update-Log und Fehlermeldung, damit Sie ein Problem erkennen und belegen können, was geschah. Daraus schöpft auch Ihr CRA-Nachweis.

Ein durchgerechnetes Beispiel: ein Thermostat-Patch ausliefern

ENISA schließt mit einem konkreten Beispiel, und es ist der klarste Teil des Dokuments. Ein eingebettetes IoT-Thermostat in Version 1.0.0 braucht eine Sicherheitsaktualisierung, die EUVDB-202X-Y behebt, einen Fehler in der Eingabevalidierung. Das Gerät nutzt einen In-Band-Updater. Das Beispiel ist illustrativ, kein universeller Bauplan.

Der Hersteller betreibt zwei Signierebenen. Eine Root-Signaturinstanz bleibt offline und autorisiert einen operativen Vendor-Signaturschlüssel für reguläre Releases. Diese Trennung lässt den Vendor-Schlüssel rotieren, ohne den Root-Vertrauensanker des Geräts zu ändern.

Das Gerät wird mit den unten gezeigten Teilen ausgeliefert.

Vorbereitung. Der Build läuft in einer kontrollierten Umgebung mit nur autorisiertem Code und autorisierten Abhängigkeiten. Eine SBOM wird erzeugt und auf Schwachstellen geprüft. Der Hersteller erzeugt eine signierte manifest.json mit dem SHA-256-Hash und der Dateigröße, dem zutreffenden Produkt und der Version, Frische- und Anti-Rollback-Feldern (Zeitstempel, Ablauf, Rollback-Zähler) sowie Advisory-Informationen (Schwere, Advisory-URL). Eine Änderung des Pakets auf Byte-Ebene erzeugt einen anderen Hash, der auf dem Gerät auffällt.

openssl dgst -sha256 -sign keys/vendor_private.pem \
  -out repo/manifest.json.sig repo/manifest.json

Discovery. Das Thermostat prüft über TLS auf Updates und validiert das Server-Zertifikat gegen ca.pem. Die Felder update_type und severity lassen es eine Sicherheitsaktualisierung von einem regulären Release unterscheiden und den Nutzer entsprechend benachrichtigen. Downloads landen in staging, sodass ein Stromausfall mitten im Download die laufende Firmware nie berührt.

curl --tlsv1.2 --cacert /etc/ssl/certs/ca.pem \
  https://updates.acme.com/device/manifest.json -o manifest.json

Verifikation und Installation. Vor der Installation führt das Gerät fünf Prüfungen in dieser Reihenfolge aus. Schlägt eine fehl, bricht es ab.

Die Anti-Rollback-Prüfung wiegt am schwersten. Der Rollback-Zähler des Geräts steigt erst, nachdem neue Firmware bootet und ihre Health-Checks besteht, ein fehlgeschlagenes oder schädliches Update kann die Schwelle also nicht heimlich anheben und einen späteren Fix aussperren. Bei Erfolg schreibt die Firmware in den inaktiven Slot und aktiviert mit einem atomaren Slot-Wechsel, sodass immer eine als gut bekannte Version bleibt. Beobachtbarkeit protokolliert jeden Versuch in einem zugriffsbeschränkten update.log mit Zeitstempel und Status. Wird der Vendor-Schlüssel je kompromittiert, signiert der Hersteller einen neuen Vendor-Schlüssel und liefert ihn aus, den der Root-Schlüssel autorisiert. Der Root-Schlüssel wird nie über diesen Kanal aktualisiert. Eine Root-Kompromittierung braucht einen separaten sicheren Prozess wie ein Factory Reset.

Was das für Ihre CRA-Akte bedeutet

Die letzte Tabelle des Advisory paart jede Sicherheitsaussage mit Beispiel-Nachweisen und Artefakten. Diese Zuordnung ist die Brücke zu Ihrer technischen Dokumentation. Die technische Dokumentation des CRA verlangt beides: eine Beschreibung Ihrer Lösung zur sicheren Verbreitung von Aktualisierungen (Anhang VII) und den Nachweis dahinter, einschließlich einer Software-Stückliste (SBOM) und Testberichten. Eine Beschreibung ohne Substanz dahinter ist die Schwachstelle.

Die Sicherheitsaussagen des Beispiels und der Nachweis, der jede stützt, sehen so aus.

Jede Zeile stützt eine oder mehrere Anforderungen aus CRA Anhang I, von Integrität und sicherer Verbreitung bis zu Monitoring und Verfügbarkeit. Die Details auf Artikelebene finden Sie unter CRA-Anforderungen an Sicherheitsaktualisierungen.

Wenn Sie die rechte Spalte heute nicht liefern können, ist diese Lücke Ihr Arbeitspunkt. Ein VEX-Eintrag und eine SBOM-gestützte Abhängigkeitsprüfung decken zwei dieser Zeilen direkt ab. Ihre Lieferanten-Sorgfaltsprüfung deckt die Vertrauenszeile für Komponenten ab, die Sie nicht selbst geschrieben haben.

Dieser Artikel dient nur zu Informationszwecken und stellt keine Rechtsberatung dar. Für konkrete Compliance-Beratung wenden Sie sich an qualifizierten Rechtsbeistand.