Når en sikkerhedsopdatering er gjort tilgængelig, skal I efter Cyber Resilience Act dele og offentliggøre oplysninger om de sårbarheder, den afhjælper. I behørigt begrundede tilfælde må I vente, indtil brugerne har haft mulighed for at installere rettelsen.
Pligten står i bilag I, del II, nr. 4. Den har virkning fra 11. december 2027. Den rammer frigivelsesnoter og sikkerhedsmeddelelser, som mange softwarehuse skriver i dag uden at tænke over, hvad de skal indeholde.
Fire ting, oplysningerne skal rumme
Bilag I, del II, nr. 4, nævner fire elementer. Oplysningerne om de afhjulpne sårbarheder skal omfatte:
- en beskrivelse af sårbarhederne
- oplysninger, der gør det muligt for brugerne at identificere det berørte produkt
- sårbarhedernes indvirkning og alvor
- tydelige oplysninger, der gør det lettere for brugerne at afhjælpe sårbarhederne
Gengivelsen her er forkortet. Hertil kommer bilag I, del II, nr. 8, som kræver, at sikkerhedsopdateringer ledsages af vejledende meddelelser om de foranstaltninger, brugerne kan træffe.
En linje i frigivelsesnoterne med “diverse sikkerhedsforbedringer” opfylder næppe de fire elementer. Det er vores vurdering af ordlyden.
Elementet om identifikation af produktet kræver mere, end det lyder. Brugeren skal kunne se, om netop den installerede version er berørt. Et versionsinterval og navnet på produktet eller modulet gør det muligt. En meddelelse, der kun nævner den rettede version, lader brugeren gætte på, hvilke ældre versioner der var sårbare.
Retten til at vente
Samme punkt giver en undtagelse. I behørigt begrundede tilfælde, hvor fabrikanten vurderer, at sikkerhedsrisiciene ved at offentliggøre er større end fordelene, kan offentliggørelsen udsættes, indtil brugerne har fået mulighed for at anvende rettelsen.
Tre ting er værd at bemærke. Undtagelsen skal begrundes. Den flytter offentliggørelsen til et senere tidspunkt. Og den knytter sig til brugernes mulighed for at installere rettelsen, så en udsættelse uden slutpunkt passer dårligt med teksten.
Et tænkt eksempel er et softwarehus, hvis kunder typisk installerer opdateringer i et fast vindue en gang om måneden. Huset kan begrunde at vente med detaljerne, til vinduet er passeret. Begrundelsen og den dato, oplysningerne blev offentliggjort, skal kunne findes bagefter.
Hvor oplysningerne skal kunne findes
Forordningen bruger ordene dele og offentliggøre. Det er vores læsning, at oplysningerne derfor skal kunne findes af brugere, der ikke er logget ind. En kundeportal bag login kan være et supplement. Brugeroplysningerne efter bilag II, nr. 2, skal angive det centrale kontaktpunkt, hvor oplysninger om sårbarheder kan modtages, og det er naturligt at henvise til stedet for sikkerhedsmeddelelser derfra.
Formatet er jeres valg
Forordningen kræver ikke et bestemt format. CSAF (Common Security Advisory Framework) er en OASIS-standard for maskinlæsbare sikkerhedsmeddelelser. CVE-numre er en måde at identificere den enkelte sårbarhed på. Ingen af delene er et krav. En overskuelig side med de fire elementer kan opfylde kravet lige så godt, hvis den er let at finde.
Det, gennemgangen ser efter, er indholdet, og at det kan findes af brugeren.
Sådan holdes meddelelserne op mod kravet
Gennemgangen kan tage udgangspunkt i alle sikkerhedsopdateringer fra det seneste år og sammenholde dem med sårbarhedsregistret. Perioden er et valg i gennemgangen. Forordningen nævner ingen.
For hver rettet sårbarhed stilles spørgsmålene:
- Findes der en offentlig oplysning, og hvornår blev den udgivet?
- Indeholder den de fire elementer fra bilag I, del II, nr. 4?
- Er der vejledning til brugerne efter nr. 8?
- Hvis offentliggørelsen blev udsat, står begrundelsen i registret, og blev den udsatte meddelelse senere udgivet?
En rettelse i registret uden nogen offentlig oplysning er et tydeligt hul. Det samme er en meddelelse, der omtaler en anden version end den, der blev rettet.
Sammenhæng med jeres politik og med indberetningen
Politikken for koordineret offentliggørelse (bilag I, del II, nr. 5) beskriver typisk, hvordan og hvornår I offentliggør. Det er naturligt, at de to hænger sammen, så det, politikken lover melderen, også er det, der sker i meddelelsen.
Pligten til at indberette aktivt udnyttede sårbarheder, som artikel 14 fastsætter, er selvstændig med egne frister og gælder allerede fra 11. september 2026. Den hører til et andet emne og behandles ikke her.
Hvad det kræver, og hvad det koster at lade være
Det kræver en skabelon for sikkerhedsmeddelelser med de fire elementer, en fast plads, hvor de udgives, og en kobling til registret, så hver rettelse får sin meddelelse. Udsættelser kræver en skriftlig begrundelse og en dato for, hvornår meddelelsen kommer.
Arbejdet bliver mindre, når meddelelsen skrives samtidig med rettelsen, mens udvikleren stadig kender detaljerne.
Uden det ved brugerne ikke, hvorfor de skal opdatere, eller hvad de kan gøre i mellemtiden. Over for myndigheden kan I ikke vise, at bilag I, del II, nr. 4, er opfyldt for de rettelser, I har frigivet.
Det skal I lade være med
- At skrive “sikkerhedsforbedringer” uden at sige hvilke · de fire elementer mangler.
- At udsætte offentliggørelsen uden en begrundelse · undtagelsen kræver, at den er behørigt begrundet.
- At glemme den udsatte meddelelse · udsættelsen varer, til brugerne har kunnet opdatere.
Det skal auditten kunne vise
- ☐ En offentlig oplysning for hver rettet sårbarhed i perioden.
- ☐ De fire elementer fra bilag I, del II, nr. 4, i hver oplysning.
- ☐ Vejledende meddelelser til brugerne efter nr. 8.
- ☐ Begrundelse og senere udgivelse for hver udsat offentliggørelse.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, bilag I, del II, nr. 4, 5 og 8, artikel 14 og 71, læst 13. november 2026.
- OASIS, Common Security Advisory Framework Version 2.0, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Læg jeres seneste tre sikkerhedsmeddelelser ved siden af de fire elementer i bilag I, del II, nr. 4, og se, hvad der mangler.
Læs også: Underretning af brugerne efter artikel 14, stk. 8 · Sikkerhedsopdateringer adskilt fra funktionsopdateringer
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
