ENISA-advies over veilige updatemechanismen: een CRA-gids

ENISA wil uw feedback vóór 10 juli 2026. Het tweede technische advies over productbeveiliging, Secure Update Mechanisms, is verschenen als concept en de consultatie loopt nu.

Waarom het ertoe doet. Het advies neemt de eis van de Cyber Resilience Act om veilige updates te leveren en splitst die op in zeven stappen, elk gekoppeld aan een falen uit de praktijk. Vier waren aanvallen: SolarWinds, ASUS, Notepad++ en Trivy. Eén geval, de CrowdStrike-storing van 2024, was een gebrekkige release in plaats van een aanval. ENISA koppelt vervolgens elke stap aan maatregelen die de kans of de impact van die dreiging of dat falen verkleinen. Deze gids licht de onderdelen eruit die een micro-, kleine of middelgrote fabrikant nodig heeft, koppelt ze aan uw CRA-verplichtingen, voegt onze eigen kijk op tooling en prioriteiten toe, en loopt door het thermostaatvoorbeeld dat ENISA gebruikt om het geheel samen te brengen.

Wat het advies wel en niet is

Het ENISA Technical Advisory on Secure Update Mechanisms is een concept met datum mei 2026, in de paginakoppen aangeduid als Version 0.1. Het gepubliceerde bestand heet v0.6, wat een typefout lijkt. ENISA heeft het opengesteld voor openbare consultatie via een feedbackenquête die sluit op 10 juli 2026.

Het richt zich op fabrikanten van producten met digitale elementen, en in het bijzonder op de teams die updatemechanismen ontwerpen, bouwen of beheren. ENISA schreef het voor micro-, kleine en middelgrote fabrikanten die veelvoorkomende updatedreigingen moeten begrijpen en een reeks maatregelen moeten toepassen zonder een groot beveiligingsteam op te tuigen.

Wees helder over de grenzen. ENISA noemt er drie rechtstreeks.

Wat het u wel geeft, is een gedeelde kaart. Dezelfde levenscyclus van zeven stappen loopt door de dreigingensectie en de maatregelensectie, zodat een maatregel altijd terugverwijst naar de dreiging die hij beantwoordt.

De updatelevenscyclus, in zeven stappen

ENISA beschrijft elke update, of het nu firmware, een binary, een deltapatch, een handtekeningbestand of een configuratiewijziging is, als doorloop van dezelfde zeven stappen. Vijf actoren voeren ze uit: de producent (fabrikant), de publicatiedienst, de updaterepository, de client-updater en het eindpunt.

De zeven stappen lopen over drie vertrouwenszones. Het producentvertrouwensdomein is waar de update wordt gebouwd en ondertekend. Het distributiedomein, dat repositories en CDN's omvat, wordt als minder vertrouwd behandeld. Het apparaatvertrouwensdomein is waar de update wordt geverifieerd en geïnstalleerd.

Het meest bruikbare idee in het document zit achter dat schema.

Hoe updates het apparaat echt bereiken

De levenscyclus is overal hetzelfde. Wie elke stap uitvoert, niet. ENISA noemt vier leveringsmodellen, en het model bepaalt waar uw maatregelen moeten zitten. De matrix hieronder toont wie elke stap uitvoert, zodat u ziet welke cellen u zelf moet bouwen.

De voorbeelden die ENISA geeft: in-band omvat desktopapp-updaters, in-product plug-in-updaters en automatische browserupdates. Platformbeheerd omvat mobiele appstores, Linux-pakketrepository's, MDM-platforms en browserextensiestores. Out-of-band handmatig omvat een installer van een leverancierswebsite, een patch via een beveiligd portaal of een gemaild pakket. Enterprise of gefaseerd omvat WSUS-achtige fasering, enterprise-mirrors, patchbeheerservers en air-gapped overdracht.

Voor eenvoudige ontwerpen beschrijft ENISA een apparaat dat een publieke hoofdsleutel plus één operationele ondertekensleutel vertrouwt. Geavanceerdere ontwerpen gebruiken aparte ondertekenrollen, en uitrol met hogere zekerheid voegt drempelhandtekeningen toe, waarbij meer dan één sleutelhouder een gevoelige wijziging moet goedkeuren. TUF en Uptane formaliseren die rolscheiding. U hoeft geen van beide over te nemen om de basislijn te halen.

Zeven manieren waarop het updatekanaal wordt aangevallen

Dit is het deel dat u twee keer moet lezen. ENISA loopt elke levenscyclusstap af, benoemt de dreiging, de impact en een echt incident. Het patroon is consistent: een compromittering vroeg in de keten blijft onzichtbaar als latere stappen alles als normaal behandelen. De tabel hieronder is sectie 3 van het advies, ingedikt, met de primaire maatregel toegevoegd uit sectie 4.

