Cyber Resilience Act kræver, at nye sikkerhedsopdateringer leveres adskilt fra funktionsopdateringer, hvor det er teknisk muligt. Brugeren skal kunne få den seneste rettelse uden samtidig at skulle tage imod nye funktioner.
Bilag I, del II, nr. 2, er hjemlen, og det første tidspunkt, hvor kravet skal være opfyldt, er 11. december 2027. Udgiver huset alt i ét samlet release-tog, kan det betyde en ændring af måden, versioner bygges og nummereres på.
Ordlyden og formålet
Bilag I, del II, nr. 2, siger, at fabrikanten i forbindelse med risiciene straks skal håndtere og afhjælpe sårbarheder, herunder ved sikkerhedsopdateringer. Samme punkt fortsætter med, at nye sikkerhedsopdateringer, hvor det er teknisk muligt, skal leveres adskilt fra funktionalitetsopdateringer.
Betragtning 57, som Kommissionens FAQ citerer, giver begrundelsen. Brugerne skal ikke være tvunget til at installere nye funktioner alene for at få den seneste sikkerhedsopdatering. Nye funktioner kan ændre arbejdsgange, kræve oplæring eller give nye fejl, og det må ikke stå i vejen for en rettelse.
Ordene “hvor det er teknisk muligt” er dét, der gør kravet til et auditpunkt. De åbner for undtagelser, men undtagelsen skal kunne forklares teknisk.
Kommissionens tre tilfælde
Kommissionens FAQ (punkt 4.3.5) gennemgår tre situationer. Eksemplerne er Kommissionens egne og tænkte.
- Ren sikkerhedsrettelse · Kommissionens eksempel: (rettelse af certifikatvalidering) · Adskillelse: Leveres særskilt, uden at blive bundtet med funktionsændringer
- Funktionsændring er nødvendig for rettelsen · Kommissionens eksempel: (en forældet filparser i en PDF-læser udskiftes, og den nye afviser filer, der før virkede) · Adskillelse: Ikke teknisk mulig og kræves ikke
- Funktionsændringen er selv rettelsen · Kommissionens eksempel: (en sårbar grænseflade slås fra) · Adskillelse: Ændringen er sikkerhedsopdateringen
Det første tilfælde er hovedreglen. De to andre beskriver, hvornår en ændring i funktionaliteten følger med, fordi rettelsen ikke kan laves uden.
FAQ’en er ikke bindende. Den er alligevel den mest konkrete læsning af punktet, der findes i november 2026.
Hvor softwarehuse typisk har udfordringen
Et tænkt, men genkendeligt mønster er at udgive fra én hovedgren, hvor sikkerhedsrettelser og nye funktioner flettes sammen og udgives samlet. Det er ikke forbudt i sig selv. Spørgsmålet er, om brugeren kan få rettelsen uden de nye funktioner.
Der findes flere tekniske løsninger. En vedligeholdelsesgren pr. understøttet version, hvor kun rettelser lægges ind. Funktionsflag, der holder nye funktioner slået fra, indtil brugeren vælger dem. Eller en opdeling af produktet i moduler, så sikkerhedsrettelser kan udgives for sig. Hvilken løsning der passer, afhænger af produktet. Forordningen peger ikke på nogen af dem.
For produkter, hvor kun den nyeste version understøttes efter artikel 13, stk. 10, hænger dette sammen med versionspolitikken. Betragtning 40, citeret i FAQ’en, siger, at mindre opdateringer, der ikke er væsentlige ændringer, kan leveres til seneste version eller underversion alene.
Når adskillelse ikke er mulig
Når en rettelse ikke kan adskilles, er det oplagt at fortælle brugerne det. Frigivelsesnoterne kan sige, at udgivelsen indeholder en sikkerhedsrettelse, at den ikke kunne leveres for sig, og hvilken funktionsændring der følger med. Så kan brugerne planlægge opdateringen, og den, der senere læser historikken, kan se begrundelsen uden at spørge udviklerne. Kommissionens eksempel med filparseren viser, hvorfor det betyder noget. Brugere, der pludselig ikke kan åbne gamle filer, bør vide, at det skyldes en sikkerhedsrettelse, så de ikke ruller opdateringen tilbage.
Kravet hænger også sammen med de automatiske sikkerhedsopdateringer, som bilagets del I, nr. 2, behandler under litra c. En automatisk opdatering, der også bringer nye funktioner, kan ændre brugerens arbejdsgang uden varsel. Det taler for at holde de to typer adskilt, også hos kunder, der har valgt automatisk installation.
Sådan læser gennemgangen frigivelseshistorikken
Gennemgangen kan tage de releases, der indeholdt sikkerhedsrettelser i en periode, og klassificere hver efter de tre tilfælde. Metoden er praksis. Forordningen foreskriver ingen bestemt kontrol.
For hver release ser gennemgangen efter:
- Kom sikkerhedsrettelsen ud som en selvstændig opdatering, eller kun sammen med nye funktioner?
- Hvis den kom sammen med nye funktioner, er der en teknisk begrundelse for, at den ikke kunne adskilles?
- Passer begrundelsen til et af de to tilfælde, hvor Kommissionen siger, at adskillelse ikke kræves?
- Står begrundelsen i registret eller i frigivelsesnoterne, så den kan findes bagefter?
Et mønster, hvor alle sikkerhedsrettelser kommer med store funktionsudgivelser, uden at nogen begrundelse er skrevet ned, er et tydeligt fund. Enkelte tilfælde med begrundelse falder inden for undtagelsen.
Hvad det kræver, og hvad det koster at lade være
Det kræver en udgivelsesproces, der kan levere en rettelse for sig, og en vane med at skrive begrundelsen ned, når det ikke kan lade sig gøre. For nogle huse betyder det en ny grenstrategi eller funktionsflag. For andre er det mest et spørgsmål om dokumentation.
Begrundelserne behøver ikke være lange. To linjer om, hvorfor rettelsen krævede funktionsændringen, er nok til, at sporet kan følges.
Uden adskillelse står brugere, der ikke vil eller kan tage nye funktioner, uden rettelsen. Det går imod formålet i betragtning 57 og kan efterlade sårbare installationer i drift længere end nødvendigt.
Hvad der påvirker prisen, og hvordan I får et tilbud, står under pris og tilbud.
Det skal I lade være med
- At bundte hver rettelse med næste store udgivelse · hovedreglen er en særskilt sikkerhedsopdatering.
- At kalde alt “teknisk umuligt” · undtagelsen skal kunne forklares for den enkelte rettelse.
- At lade begrundelsen stå i en udviklers hukommelse · den skal kunne findes af en gennemgang.
Det skal auditten kunne vise
- ☐ En liste over releases med sikkerhedsrettelser i perioden.
- ☐ Rettelser leveret særskilt, hvor det var teknisk muligt.
- ☐ Skriftlig teknisk begrundelse, hvor de ikke blev adskilt.
- ☐ En udgivelsesproces, der kan levere en rettelse uden nye funktioner.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, bilag I, del II, nr. 2, og artikel 13, stk. 10, læst 13. november 2026.
- Europa-Kommissionen, FAQs on the Cyber Resilience Act, version 1.4, punkt 4.3.2 og 4.3.5, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Gå jeres seneste ti releases igennem og markér, hvilke sikkerhedsrettelser der kun kunne fås sammen med nye funktioner.
Læs også: Automatiske sikkerhedsopdateringer som standard · Væsentlig ændring
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
