Efter det nye produktansvarsdirektiv er software et produkt, og fabrikanten kan derfor hæfte objektivt for skade, som defekt software forvolder. Direktivet indfører samtidig regler om fremlæggelse af bevis og formodninger, der kan lette skadelidtes bevisbyrde, og her kan et dokumenteret udviklingsforløb få betydning.
Artiklen gengiver direktivets regler. Den er ikke juridisk rådgivning. Hvad reglerne betyder for en bestemt virksomhed, kræver en konkret vurdering, og de steder, hvor teksten nedenfor tolker, er markeret.
Status for den danske lov
Direktivet er rettet til medlemsstaterne og gælder først gennem national lov. Justitsministeren fremsatte 7. oktober 2026 L 32, Forslag til lov om produktansvar. Første behandling var 3. november 2026, og 13. november 2026 var sagens status “1. beh./Henvist til udvalg”. Folketingets tidsplan peger på betænkning 24. november og tredje behandling 3. december 2026. Det er en plan, og loven var ikke vedtaget 13. november 2026.
Folketingets resumé siger, at lovforslaget gennemfører direktivet, viderefører det objektive ansvar, udvider kredsen af ansvarlige og indfører formodningsregler. Loven foreslås at træde i kraft 1. januar 2027. Selve lovteksten og bemærkningerne kunne ikke hentes og er ikke læst, så hvordan Danmark gennemfører de enkelte artikler, er ikke undersøgt her.
Efter direktivets artikel 2, stk. 1, gælder det produkter, der bringes i omsætning eller tages i brug efter 9. december 2026. Det gamle direktiv gælder fortsat for produkter bragt i omsætning før (artikel 21).
Software er et produkt
Artikel 4, nr. 1, lader »produkt« omfatte “elektricitet, digitale produktionsfiler, råmaterialer og software”. Betragtning 13 siger, at det gælder uanset leverings- eller brugsmåden, også når softwaren tilgås via et netværk eller cloud eller leveres som SaaS. Samme betragtning siger, at “blot kildekoden for software” ikke er et produkt.
Efter artikel 2, stk. 2, gælder direktivet ikke for open source-software uden licensbetaling, der er udviklet eller leveret uden for en kommerciel aktivitet. Leveres software mod betaling eller mod personoplysninger, der bruges til andet end sikkerhed, kompatibilitet eller interoperabilitet, gælder direktivet efter betragtning 14.
Hvilke skader der dækkes
Artikel 6, stk. 1, begrænser ansvaret til visse skader:
- død eller personskade, også lægeligt anerkendt skade på den mentale sundhed,
- skade på ejendele, dog ikke selve produktet og ikke ejendele, der udelukkende anvendes til erhvervsmæssige formål,
- ødelæggelse eller beskadigelse af data, der ikke anvendes til erhvervsmæssige formål.
Efter artikel 1 og 5 har kun fysiske personer ret til erstatning. For et softwarehus med erhvervskunder kan det betyde, at direktivet sjældnere rammer, end overskriften antyder. Det er en tolkning, og den afhænger af, hvordan produktet bruges.
Hvornår er software defekt?
Efter artikel 7, stk. 1-2, er et produkt defekt, hvis det ikke frembyder den sikkerhed, en person med rette kan forvente, eller som er påkrævet efter EU-retten eller national ret. Der tages hensyn til alle omstændigheder. Blandt dem nævner litra f “relevante produktsikkerhedskrav, herunder sikkerhedsrelevante cybersikkerhedskrav”. Litra e nævner tidspunktet, hvor fabrikanten mistede kontrollen med produktet, og litra g tilbagekaldelser.
Efter stk. 3 er et produkt ikke defekt, alene fordi et bedre produkt eller en opdatering kommer senere.
Bevis og formodninger
Artikel 9 giver en sagsøger, der har gjort kravet sandsynligt, mulighed for at få sagsøgte pålagt at fremlægge relevant bevismateriale. Pligten er begrænset til det nødvendige og forholdsmæssige, og forretningshemmeligheder beskyttes.
Artikel 10, stk. 2, lader defekt antage, hvis sagsøgte ikke fremlægger bevismaterialet, hvis produktet ikke opfylder obligatoriske produktsikkerhedskrav, der skal beskytte mod den lidte skade, eller hvis skaden skyldes en åbenbar fejl ved normal brug. Stk. 4 lader domstolen antage defekt eller årsagsforbindelse ved uforholdsmæssigt store bevisvanskeligheder, bl.a. ved teknisk kompleksitet. Efter stk. 5 kan alle formodninger afkræftes.
Koblingen til CRA
Kommissionens tjenestegrene skriver i deres FAQ, at CRA og direktivet er af forskellig karakter og supplerer hinanden, men uden juridisk overlap. Defekt vurderes under hensyn til alle omstændigheder, også cybersikkerhedskrav.
Det følgende er tolkning. Ingen læst kilde siger med disse ord, at CRA’s krav er “obligatoriske produktsikkerhedskrav” efter artikel 10 eller “sikkerhedsrelevante cybersikkerhedskrav” efter artikel 7. Hvis de er det, kan en manglende risikovurdering eller manglende sårbarhedshåndtering få betydning i en erstatningssag. Det er også en tolkning, at et dokumenteret udviklingsforløb kan bruges som bevis, når artikel 9 kræver fremlæggelse.
Bemærk datoerne. Direktivet gælder produkter bragt i omsætning efter 9. december 2026. Forordningens produktkrav følger først et år senere, i december 2027.
Fritagelser og aftaler
Artikel 11, stk. 1, giver fritagelser, bl.a. når defekten sandsynligvis ikke forelå ved omsætningen, når den skyldes overholdelse af retlige krav, eller når den videnskabelige og tekniske viden ikke gjorde det muligt at opdage den. Medlemsstaterne kan efter artikel 18 bevare eller indføre ansvar for udviklingsrisici. Hvordan Danmark håndterer det, er ikke undersøgt.
Efter artikel 15 kan ansvaret over for skadelidte ikke begrænses ved kontrakt. Efter artikel 12, stk. 2, har en fabrikant, der integrerer software fra en mikro- eller lille virksomhed, ikke regres mod den, hvis der er aftalt afkald.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at beslutninger om sikkerhed i udviklingen er skrevet ned og kan findes, også for versioner, der er flere år gamle. Det kræver også, at nogen med juridisk indsigt vurderer, hvordan den danske lov gennemfører direktivet, når den er vedtaget.
Uden dokumentation kan artikel 10, stk. 2, litra a, blive aktuel. Kan bevismaterialet ikke fremlægges, kan defekt antages.
Det skal I lade være med
- At tro, at SaaS falder uden for produktansvaret · betragtning 13 nævner det udtrykkeligt.
- At begrænse ansvaret over for skadelidte i licensvilkårene · artikel 15 tillader det ikke.
- At bruge artiklen som juridisk vurdering · den danske lovtekst er ikke læst.
Det skal auditten kunne vise
- ☐ Dokumenterede sikkerhedsbeslutninger pr. version, der kan fremlægges.
- ☐ En oversigt over, om produktet bruges af forbrugere eller kun erhvervsmæssigt.
- ☐ Datoer for, hvornår hver version blev bragt i omsætning.
- ☐ En dateret note om status for den danske lov.
Kilder
- Direktiv (EU) 2024/2853 om produktansvar, artikel 1, 2, 4-7, 9-12, 15, 18, 21 og 22 samt betragtning 13 og 14, læst 13. november 2026.
- Folketinget, L 32 Forslag til lov om produktansvar, samling 2026-27), resumé og status, 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.
Senest gennemgået: november 2026.
Næste skridt
Find ud af, om jeres produkter bruges af forbrugere, og om sikkerhedsbeslutningerne for de seneste versioner kan findes og fremlægges.
Læs også: SaaS og kildekode i CRA og produktansvaret · Cybersikkerhedsrisikovurderingen for et softwareprodukt
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
