Cyber Resilience Act kræver, at I har mekanismer til sikker distribution af opdateringer, og at den tekniske dokumentation beskriver de løsninger, I har valgt. Forordningen siger ikke, hvordan mekanismen skal være bygget. Signering, beskyttede kanaler og kontrol i klienten er almindelige tekniske løsninger, men de er ikke nævnt i lovteksten.
Hjemlen er bilag I, del II, nr. 7, sammen med bilag VII, nr. 2, litra b, og kravene har virkning fra 11. december 2027. Opdateringsmekanismen når ud til hver eneste installation, og derfor vejer dens sikkerhed tungt.
Det, lovteksten kræver
Bilag I, del II, nr. 7, pålægger fabrikanten at sørge for mekanismer til sikker distribution af opdateringer. Formålet er, at sårbarheder rettes eller afbødes rettidigt, og for sikkerhedsopdateringer automatisk, hvor det er relevant.
Efter bilag VII, nr. 2, litra b, skal den tekniske dokumentation beskrive de tekniske løsninger, I har valgt for at distribuere opdateringer sikkert.
Kravet hænger sammen med to af de væsentlige krav til produktets egenskaber, litra c og f i del I, nr. 2. Litra c handler om, at sårbarheder skal kunne afhjælpes gennem sikkerhedsopdateringer, herunder automatiske sikkerhedsopdateringer som standard, hvor det er relevant, med mulighed for at fravælge eller udsætte dem. Litra f handler om at beskytte integriteten af programmer og konfiguration mod ændringer, der ikke er godkendt. At en klient bør afvise en ændret opdateringspakke, er vores tolkning af litra f sammen med del II, nr. 7.
Hvad lovteksten ikke siger
Der står intet i forordningen om digitale signaturer, bestemte protokoller eller kontrol i klienten. De læste afsnit af Kommissionens vejledning og FAQ nævner det heller ikke. Pr. november 2026 har vi ikke set referencer til harmoniserede standarder til forordningen i EU-Tidende, så ingen standard giver formodning om overensstemmelse for opdateringsmekanismen endnu.
Det er også værd at beskrive, hvad der sker, når en opdatering fejler undervejs. Bliver installationen stående i en sikker tilstand, eller kan en afbrudt opdatering efterlade programmet halvt opdateret? Kommissionens vejledning (punkt 169) nævner som eksempel, at et udfald i et system uden for produktet ikke må bringe produktet i en usikker tilstand. Eksemplet handler om backend-systemer og er ikke et krav, men tanken passer også på opdateringsserveren.
Det betyder, at fabrikanten selv vælger løsningen og selv skal kunne forklare, hvorfor den er sikker. Beskrivelsen i bilag VII er stedet, hvor det forklares.
Almindelige tekniske løsninger
Følgende løsninger er almindelige i softwareudvikling. De er nævnt som eksempler på, hvad en beskrivelse efter bilag VII kan indeholde, og ingen af dem er et lovkrav.
- Byg og pakning · Almindelig løsning: (pakken bygges i et kontrolleret miljø) · Hvad beskrivelsen kan forklare: (hvem kan starte et byg og frigive en pakke)
- Signering · Almindelig løsning: (pakken signeres digitalt) · Hvad beskrivelsen kan forklare: (hvor signeringsnøglen opbevares, og hvem kan bruge den)
- Kanal · Almindelig løsning: (pakken hentes over en krypteret forbindelse) · Hvad beskrivelsen kan forklare: (hvordan klienten kender den rigtige server)
- Kontrol i klienten · Almindelig løsning: (signaturen kontrolleres før installation) · Hvad beskrivelsen kan forklare: (hvad klienten gør med en pakke, der ikke kan verificeres)
- Version · Almindelig løsning: (klienten afviser ældre versioner end den installerede) · Hvad beskrivelsen kan forklare: (hvordan nedgradering til en sårbar version undgås)
Hvor meget af kæden der skal beskrives, afhænger af risikovurderingen. For et lille internt værktøj kan beskrivelsen være kort. For et produkt med automatiske opdateringer til mange installationer bør den være grundig, fordi en kompromitteret mekanisme rammer alle.
Automatiske opdateringer og undtagelserne
Kommissionens FAQ (punkt 4.3.3) gengiver betragtning 56. Efter den rammer kravet om automatiske opdateringer ikke komponenter, der hovedsagelig skal bygges ind i andre produkter. Det rammer heller ikke produkter, hvor automatiske opdateringer ikke er noget, brugerne med rimelighed kan vente, som udstyr til professionelle IKT-netværk og kritiske eller industrielle miljøer.
Undtagelsen gælder det automatiske. Distributionen skal stadig være sikker, og opdateringerne skal stilles til rådighed uden ophold. Begrundelsen for at undlade automatiske opdateringer hører hjemme i risikovurderingen.
Sådan prøver gennemgangen mekanismen
Forordningen beskriver ingen metode til gennemgangen. Den, der bruges her, har typisk to dele.
Beskrivelsen. Først læses beskrivelsen efter bilag VII, nr. 2, litra b. Dækker den hele kæden fra byg til installation? Står der, hvem der har adgang til de led, hvor en pakke kan ændres? Passer den til risikovurderingen?
Klienten. Derefter prøves beskrivelsen mod en installeret kopi af softwaren. Et almindeligt trin er at give klienten en pakke, der er ændret efter signering, og se, at den bliver afvist, og at brugeren eller administratoren får besked. Et andet er at forsøge at installere en ældre version. Prøverne laves på softwaren i et testmiljø.
Hvem der har rettigheder i udrulningskæden i den daglige drift, er et driftsspørgsmål, der hører til de tekniske kontrolpunkter i driften.
Hvad det kræver, og hvad det koster at lade være
Det kræver en skriftlig beskrivelse af opdateringskæden, som en person uden for udviklingsholdet kan forstå. Det kræver også, at klienten faktisk opfører sig, som beskrivelsen siger, og at nøgler og byggemiljø er beskyttet.
En svag opdateringsmekanisme er en vej ind til alle jeres kunder på én gang. Mangler beskrivelsen, kan I heller ikke vise myndigheden, at bilag I, del II, nr. 7, er opfyldt.
Nielco IT kan læse beskrivelsen og prøve klientens afvisning i en installeret kopi af softwaren som uvildig part. Firmware på fysiske enheder og hardware ligger uden for opgaven.
Det skal I lade være med
- At kalde signering et lovkrav over for kunderne · forordningen kræver en sikker mekanisme og en beskrivelse.
- At lade signeringsnøglen ligge, hvor mange kan bruge den · så hjælper signaturen ikke.
- At beskrive kæden, uden at klienten er prøvet · beskrivelsen skal passe til det, softwaren gør.
Det skal auditten kunne vise
- ☐ En beskrivelse efter bilag VII, nr. 2, litra b, af hele kæden fra byg til installation.
- ☐ En prøve, der viser, at klienten afviser en ændret eller ældre pakke.
- ☐ Kendte personer med adgang til signering og frigivelse.
- ☐ Begrundelse i risikovurderingen, hvis automatiske opdateringer er fravalgt.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, bilag I, del I, nr. 2, litra c og f, bilag I, del II, nr. 7, og bilag VII, nr. 2, litra b, læst 13. november 2026.
- Europa-Kommissionen, FAQs on the Cyber Resilience Act, version 1.4, punkt 4.3.3, læst 13. november 2026.
- Europa-Kommissionen, Cyber Resilience Act: Standardisation, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Tegn jeres opdateringskæde fra byg til installation og skriv ud for hvert led, hvem der kan ændre en pakke dér.
Læs også: Automatiske sikkerhedsopdateringer som standard · Den tekniske dokumentation efter bilag VII
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
