Når en sårbarhed i jeres software ikke kan rettes, kræver Cyber Resilience Act stadig, at I handler. Artikel 13, stk. 21, pålægger fabrikanten omgående at træffe korrigerende foranstaltninger, og Kommissionen skriver, at afhjælpning kan være afbødning, og at tilbagetrækning og tilbagekaldelse sandsynligvis vil være undtagelser.
Fra 11. december 2027 har reglen virkning. Ordlyden passer bedst på fysiske produkter, og derfor er det værd at se, hvordan den lander på software.
Stykke 21 læst for software
Artikel 13, stk. 21, siger i hovedtræk, at en fabrikant, der ved eller har grund til at tro, at produktet eller processerne ikke opfylder de væsentlige krav i bilag I, omgående skal træffe de nødvendige korrigerende foranstaltninger. Foranstaltningerne skal bringe produktet eller processerne i overensstemmelse, eller produktet skal trækkes tilbage eller kaldes tilbage.
For et softwarehus betyder det, at en kendt sårbarhed, der ikke kan rettes, er et tegn på mulig manglende overensstemmelse. Det er en forenklet læsning. Hvornår en enkelt sårbarhed betyder, at bilag I ikke er opfyldt, afhænger af risikovurderingen og af, om sårbarheden kan udnyttes.
Kommissionens svar: afbødning først
Kommissionens FAQ (punkt 4.3.4) siger, at afhjælpning kan have forskellige former, herunder afbødning. Tilbagetrækning eller tilbagekaldelse kan blive nødvendig i situationer, som FAQ’en kalder sandsynligvis exceptionelle, særligt for hardware. I de tilfælde vil myndighederne sandsynligvis være involveret efter artikel 54 til 58. Vi har ikke gennemgået de artikler her og skriver kun, at de kan blive sat i gang.
FAQ’en er ikke bindende, men den giver softwarehuset en rækkefølge at tænke i.
Tre veje, når rettelsen udebliver
Afbødning. En foranstaltning, der gør sårbarheden sværere eller umulig at udnytte, uden at den underliggende fejl er væk. Det kan være en ændret standardindstilling, en ekstra kontrol foran den sårbare kode eller en vejledning til brugeren om at begrænse adgangen. Kommissionens FAQ (punkt 4.3.1) nævner konfigurationsvejledning, der slår den berørte funktion fra, som en mulig afhjælpning.
Lukning af en funktion. FAQ’en (punkt 4.3.5) bruger netop det at slå en sårbar grænseflade fra som eksempel på en funktionsændring, der selv er en sikkerhedsopdatering. Brugeren mister noget, men produktet bliver sikkert at bruge. Tag stilling til, om lukningen ændrer produktets tilsigtede formål, for så kan der være tale om en væsentlig ændring.
Tilbagetrækning af en version. For software kan det betyde, at en version ikke længere udbydes, og at brugere henvises til en anden. Kommissionen omtaler tilbagetrækning som undtagelsen. Det er vores tolkning, at den for software primært er relevant, når hverken afbødning eller lukning af en funktion bringer risikoen ned.
Uanset vejen skal brugerne have noget at handle på. Efter bilag I, del II, nr. 8, skal en sikkerhedsopdatering følges af en vejledning om, hvad brugeren kan gøre. En afbødning, der forudsætter, at brugeren selv gør noget, virker kun, hvis brugeren får det at vide.
Et tænkt forløb
Et tænkt softwarehus opdager en sårbarhed i en ældre protokol, som produktet understøtter, fordi nogle kunder har gammelt udstyr. Fejlen ligger i selve protokollen og kan ikke rettes i koden.
Huset vurderer risikoen og beslutter tre ting. Protokollen slås fra som standard i en sikkerhedsopdatering. Kunder, der har brug for den, får en vejledning om at begrænse den til et lukket netværkssegment. Risikovurderingen ajourføres, og registret viser vurderingen, beslutningen og datoen. Hvis risikoen senere vurderes som for høj, er næste skridt at fjerne protokollen helt.
Eksemplet er tænkt. Det viser, hvilket spor en gennemgang leder efter.
Hvad gennemgangen ser efter
En gennemgang kan begynde med at finde sager i sårbarhedsregistret, hvor der ikke kom en rettelse, og læse dem for sig. Fire spørgsmål går igen:
- Står der, hvorfor sårbarheden ikke kunne rettes?
- Hvilken afbødning blev valgt, og hvornår kom den ud til brugerne?
- Blev det vurderet, om afbødningen var nok, eller om en funktion skulle lukkes?
- Blev risikovurderingen og den tekniske dokumentation ajourført?
En sag uden rettelse kan godt være i orden. Det afgørende er, om vurderingen og beslutningen står i registret.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at nogen kan træffe beslutningen om at afbøde, lukke eller trække tilbage, og at beslutningen skrives ned med begrundelse. Det kræver også, at brugerne får besked på en måde, de forstår.
Uden et spor står en åben sårbarhed tilbage som et spørgsmål om, hvorvidt produktet overholder bilag I. På begrundet anmodning kan myndigheden kræve dokumentationen efter artikel 13, stk. 22. Er der ingen, kan den selv vurdere, hvad der skal ske.
Nielco IT kan gennemgå jeres sager uden rettelse som en uafhængig part og pege på, hvor beslutningssporet mangler; vi træffer ikke beslutningen for jer.
Det skal I lade være med
- At lade en sag stå åben uden afbødning · artikel 13, stk. 21, siger omgående.
- At slå en funktion fra uden at vurdere formålet · det kan være en væsentlig ændring.
- At trække en version tilbage uden at fortælle brugerne hvorfor · de skal kunne handle på beskeden.
Det skal auditten kunne vise
- ☐ Sager uden rettelse med begrundelse, valgt afbødning og dato.
- ☐ Vurdering af, om afbødningen bragte risikoen ned.
- ☐ Besked eller vejledning til brugerne, hvor de selv skal handle.
- ☐ Ajourført risikovurdering og teknisk dokumentation.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 13, stk. 21 og 22, læst 13. november 2026.
- Europa-Kommissionen, FAQs on the Cyber Resilience Act, version 1.4, punkt 4.3.1, 4.3.4 og 4.3.5, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find de sager i registret, der blev lukket uden en rettelse, og læs, om hver har en begrundet afbødning.
Læs også: Håndtere eller rette · Kravet kan ikke opfyldes fuldt
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