Het dreigingsmodel dat ENISA aanneemt is breed. Aanvallers kunnen zich richten op buildpijplijnen, ondertekensleutels, publicatiediensten, repositories, CDN's, DNS, replay van metadata, de updatestatus aan de clientkant of de installatieworkflow. De mix van kwaadaardige gevallen (SolarWinds, ASUS) en een niet-kwaadaardig geval (CrowdStrike) is bewust. Een veilig updatemechanisme moet zowel een aanvaller als een slechte release overleven.

STRIDE in één oogopslag

Bijlage 1 van het advies koppelt de dreigingen aan de Microsoft STRIDE-categorieën. Het is een indicatieve koppeling, niet uitputtend, en meerdere dreigingen beslaan meer dan één categorie. Houdt u dit jaar één sessie voor dreigingsmodellering, gebruik deze tabel dan als agenda: loop uw updatekanaal stap voor stap door en vraag welke STRIDE-categorie bij elke stap het hardst toeslaat. Voor een klein team verdienen de rijen Manipulatie en Spoofing bij de stappen Ophalen en Controleren de meeste tijd, want daar landden de aanvallen op ASUS en Notepad++.

De maatregelen, gegroepeerd zoals ENISA ze groepeert

Sectie 4 bundelt de maatregelen in vier fasen en stemt ze af op de ENISA Secure by Design and Default-playbook. Het volledige advies somt 36 benoemde aanbevelingen op. De tabellen hieronder houden de waardevolste per fase aan. Lees de bron voor de volledige set.

Voorbereiding en publicatie

Deze fase betreft het bouwen, autoriseren en publiceren van de update en de bijbehorende metadata.

Ontdekking en ophalen

Deze fase bepaalt hoe clients updates vinden en downloaden zonder omgeleid te worden of verouderde gegevens te krijgen.

Verificatie en installatie

Dit is het primaire vertrouwensbeslispunt. Faalt het, dan worden eerdere compromitteringen geldige updates.

1. Handtekeningverificatie. Verifieer de authenticiteit van de metadata en bevestig dat het artefact er cryptografisch aan is gebonden.
2. Toepasselijkheidsvalidatie. Bevestig vóór installatie dat de update bij dit product, deze versie en deze configuratie past.
3. Integriteitshandhaving. Valideer de hash van het artefact en weiger beschadigde of gewijzigde inhoud vóór installatie.
4. Versiebeheer en anti-terugrol. Blokkeer installatie van oudere of ongeautoriseerde versies met terugroltellers of monotone volgnummers.
5. Geautoriseerde installatiecontext. Alleen vertrouwde, geautoriseerde componenten mogen de installatie starten en uitvoeren, met least-privilege-beperkingen. Dit is de maatregel tegen de dreiging van verhoogde rechten bij de installatiestap.
6. Atomisch updategedrag. Het systeem schakelt volledig over naar de nieuwe versie of blijft veilig op de vorige, met herstel bij falen.

Waarneembaarheid en herstel

Deze fase legt uitkomsten vast, brengt fouten aan het licht en laat het apparaat herstellen.

Hoe teams dit bouwen met opensourcetools

ENISA houdt het advies technologie-onafhankelijk en noemt frameworks en richtlijnen zoals TUF, Uptane, SLSA, in-toto en NIST SP 800-40, zonder specifieke tools aan te bevelen. Dat is de juiste keuze voor een toezichthouder, maar het laat de praktische vraag open. De koppeling hieronder is van ons, niet van ENISA. Geen van deze tools is een conformiteitscertificaat. Ze implementeren het engineeringwerk. Het bewijs blijft van u.

Bouw de updater in afhankelijkheidsvolgorde

Dit deel is onze richtlijn, niet die van ENISA. Eerst één voorbehoud: dit is geen verkorte lijst om bij te stoppen. De CRA vereist elke essentiële cyberbeveiligingsvereiste die op uw product van toepassing is, op basis van uw risicobeoordeling onder Bijlage I, dus het doel is de volledige set maatregelen. Wat volgt is de volgorde waarin wij ze zouden bouwen, zodat een klein team niet verlamd raakt door 36 aanbevelingen. De basis maakt de latere maatregelen zinvol, dus de volgorde doet ertoe.

1. Onderteken de metadata en verifieer op het apparaat. Voorzie een vertrouwensanker en controleer de handtekening voordat er iets installeert. Doe dit eerst, want elke andere maatregel gaat ervan uit dat het apparaat alleen authentieke updates accepteert. Zonder dit is de rest decoratie.
2. Vergrendel het transport. TLS voor ontdekking en ophalen, en behandel elke CDN of mirror als onvertrouwd. Dit is grotendeels configuratie, dus het is goedkoop, en het sluit de ASUS-achtige ophaalaanval.
3. Voeg hash- en toepasselijkheidscontroles toe. Kleine toevoegingen bij de verificatiestap: bevestig dat de hash van het artefact overeenkomt met het ondertekende manifest, en dat de update bij dit model en deze versie past. Weinig moeite zodra ondertekening op zijn plek is.
4. Plan anti-terugrol vroeg in. Het is de moeilijkste maatregel om achteraf in te bouwen, want hij vereist beschermde tellerstatus en medewerking van de bootloader, dus plan hem nu al, ook al landt hij later. Het is de verdediging tegen bevriezing en downgrade die ENISA het meest benadrukt.
5. Maak installaties atomisch, met terugrol. A/B of redundante slots, zodat een slechte release (de faalwijze van CrowdStrike) het apparaat niet onbruikbaar maakt. Dit is een groot werk als het met de hand wordt gemaakt, en daarom wint een onderhouden framework hier doorgaans.
6. Leg uitkomsten vast en rapporteer ze. Een manipulatiebestendig updatelogboek en foutrapportage, zodat u een probleem kunt detecteren en kunt aantonen wat er is gebeurd. Dit is ook waar uw CRA-bewijs uit put.

