En sikkerhedsopdatering, I gør tilgængelig i supportperioden, skal efter Cyber Resilience Act forblive tilgængelig i mindst ti år efter udstedelsen eller i resten af supportperioden, alt efter hvad der er længst. Det er et af de få steder i forordningen, hvor der står et konkret tal.
Reglen findes i artikel 13, stk. 9, og har virkning fra 11. december 2027. Et softwarehus må derfor regne med, at opdateringsarkivet bliver en del af produktets dokumenterede overensstemmelse og skal overleve både serverskift og nye distributionsplatforme.
Hvad stykket siger
Artikel 13, stk. 9, siger, at hver sikkerhedsopdatering efter bilag I, del II, nr. 8, som er gjort tilgængelig for brugerne i supportperioden, forbliver tilgængelig efter udstedelsen i mindst ti år eller i resten af supportperioden, alt efter hvad der er længst.
Læg mærke til tre ting. Kravet gælder hver enkelt sikkerhedsopdatering, også de ældste. Perioden regnes fra udstedelsen af den enkelte opdatering. Og den længste af de to perioder vinder.
Kravet gælder sikkerhedsopdateringer efter bilag I, del II, nr. 8. Udgiver I en sikkerhedsrettelse sammen med nye funktioner, fordi den ikke kunne skilles ud, er det vores tolkning, at den samlede pakke skal kunne hentes i perioden, da det er dén, der indeholder rettelsen. Det er endnu en grund til at udgive sikkerhedsrettelser for sig, hvor det kan lade sig gøre, så arkivet ikke vokser med hele funktionsudgivelser.
Regnestykket med to tænkte eksempler
Eksemplerne er tænkte og viser kun, hvordan de to perioder sammenlignes.
- (marts 2028) · Supportperioden slutter: (marts 2033) · Ti år efter udstedelse: (marts 2038) · Skal kunne hentes til: (marts 2038)
- (juni 2032) · Supportperioden slutter: (december 2045) · Ti år efter udstedelse: (juni 2042) · Skal kunne hentes til: (december 2045)
I det første eksempel er supportperioden kort, og tiårsreglen bestemmer. I det andet er supportperioden lang, og den bestemmer. For produkter med lang supportperiode kan de første opdateringer altså skulle ligge tilgængelige i mange år.
Samme tidshorisont andre steder i forordningen
Tiårsreglen går igen i artikel 13. Efter stk. 13 skal dokumentationen og erklæringen gemmes et årti efter omsætningen, eller hele supportperioden, når den er den længste af de to. Stk. 18 stiller samme tidskrav til brugeroplysningerne, som skal ligge online.
De tre krav regnes ikke fra samme tidspunkt. Opdateringerne regnes fra hver udstedelse, dokumentationen fra omsætningen. Men de peger alle på, at en softwarefabrikant skal kunne finde og udlevere materiale om et produkt i lang tid, efter det er solgt.
Det, kravet betyder i praksis
Hvordan arkivet indrettes, siger forordningen intet om. Det følgende er praksis og forslag.
Et arkiv med alle sikkerhedsopdateringer. Hver opdatering ligger med versionsnummer, udstedelsesdato og den vejledende meddelelse, der fulgte med. Et register over, hvornår hver opdatering tidligst må fjernes, gør det lettere at holde styr på perioderne.
Hosting, der ikke er knyttet til én leverandørkonto. Ligger opdateringerne på en platform, I ikke selv kontrollerer, bør det være beskrevet, hvordan de flyttes, hvis platformen lukker eller ændrer vilkår. Opdateringerne skal også kunne hentes af den bruger, de er udstedt til.
En plan ved skift af platform. Skifter I distributionskanal, fx fra egen downloadside til en appbutik, skal de gamle opdateringer stadig kunne nås. Det er vores tolkning, at et skift ikke ændrer på perioden.
Integritet over tid. Opdateringer, der hentes ti år efter udstedelsen, skal stadig kunne kontrolleres af den klient, der skal installere dem. Hvis signeringsnøgler eller certifikater udløber undervejs, er det værd at tænke over, hvordan gamle pakker stadig kan verificeres. Det er en teknisk overvejelse, som forordningen ikke nævner.
Når opdateringen ligger i en appbutik
Distribueres en app gennem en markedsplads, styrer udvikleren ikke altid selv, hvilke ældre versioner der kan hentes. Det kan gøre stk. 9 svært at opfylde gennem butikken alene. Kilderne til denne artikel siger intet om, hvordan kravet skal opfyldes i den situation. Spørgsmålet bør derfor stå i risikovurderingen og i beskrivelsen af distributionen, så det er synligt, hvordan I har valgt at løse det.
Sådan kontrollerer gennemgangen arkivet
Gennemgangen vælger typisk et antal sikkerhedsopdateringer af forskellig alder fra sårbarhedsregistret og forsøger at hente hver, som en bruger ville gøre. Metoden er praksis. Fire spørgsmål går igen:
- Kan opdateringen findes og hentes?
- Er det den samme pakke, der oprindeligt blev udstedt?
- Kan den stadig verificeres og installeres på den version, den er beregnet til?
- Er der en plan for, hvor opdateringen ligger, hvis den nuværende hosting forsvinder?
Hvad det kræver, og hvad det koster at lade være
Det kræver et arkiv med alle sikkerhedsopdateringer, et register over perioderne og en plan for, hvordan arkivet flyttes, når platformen skifter. Det meste af arbejdet ligger i at holde orden på perioderne.
Uden arkivet kan brugere med ældre installationer stå uden mulighed for at få en rettelse, de har krav på. Over for myndigheden er en opdatering, der ikke længere kan findes, et konkret brud på et klart stykke.
Det skal I lade være med
- At slette gamle opdateringer, når en ny version kommer · hver opdatering har sin egen periode.
- At lade arkivet afhænge af én platformskonto · lukker kontoen, forsvinder opdateringerne.
- At regne perioden fra produktets lancering · den regnes fra hver opdaterings udstedelse.
Det skal auditten kunne vise
- ☐ Et arkiv med alle sikkerhedsopdateringer udstedt i supportperioden.
- ☐ Et register med den tidligste dato for fjernelse af hver opdatering.
- ☐ Stikprøver, der viser, at ældre opdateringer kan hentes og verificeres.
- ☐ En plan for arkivet ved skift af hosting eller distributionskanal.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 13, stk. 9, 13 og 18, og bilag I, del II, nr. 8, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Prøv at hente den ældste sikkerhedsopdatering, I har udsendt til et produkt, der stadig er i brug, og notér, hvor den ligger.
Læs også: Gamle versioner · Hvem købte I af, og hvem solgte I til?
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
