Cyber Resilience

I ændrer en andens kommercielle software: ændret produkt eller nyt produkt bygget af komponenter?

I ændrer en andens kommercielle software: ændret produkt eller nyt produkt bygget af komponenter?

Ændrer I en andens kommercielle software væsentligt og bringer den i omsætning, bliver I fabrikant efter Cyber Resilience Act. Pligterne gælder den ændrede del, medmindre ændringen påvirker cybersikkerheden for produktet som helhed. Bygger I derimod et nyt produkt af komponenter, står I med fabrikantens pligter for alt i det nye produkt.

Skellet afgør, hvor meget dokumentation I skal lave. Reglerne gælder fra 11. december 2027. Artiklen handler om kommerciel software. Open source, der tilpasses hos kunden, er et andet spor.

Hvem forordningen taler om

Artikel 21 siger, at en importør eller distributør, der foretager en væsentlig ændring af et produkt, anses for fabrikant og er omfattet af pligterne i artikel 13 og 14. Forordningens ord er distributør, også hvor man i daglig tale siger forhandler.

Artikel 22, stk. 1 og 2, rækker videre. Også andre, der laver en væsentlig ændring og derefter udbyder det ændrede produkt, får fabrikantens rolle. For dem gælder artikel 13 og 14 i det omfang, ændringen rækker. Rammer ændringen produktets cybersikkerhed samlet set, omfatter pligterne alt.

En integrator, der tilpasser en andens software og leverer den videre, falder typisk ind under artikel 22. En distributør, der ændrer et produkt, den forhandler, falder under artikel 21. Det er en forenkling. Den enkelte rolle afhænger af, hvordan produktet bringes i omsætning.

Ændret del eller hele produktet

Kommissionens vejledning (punkt 118 og 119) siger, at når ændringen ikke påvirker cybersikkerheden som helhed, gælder pligterne kun for den ændrede del. Den oprindelige fabrikants pligter gælder fortsat for det oprindelige produkt.

Påvirker ændringen helheden, er det et nyt produkt, og pligterne gælder for det hele (punkt 121). Vejledningen nævner som tegn, at ændringen ikke længere er afgrænset til en bestemt komponent eller et bestemt delsystem.

Et tænkt eksempel gør skellet tydeligt. En integrator tilføjer et nyt rapportmodul til et lagersystem fra en anden producent. Modulet læser data via systemets eksisterende grænseflade og ændrer intet andet. Det er en afgrænset ændring. En anden integrator omskriver systemets login og rettighedsstyring, så kunden kan bruge sit eget fælles login. Den ændring rører ved hele systemets sikkerhed, og det er nærliggende at se den som en ændring af helheden. Begge vurderinger er vores tolkning af vejledningen.

At ændre eller at bygge nyt

Vejledningen (punkt 120, eksempel 51) skelner mellem at ændre et produkt og at samle komponenter til et nyt. Den, der sætter komponenter sammen, ændrede eller ej, og udbyder resultatet som et nyt produkt, har efter vejledningen ikke ændret et andet produkt. Den har alle fabrikantens pligter for det samlede resultat. Den kan til gengæld støtte sig til komponentfabrikanternes egne overensstemmelsesaktiviteter.

Det er en vigtig forskel for dokumentationen:

  • Afgrænset væsentlig ændring af en andens produkt · Hvem er fabrikant: Den, der ændrer, for sin del · Pligterne gælder: Den ændrede del
  • Ændring, der påvirker sikkerheden som helhed · Hvem er fabrikant: Den, der ændrer · Pligterne gælder: Hele produktet
  • Nyt produkt samlet af komponenter · Hvem er fabrikant: Den, der samler · Pligterne gælder: Hele det nye produkt, med støtte i komponenternes dokumentation

Hvad der kan genbruges

Vejledningen citerer i fodnote 16 Kommissionens Blue Guide om ændrede produkter. Test og dokumentation skal ikke gentages for aspekter, ændringen ikke berører. Den, der ændrer, skal kunne vise, at ikke alle dele af dokumentationen skal opdateres. Ansvaret for, at det ændrede produkt overholder kravene, og for erklæringen ligger hos den, der ændrer.

Det betyder, at den, der ændrer, skal have adgang til nok af den oprindelige dokumentation til at kunne afgrænse sin egen del. Det er et spørgsmål, der hører hjemme i aftalen med den oprindelige producent, før ændringen laves.

Sårbarhedshåndteringen er et særligt punkt. Den, der har ændret en del af produktet, har pligterne i artikel 13 for sin del, herunder bilag I, del II. Sårbarheder i den ændrede del skal derfor håndteres af den, der ændrede. Sårbarheder i den oprindelige del ligger fortsat hos den oprindelige fabrikant, når ændringen er afgrænset. Det er vores læsning af vejledningens punkt 118 og 119, og det forudsætter en aftale mellem de to parter om, hvordan meldinger sendes videre.

Hvad gennemgangen ser efter

Gennemgangen afklarer typisk først rollen og derefter omfanget. Hvilken software er ændret, og af hvem? Er ændringen væsentlig efter de fire prøvesten? Er den afgrænset til en komponent eller et delsystem? Og findes der en skriftlig begrundelse for, at resten af produktet er uberørt?

Bagefter ser gennemgangen på dokumentationen for den ændrede del: risikovurdering, test og den overensstemmelseserklæring, som den, der ændrer, selv skal underskrive.

Hvad det kræver, og hvad det koster at lade være

Det kræver en skriftlig vurdering af, om ændringen er væsentlig, og om den er afgrænset. Det kræver også, at aftalen med den oprindelige producent giver adgang til det materiale, der gør det muligt at afgrænse ansvaret.

Uden vurderingen kan en integrator stå med pligter for et helt produkt, den ikke selv har bygget, og uden adgang til den dokumentation, der skulle til. Det er sværere at rette bagefter end at aftale før.

Det skal I lade være med

  • At gå ud fra, at tilpasning aldrig gør jer til fabrikant · en væsentlig ændring gør det.
  • At ændre login eller rettigheder og kalde det afgrænset · den slags kan påvirke helheden.
  • At lave ændringen, før aftalen om dokumentation er på plads · I skal kunne vise, hvad der er uberørt.

Det skal auditten kunne vise

  • ☐ Afklaret rolle efter artikel 21 eller 22.
  • ☐ Vurdering af, om ændringen er væsentlig og afgrænset.
  • ☐ Begrundelse for, at uberørte dele ikke skal dokumenteres igen.
  • ☐ Risikovurdering, test og erklæring for den del, I er ansvarlige for.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Skriv for hver tilpasning, I leverer af en andens software, om den er afgrænset til en komponent, og hvorfor.

Læs også: I installerer og tilpasser open source hos kunden · Forhandler af andres software

→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal jeres software gennemgås?

Skriv kort, hvilket produkt det drejer sig om, og hvad der sætter det i gang. Så vender jeg tilbage. Gennemgangen er uvildig og uafhængig, og Nielco IT har ingen forhandleraftaler.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.