Når en kunde får software udviklet hos jer og markedsfører den under sit eget navn eller varemærke, er kunden fabrikant efter Cyber Resilience Act. I får ikke selv fabrikantens pligter for det produkt, men kunden har brug for en række leverancer fra jer for at kunne opfylde sine.
Hvad kunden beder om, er et spørgsmål om aftale og praksis. Forordningen regulerer det ikke direkte, og det er derfor fabrikantens egne pligter, der viser, hvad der bliver efterspurgt.
Fabrikant er den, der markedsfører
Artikel 3, nr. 13, i forordning (EU) 2024/2847 definerer fabrikanten som den, der udvikler eller fremstiller produkter med digitale elementer, eller som får dem designet, udviklet eller fremstillet og markedsfører dem under sit navn eller varemærke. Det gælder, hvad enten produktet sælges, udnyttes kommercielt på anden måde eller stilles til rådighed uden vederlag.
Det er altså markedsføringen under eget navn, der gør kunden til fabrikant, selv om kunden ikke har skrevet en linje kode. Artikel 21 peger samme vej for importører og distributører. Bringer de et produkt i omsætning under eget navn eller varemærke, anses de for fabrikant og får pligterne i artikel 13 og 14.
Det, ansvaret ikke kan flytte
Efter artikel 18, stk. 1, må fabrikanten give en repræsentant skriftlig fuldmagt til at handle for sig. Stk. 2 sætter grænser. Pligterne i artikel 13, stk. 1 til 11, i stk. 12, første afsnit, og i stk. 14 kan ikke indgå i fuldmagten. Det dækker bl.a. risikovurderingen i stk. 2 til 4 og udarbejdelsen af den tekniske dokumentation i stk. 12.
Bestemmelsen handler om repræsentanter og ikke om udviklingshuse. Den viser dog, hvor fast forordningen holder pligterne hos fabrikanten. En aftale, der lægger alt ansvar hos udviklingshuset, ændrer ikke på, hvem myndigheden henvender sig til.
Det, kunden har brug for
Ingen regel pålægger udviklingshuset at levere bestemte ting til fabrikanten. Listen nedenfor er derfor en udledning af fabrikantens egne pligter. Den er vores tolkning og viser, hvad en fabrikant med rimelighed vil efterspørge.
- Risikovurdering (artikel 13, stk. 2 til 4) · Arkitekturbeskrivelse og viden om design og grænseflader
- Egenskabskrav (bilag I, del I) · Beskrivelse af, hvordan hvert krav er løst i koden
- Sårbarhedshåndtering (bilag I, del II) · Softwarekomponentliste og besked om sårbarheder og rettelser
- Teknisk dokumentation (bilag VII) · Beskrivelse af udviklingsprocessen og resultater af afprøvninger
- Indberetning (artikel 14) · Hurtig besked, når en aktivt udnyttet sårbarhed bliver kendt
Den sidste linje er den, der haster. Artikel 14 har gjaldt siden 11. september 2026 og omfatter også ældre versioner, kunden allerede har solgt. Har kunden ikke en aftale om, hvordan I melder en udnyttet sårbarhed, kan fristerne i artikel 14 være svære at nå. De øvrige krav gælder fra 11. december 2027.
Hvornår I selv kan blive fabrikant
Situationen er en anden, hvis I leverer en del, som I også bringer i omsætning for sig. Artikel 3, nr. 1, omfatter softwarekomponenter, der bringes i omsætning separat. Sælger I et bibliotek eller et modul til flere kunder, og bygger kunden det ind, kan I være fabrikant af den komponent.
Ingen læst kilde behandler udviklingshusets situation direkte, så vurderingen bør tages med forbehold og gøres for hver leverance. Komponentens pligter er beskrevet i biblioteker, SDK’er og komponenter solgt særskilt.
Aftalen set fra udviklingshuset
For jer handler aftalen om at kunne levere det, kunden har brug for, uden at påtage jer pligter, forordningen lægger hos kunden. Det er almindelig praksis at beskrive leverancerne konkret, fx hvilken dokumentation der følger med hver release, hvem der overvåger komponenterne, og hvor hurtigt sårbarheder meldes.
Hvordan kunden kontrollerer jer som leverandør, er beskrevet fra kundens side på leverandøraudit. Aftalens indhold, når I sælger en andens software under eget navn, står i artiklen om white label.
Et tænkt eksempel
Et udviklingshus i Aarhus har bygget et program til tidsregistrering for en kæde af konsulentfirmaer. Kæden sælger programmet videre til sine franchisetagere under kædens eget navn. Kæden er derfor fabrikant. Udviklingshuset har koden, byggemiljøet og overblikket over komponenterne. Kontrakten nævner fejlrettelser, men intet om komponentlister eller om, hvem der skal opdage og melde en aktivt udnyttet sårbarhed. Når kæden spørger, hvordan den skal kunne indberette inden for fristerne i artikel 14, har ingen af parterne et svar. Løsningen er en tilføjelse til aftalen, der beskriver leverancerne, og en fast kontakt i hver virksomhed. Eksemplet er tænkt.
Hvad det kræver, og hvad det koster at lade være
Det kræver et overblik over de kunder, der markedsfører software, I har udviklet, under eget navn, og at I kan levere komponentlister, dokumentation og sårbarhedsbesked i et format, kunden kan bruge.
Uden afklaring risikerer begge parter at vente på hinanden. Kunden har pligterne, og I har viden, kunden ikke kan opfylde dem uden.
Det skal I lade være med
- At gå ud fra, at I er fabrikant, fordi I har skrevet koden · rollen følger navnet, produktet sælges under.
- At love at overtage kundens pligter i aftalen · forordningen holder dem hos fabrikanten.
- At vente med en aftale om sårbarhedsbesked til 2027 · artikel 14 gælder allerede.
Det skal auditten kunne vise
- ☐ En liste over kunder, der markedsfører jeres software under eget navn.
- ☐ For hver kunde, hvilke leverancer der er aftalt til dokumentation og sårbarheder.
- ☐ En aftalt kanal og frist for besked om aktivt udnyttede sårbarheder.
- ☐ En vurdering af, om nogen leverance er en komponent, I selv bringer i omsætning.
Kilder
- Forordning (EU) 2024/2847, dansk tekst, artikel 3, nr. 1 og 13, artikel 13, 14, 18 og 21, bilag I og VII, læst 13. november 2026 i Publikationskontorets kopi.
Senest gennemgået: november 2026.
Næste skridt
Find de kunder, der sælger jeres software under eget navn, og se, hvad I har aftalt om sårbarhedsbesked.
Læs også: Mobilapps · Software udviklet til én erhvervskunde
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
