Fabrikanten skal sikre, at produktets sårbarheder, også dem i komponenterne, håndteres effektivt fra omsætningen og i hele supportperioden. Det står i artikel 13, stk. 8, og gælder fra 11. december 2027. Har I flere versioner i support, rækker pligten ud over den nyeste, og beviset skal kunne vise det.
Lovteksten siger ikke “én liste og én overvågning pr. version”. Det er vores tolkning af, hvordan pligten kan dokumenteres. Artiklen handler om beviset for den løbende pligt. Valget af værktøjer er jeres eget.
Det, loven siger
Tre bestemmelser hænger sammen. Artikel 13, stk. 8, gør fabrikanten ansvarlig for, at sårbarheder i produktet og dets komponenter bliver håndteret effektivt efter bilag I, del II, fra omsætningen og supportperioden ud. Artikel 13, stk. 7, pålægger en systematisk registrering af de sårbarheder, fabrikanten får kendskab til, og af relevante oplysninger fra andre, og kræver, at risikovurderingen holdes ajour. Bilag I, del II, nr. 3, kræver løbende og effektiv afprøvning og gennemgang af sikkerheden.
Ingen af dem nævner versioner direkte. Men sårbarhedshåndteringen gælder produktet, og hver version, der er bragt i omsætning og stadig er i support, er en del af det.
Hvilke versioner er i spil?
Artikel 13, stk. 10, giver en mulighed. Når der efter hinanden er kommet væsentligt ændrede versioner på markedet, må fabrikanten nøjes med at afhjælpe efter del II, nr. 2, i den nyeste. Til gengæld skal brugere af ældre versioner kunne skifte til den nyeste uden betaling og uden ekstra omkostninger til at tilpasse deres hardware og software.
Kommissionen understreger i sin vejledning, at de øvrige pligter i del II gælder fortsat. Det vil sige, at selv hvis I kun retter i den nyeste version, skal I stadig identificere og dokumentere sårbarheder og komponenter i de tidligere. Overvågningen stopper altså ikke, fordi afhjælpningen gør.
Bruger I ikke stk. 10, gælder hele del II for hver version i support.
Regelmæssig, ikke mekanisk
Vejledningen forklarer, hvad “regelmæssige” afprøvninger betyder. Det kræver ikke, at en uændret testkampagne gentages mekanisk med faste mellemrum. Det kræver en løbende vurdering af, om nye trusler eller nyopdagede sårbarheder gør nye test nødvendige. Hyppighed og dybde står i forhold til risikoprofilen.
Overført til komponenter betyder det, at overvågningen skal reagere, når der kommer ny viden om en komponent i en understøttet version. En månedlig scanning kan være nok for ét produkt og for sjældent for et andet. Det skal begrundes.
Sporet fra advarsel til vurdering
En gennemgang leder efter et spor, der kan følges for hver understøttet version. Mange bygger sporet op i tre led. Opbygningen er praksis:
- En liste. Komponentlisten for den konkrete version. Den tyske retningslinje BSI TR-03183-2 opstiller en regel om én liste for hver softwareversion. Den er ikke bindende, men passer godt til formålet.
- En overvågning. En løbende sammenligning af listen med offentlige sårbarhedsdatabaser og andre kilder.
- Et spor. For hver advarsel, der rammer en komponent i versionen, en registrering af, hvornår den kom, hvem der vurderede den, og hvad konklusionen blev.
En almindelig prøve i en gennemgang er at vælge en offentliggjort sårbarhed i en udbredt komponent og spørge, hvornår den blev opdaget i hver af de versioner, der er i support, og hvad der skete bagefter.
Hvor matchningen svigter
ENISA’s undersøgelse fra 2026 viser, hvor det typisk går galt. Næsten to tredjedele af de adspurgte svarede, at matchning mod sårbarheder, herunder justering af identifikatorer som CPE og purl og håndtering af falske positiver, påvirker dem temmelig eller ekstremt meget. Om leverandørers lister svarede 27 procent, at de mangler fuldstændighed, 17 procent præcise komponentidentifikatorer og 12 procent gode sårbarhedsreferencer. Bag tallene står 334 besvarelser fra slutningen af 2025, ikke en opgørelse over markedet.
For en gennemgang peger det på to kontrolpunkter. Har komponenterne på listen identifikatorer, der kan matches? Og hvordan håndteres falske positiver, så de ikke drukner de rigtige fund?
Gamle versioner hos kunderne
Mange softwarehuse har kunder, der kører versioner, som er flere år gamle, men stadig i support. Byggemiljøet for de versioner kan være ændret, og listen er måske aldrig lavet. Her kan overvågningen ikke komme i gang, før listen er genskabt. Hvad der skal ske med versioner fra før 11. december 2027, er et særskilt spørgsmål. For dem gælder kravene i del II kun, hvis de ændres væsentligt efter datoen. Artikel 14 om indberetning gælder dog for alle.
Hvad det kræver, og hvad det koster at lade være
Det kræver en oversigt over de versioner, der er i support, en komponentliste for hver, en overvågning, der kører mod dem alle, og en registrering af vurderinger.
Uden det ved I ikke, om en ny sårbarhed rammer en version hos en kunde, før kunden spørger. Og I kan ikke vise myndigheden, at pligten i artikel 13, stk. 8, er opfyldt for andet end den nyeste version.
Det skal I lade være med
- At overvåge kun den nyeste version, når ældre er i support · pligten gælder hele supportperioden.
- At læse stk. 10 som et stop for overvågning · kun afhjælpningen kan begrænses.
- At lade advarsler ligge uden registreret vurdering · registreringen efter artikel 13, stk. 7, skal være systematisk.
Det skal auditten kunne vise
- ☐ En oversigt over versioner i support med supportperiode.
- ☐ En komponentliste for hver af dem.
- ☐ Bevis for løbende overvågning af hver version.
- ☐ Spor fra advarsel til vurdering for en udvalgt sårbarhed.
- ☐ Ved brug af artikel 13, stk. 10: dokumentation af betingelserne.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 13, stk. 7, 8 og 10, artikel 69, og bilag I, del II, nr. 2-3, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, punkt 131 og 238-240, læst 13. november 2026.
- ENISA, SBOM Adoption State of Play 2026, afsnit 2.4.1 og 2.4.7, læst 13. november 2026.
- BSI, TR-03183-2, version 2.1.0, afsnit 3.1, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Skriv de versioner op, der er i support i dag, og se, om hver af dem har en komponentliste, der bliver overvåget.
Læs også: En komponentliste for hver version · “Ikke berørt”: den dokumenterede vurdering
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
