Produktansvarsdirektivet pålægger ikke fabrikanten at opdatere software. Til gengæld kan fabrikanten ikke fritages for ansvar, når en defekt skyldes en manglende sikkerhedsopdatering, som det var inden for fabrikantens kontrol at levere.
Pligten til at levere sikkerhedsopdateringer kommer fra Cyber Resilience Act, som gælder fra 11. december 2027. Produktansvarsdirektivet dækker software, som kommer på markedet senere end 9. december 2026. Artiklen viser koblingen mellem de to. Den er ikke juridisk rådgivning, og den del, der forbinder supportperioden med ansvaret, er tolkning.
Kommissionens svar
Kommissionens tjenestegrene svarer i deres FAQ om CRA, afsnit 2.3.1, på netop dette spørgsmål. Oversat fra engelsk siger svaret, at direktivet ikke pålægger fabrikanter nogen materiel pligt til at opdatere eller opgradere produktet. Fabrikanten hæfter dog for defekter, der indføres med en opdatering, og for defekter, der opstår efter omsætningen, fordi en opdatering mangler.
Svaret tilføjer, at det er CRA, der indeholder de konkrete pligter om sikkerhedsopdateringer, nemlig i bilag I. FAQ’en er vejledning, og den udtrykker ikke Kommissionens officielle holdning.
Direktivets artikel 11, stk. 2
Grundreglen i artikel 11, stk. 1, litra c, fritager en erhvervsdrivende, hvis defekten sandsynligvis ikke forelå, da produktet blev bragt i omsætning. Artikel 11, stk. 2, gør en undtagelse fra den fritagelse. Fabrikanten fritages ikke, hvis defekten skyldes
- a) en relateret tjeneste,
- b) software, herunder opdateringer,
- c) “manglende softwareopdateringer eller -opgraderinger, der er nødvendige for at opretholde sikkerheden”,
- d) en væsentlig ændring,
“forudsat at det er inden for fabrikantens kontrol”.
Artikel 4, nr. 5, siger, at »fabrikantens kontrol« bl.a. omfatter, at fabrikanten “har mulighed for at levere softwareopdateringer eller opgraderinger selv eller via en tredjepart”.
For software betyder det, at forsvaret “defekten var der ikke ved leveringen” ikke hjælper, hvis problemet er en sikkerhedsopdatering, fabrikanten kunne have leveret.
Supportperioden i CRA
CRA fastsætter, hvor længe fabrikanten skal håndtere sårbarheder og levere sikkerhedsopdateringer:
- Artikel 13, stk. 8 · En supportperiode på mindst fem år, medmindre produktets forventede brugstid er kortere
- Artikel 13, stk. 9 · Hver sikkerhedsopdatering forbliver tilgængelig i mindst ti år eller resten af supportperioden
- Artikel 13, stk. 19 · Slutdatoen for supportperioden oplyses på købstidspunktet
Supportperioden fastlægges i den tekniske dokumentation. Hvordan begrundelsen skrives, står i supportperioden.
Koblingen er tolkning
Det følgende er tolkning. De læste kilder afklarer ikke, hvordan supportperiodens udløb påvirker “fabrikantens kontrol” efter direktivets artikel 4, nr. 5.
Man kunne forestille sig, at en fabrikant, der har oplyst en slutdato efter CRA og ikke længere leverer opdateringer, ikke har kontrollen. Man kunne også forestille sig, at kontrollen består, så længe fabrikanten faktisk har mulighed for at levere en rettelse. Teksten afgør det ikke, og der er ingen praksis. Skriv derfor ikke internt eller i kundemateriale, at ansvaret ophører, når supportperioden udløber.
Det, der står fast, er tidsrammerne i direktivet. Efter artikel 17 udløber kravet 10 år efter, at produktet blev bragt i omsætning, eller ved en væsentlig ændring efter, at den ændrede version kom på markedet. Ved personskade, der først viser sig senere, er fristen 25 år. Efter artikel 16 forældes kravet 3 år efter, at skadelidte fik kendskab til skaden. Disse frister kan række ud over en supportperiode på fem år.
Hvornår er en opdatering “nødvendig for sikkerheden”?
Artikel 11, stk. 2, litra c, taler om opdateringer, der er nødvendige for at opretholde sikkerheden. Direktivet definerer ikke, hvornår en opdatering er det. Det er nærliggende at se på CRA’s krav i bilag I og på fabrikantens egen sårbarhedshåndtering, men det er en tolkning.
En fabrikant, der kan vise, hvordan hver kendt sårbarhed er vurderet, og hvorfor en rettelse er eller ikke er udsendt, har i det mindste et grundlag at forklare sig ud fra. Hvordan den vurdering dokumenteres, når en sårbarhed ikke rettes, er beskrevet i “ikke berørt”-vurderingen.
Opdateringer kan også indføre defekter
Svaret i FAQ’en har to sider. Fabrikanten hæfter også for defekter, der indføres med en opdatering. Artikel 11, stk. 2, litra b, nævner software “herunder opdateringer”. En test af sikkerhedsopdateringer før udsendelse beskytter altså mod to ting på en gang. Det sidste er en praktisk følge.
Efter direktivets artikel 7, stk. 3, er et produkt ikke defekt, blot fordi en opdatering kommer senere. En senere forbedring gør altså ikke i sig selv den tidligere version defekt.
Hvad det kræver, og hvad det koster at lade være
Det kræver en sårbarhedshåndtering, hvor beslutninger om at rette eller ikke rette er skrevet ned, en opdateringskanal, der virker i hele supportperioden, og en test af opdateringerne. Det kræver også, at oplysningen om supportperiodens slutdato er præcis.
Lader I være, står I uden forklaring, hvis en skadelidt peger på en sårbarhed, der kunne være rettet. Direktivets frister rækker op til 10 år, og ved latent personskade 25 år.
Det skal I lade være med
- At love kunder, at ansvaret slutter med supportperioden · det er ikke afklaret.
- At udsende sikkerhedsopdateringer uden test · defekter fra opdateringer er også omfattet.
- At bruge FAQ’en som lov · den er vejledning fra Kommissionens tjenestegrene.
Det skal auditten kunne vise
- ☐ En fastlagt og begrundet supportperiode for hver version.
- ☐ En registrering af hver kendt sårbarhed med beslutning og dato.
- ☐ Bevis for test af sikkerhedsopdateringer før udsendelse.
- ☐ Et arkiv, hvor sikkerhedsopdateringerne fortsat kan hentes.
Kilder
- Direktiv (EU) 2024/2853 om produktansvar, artikel 2, 4, nr. 5, 7, stk. 3, 11, 16 og 17, læst 13. november 2026.
- Europa-Kommissionens tjenestegrene, FAQs on the Cyber Resilience Act, version 1.4, afsnit 2.3.1, læst 13. november 2026.
- Forordning (EU) 2024/2847, artikel 13, stk. 8, 9 og 19, og artikel 71, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Se på, om jeres sårbarhedsregister viser en beslutning og en dato for hver kendt sårbarhed i de understøttede versioner.
Læs også: Hver sikkerhedsopdatering skal kunne hentes i ti år · Alle sårbarheder skal håndteres, ikke alle skal rettes
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