Een uitgewerkt voorbeeld: een thermostaatpatch uitleveren

ENISA sluit af met een concreet voorbeeld, en dat is het helderste deel van het document. Een embedded IoT-thermostaat op versie 1.0.0 heeft een beveiligingsupdate nodig die EUVDB-202X-Y patcht, een fout in de invoervalidatie. Het apparaat gebruikt een in-band updater. Het voorbeeld is illustratief, geen universele blauwdruk.

De fabrikant draait twee ondertekenniveaus. Een hoofdondertekenautoriteit blijft offline en autoriseert een operationele leverancierondertekensleutel voor routinematige releases. Door die splitsing kan de leveranciersleutel roteren zonder het vertrouwensanker van het apparaat te wijzigen.

Het apparaat wordt geleverd met de onderdelen die hieronder worden getoond.

Voorbereiding. De build draait in een gecontroleerde omgeving met alleen geautoriseerde code en afhankelijkheden. Een SBOM wordt gegenereerd en op kwetsbaarheden gecontroleerd. De fabrikant produceert een ondertekend manifest.json met de SHA-256-hash en bestandsgrootte, het toepasselijke product en de versie, versheids- en anti-terugrolvelden (tijdstempel, verloopdatum, terugrolteller) en advisory-informatie (ernst, advisory-URL). Een wijziging op byteniveau aan het pakket levert een andere hash op, die op het apparaat wordt opgevangen.

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

Ontdekking. De thermostaat controleert op updates via TLS en valideert het servercertificaat tegen ca.pem. Met de velden update_type en severity kan hij een beveiligingsupdate onderscheiden van een routinematige release en de gebruiker dienovereenkomstig informeren. Downloads belanden in staging, zodat een stroomstoring midden in een download de draaiende firmware nooit raakt.

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

Verificatie en installatie. Vóór installatie voert het apparaat vijf controles op volgorde uit. Faalt er een, dan breekt het af.

De anti-terugrolcontrole weegt het zwaarst. De terugrolteller van het apparaat gaat pas omhoog nadat nieuwe firmware opstart en de gezondheidscontroles doorstaat, zodat een mislukte of kwaadaardige update de ondergrens niet stilletjes kan verhogen en een latere fix kan buitensluiten. Bij succes schrijft de firmware naar de inactieve slot en activeert met een atomische slotomschakeling, zodat er altijd een bekende goede versie blijft. Waarneembaarheid legt elke poging vast in een toegangsbeperkte update.log met tijdstempel en status. Raakt de leveranciersleutel ooit gecompromitteerd, dan ondertekent de fabrikant een nieuwe leveranciersleutel en levert die uit, geautoriseerd door de hoofdsleutel. De hoofdsleutel wordt nooit via dit kanaal bijgewerkt. Compromittering van de hoofdsleutel vereist een apart veilig proces, zoals een fabrieksreset.

Wat dit betekent voor uw CRA-dossier

De laatste tabel van het advies koppelt elke beveiligingsclaim aan voorbeeldbewijs en -artefacten. Die koppeling is de brug naar uw technische documentatie. De technische documentatie van de CRA vraagt beide: een beschrijving van uw oplossing voor veilige updates (Bijlage VII) én het bewijs erachter, waaronder een softwarestuklijst (SBOM) en testverslagen. Een beschrijving zonder iets erachter is het zwakke punt.

De beveiligingsclaims van het voorbeeld, en het bewijs dat elk ervan onderbouwt, zien er zo uit.

Elke rij ondersteunt een of meer vereisten uit Bijlage I van de CRA, van integriteit en veilige verspreiding tot monitoring en beschikbaarheid. Zie de CRA-vereisten voor beveiligingsupdates voor het detail op artikelniveau.

Kunt u de rechterkolom vandaag niet leveren, dan is dat gat uw actiepunt. Een VEX-registratie en een SBOM-gestuurde afhankelijkheidscontrole dekken twee van deze rijen rechtstreeks. Uw due diligence bij leveranciers dekt de rij over buildvertrouwen voor componenten die u niet zelf hebt geschreven.

Dit artikel is uitsluitend bedoeld ter informatie en vormt geen juridisch advies. Raadpleeg voor specifiek nalevingsadvies een gekwalificeerd juridisch adviseur.