Når en komponent i jeres produkt mister sin support, har I stadig pligten til at håndtere sårbarheder i hele produktets supportperiode, også i den komponent. Kommissionen skriver i sin FAQ, at fabrikanten da må afhjælpe på anden måde, for eksempel ved at skifte komponenten eller selv udvikle en rettelse.
Pligten gælder fra 11. december 2027. En gennemgang ser derfor på, om komponenternes supportperioder er sammenholdt med produktets, og om der findes en plan for de komponenter, der udløber først.
Hvad loven siger
Efter artikel 13, stk. 8, bærer fabrikanten ansvaret for en effektiv håndtering af sårbarheder efter bilag I, del II, fra produktet bringes i omsætning og supportperioden ud, og det gælder også de indbyggede komponenter.
Samme stykke giver fabrikanten lov til at tage hensyn til komponenternes supportperioder, når produktets egen supportperiode fastsættes. Det gælder integrerede komponenter, der leverer centrale funktioner og stammer fra tredjeparter. Med andre ord kan en kort supportperiode i en central komponent være en del af begrundelsen for produktets supportperiode. Den kan ikke bruges til at slippe for pligten, når supportperioden først er fastsat.
Kommissionens svar
FAQ’en siger, at sårbarhedshåndteringen gælder hele produktet i hele supportperioden, inklusive komponenterne. Har en komponent mistet sin support, og kan en sårbarhed ikke afbødes tilstrækkeligt, skal fabrikanten afhjælpe den på anden vis, for eksempel ved at skifte komponenten eller selv udvikle en rettelse.
Det er den situation, der gør planlægningen nødvendig. Opdager I først, at en komponent er uden support, når der kommer en alvorlig sårbarhed i den, er valgmulighederne få og tidspresset stort.
Når projektet står uden vedligeholder
Et open source-projekt kan holde op med at blive vedligeholdt, uden at nogen melder en slutdato. Det er en anden situation end en annonceret afslutning, men følgen er den samme. Ingen retter sårbarheder.
Kommissionens vejledning siger, at pligten til at indberette sårbarheder opstrøms efter artikel 13, stk. 6, ikke gælder, når komponenten ikke har en vedligeholder. Kommissionen opfordrer i stedet fabrikanten til at informere andre brugere af komponenten, for eksempel via mailinglister, sager i projektet eller offentlige sårbarhedsregistreringer. Pligten til at håndtere sårbarheden i eget produkt gælder fortsat.
Supportperioden ved valg af komponent
Kontrol af komponentens supportperiode er et af de eksempler på handlinger ved integration, som FAQ’en nævner. Det er altså noget, der hører med, når komponenten vælges. Spørgsmålet er enkelt: Rækker komponentens support lige så langt som den supportperiode, I vil love for produktet? Hvis ikke, hvad er planen?
Sammenholdningen
Det er almindeligt i en gennemgang at lægge to datoer ved siden af hinanden for hver central komponent: komponentens forventede supportslut og produktets supportslut. Kilden til komponentens dato kan være en annonceret plan, en udgivelsespolitik eller, for open source uden plan, en vurdering af aktiviteten i projektet. Det sidste er et skøn og skal markeres som sådan.
- (Webramme) · Komponentens supportslut: (Annonceret, før produktets) · Produktets supportslut: (Erklæret supportperiode) · Plan: (Skift til ny hovedversion i en bestemt udgivelse)
- (Lille hjælpebibliotek) · Komponentens supportslut: (Ingen plan, lav aktivitet) · Produktets supportslut: (Erklæret supportperiode) · Plan: (Overvåg, vurder at fjerne biblioteket)
- (Runtime) · Komponentens supportslut: (Annonceret, efter produktets) · Produktets supportslut: (Erklæret supportperiode) · Plan: (Ingen handling)
Eksemplerne er tænkte. Ingen kilde opstiller en skabelon for planen. Kolonnerne er vores forslag.
Hvad planen kan indeholde
Planen for en komponent, der udløber før produktet, kan for eksempel indeholde:
- hvornår skiftet til en anden version eller komponent skal ske,
- hvad der skal til for at skifte, og om skiftet kan blive en væsentlig ændring,
- hvordan sårbarheder håndteres i perioden mellem supportslut og skift,
- hvem der kan lave en rettelse selv, hvis det bliver nødvendigt.
Planens indhold er praksis. Hvordan udgåede systemer håndteres hos den, der driver dem, hører til styringen af udgåede systemer over tid og den tekniske kontrol af udgåede systemer i drift. Her er synsvinklen fabrikantens.
Når skiftet bliver en væsentlig ændring
Et skift af en central komponent kan være stort. Kommissionens vejledning bruger i et andet eksempel et skift til en ekstern tjeneste til nøglehåndtering hos en tredjepart som en væsentlig ændring, da både afhængighederne og datastrømmene skifter. Om et komponentskift er en væsentlig ændring, afhænger af, hvad der ændres, og skal vurderes i hvert tilfælde. Pointen for planen er, at et skift, der planlægges i god tid, kan vurderes i ro. Et skift under tidspres efter en alvorlig sårbarhed giver sjældent den mulighed.
Det samme gælder valget mellem at skifte og at rette selv. At vedligeholde en kopi af en komponent, som ingen andre retter, er en opgave, der varer resten af supportperioden. Den beslutning bør tages med øjnene åbne og skrives ned, så den kan ses igen, når supportperioden for produktet nærmer sig sin slutning.
Hvad det kræver, og hvad det koster at lade være
Det kræver en oversigt over centrale komponenter med deres forventede supportslut, en sammenholdning med produktets supportperiode og en plan for dem, der udløber først.
Uden oversigten opdager I en udløbet komponent, når der er en sårbarhed i den. Så står valget mellem at skifte under pres eller selv rette kode, I ikke kender, og begge dele tager tid, kunderne ikke har.
Det skal I lade være med
- At love en supportperiode, der rækker længere end jeres centrale komponenter, uden en plan · pligten følger produktet.
- At regne et stille open source-projekt for vedligeholdt · aktiviteten skal vurderes.
- At bruge komponentens supportslut som grund til at stoppe sårbarhedshåndteringen · artikel 13, stk. 8, gælder hele supportperioden.
Det skal auditten kunne vise
- ☐ En oversigt over centrale komponenter med forventet supportslut og kilde.
- ☐ En sammenholdning med produktets supportperiode.
- ☐ En plan for komponenter, der udløber før produktet.
- ☐ Kontrol af supportperiode ved valg af nye komponenter.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 13, stk. 6 og 8, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, punkt 225, læst 13. november 2026.
- Kommissionens tjenestegrene, FAQs on the Cyber Resilience Act, version 1.4, afsnit 4.3.7 og 4.4.2, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Skriv jeres fem mest centrale komponenter op med deres forventede supportslut, og læg dem ved siden af produktets.
- Softwarekomponentliste, afhængigheder og tredjepartskomponenter
- Supportperioden: begrundelsen i den tekniske dokumentation
Læs også: Valg af open source- og tredjepartskomponenter · Sårbarheden kan ikke rettes
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
