Et konsulenthus, der installerer open source på kundens egen server og rådgiver om brugen, bringer ikke softwaren i omsætning og bliver ikke fabrikant efter CRA. Det kan ændre sig, når konsulenthuset foretager en væsentlig ændring af softwaren og leverer den ændrede udgave, og derfor skal det kunne vises, hvad der er ændret.
Spørgsmålet er ikke behandlet direkte i nogen af de kilder, vi har læst. Vejledningen fra Kommissionen, C(2026) 5252, har et eksempel om installation og en generel regel om væsentlige ændringer, og artikel 22 i forordningen handler om den, der ændrer en andens produkt. Hvordan de passer sammen for en konsulent, der leverer en ændret udgave til én kunde, er vores tolkning, og den skal vurderes konkret.
Installation og rådgivning
Vejledningen siger, at en serviceleverandør, der hjælper en kunde med at installere open source på kundens egen server uden at ændre den væsentligt, ikke bringer softwaren i omsætning (punkt 59 og eksempel 19). Det samme gælder bistand til open source, der ikke er under serviceleverandørens eget ansvar.
Det dækker en stor del af det, konsulenthuse laver: opsætning, konfiguration, integration med kundens øvrige systemer, undervisning og drift. Konfiguration gennem de indstillinger, softwaren selv tilbyder, er efter vores læsning ikke en ændring af produktet.
Den væsentlige ændring
Artikel 22, stk. 1, siger, at en person, der ikke er fabrikant, importør eller distributør, og som foretager en væsentlig ændring af et produkt og bringer det i omsætning, anses for fabrikant. Efter stk. 2 gælder pligterne i artikel 13 og 14 for den del af produktet, ændringen berører. Påvirker ændringen cybersikkerheden af produktet som helhed, gælder de for hele produktet.
Artikel 3, nr. 30, kalder en ændring væsentlig, når den har virkning for overholdelsen af bilag I, del I, eller for det formål, produktet er vurderet til. Betragtning 39 og vejledningens afsnit 4.3 uddyber det. Vejledningen lægger vægt på ændringens virkning på risikoprofilen. Vejledningen spørger bl.a., om ændringen åbner nye grænseflader, kanaler eller afhængigheder, og om den giver nye angrebsmuligheder.
Tænkte eksempler på ændringer, der kan være væsentlige: et nyt modul, der giver adgang udefra til en funktion, softwaren ikke havde, en ændret autentificering, eller fjernelse af en indbygget sikkerhedskontrol for at få en integration til at virke. Tænkte eksempler på ændringer, der næppe er det: oversættelse af brugerfladen, et nyt tema eller en rettelse af inputvalidering.
Bringer I den ændrede udgave i omsætning?
Her ligger det uafklarede. Artikel 22 kræver både en væsentlig ændring og at produktet bringes i omsætning. Om en ændret udgave, der kun installeres hos én kunde, bringes i omsætning, afhænger af, om den leveres som led i erhvervsvirksomhed. Et konsulenthus, der tager betaling, leverer som udgangspunkt erhvervsmæssigt, men ingen kilde siger, hvordan reglen skal anvendes på en ændret udgave til én kunde. Skriv derfor ikke ind i jeres egne processer, at enhver tilpasning gør jer til fabrikant. Skriv heller ikke det modsatte.
Vejledningen tilføjer en grænse i den anden retning. Samler I komponenter, også ændrede, til et nyt produkt og bringer det i omsætning, er I fabrikant af hele det nye produkt (punkt 120 og eksempel 51). Den situation følger den almindelige fabrikantrolle.
Hvad der følger, hvis I er fabrikant
Er konsulenthuset fabrikant efter artikel 22, gælder pligterne for den berørte del. Vejledningen gengiver i fodnote 16 Kommissionens Blue Guide. Test og dokumentation skal ikke gentages for de dele, ændringen ikke påvirker, men den, der ændrer, skal kunne vise, hvorfor resten af dokumentationen ikke skal opdateres, og skal selv udarbejde erklæringen. Den oprindelige udgivers pligter fortsætter for det oprindelige produkt (punkt 117-121).
Dokumentationen af ændringer
Uanset hvor grænsen ender, er det almindelig praksis at føre en ændringslog for hver kundeinstallation. Den gør det muligt at vurdere rollen bagefter og at svare, hvis kunden eller en myndighed spørger.
- Kunde og installation · (kunde A, produktionsmiljø)
- Oprindelig version · (open source-projektets udgivelse, med versionsnummer)
- Ændring i koden · (nyt modul til eksport via API)
- Påvirker bilag I, del I, eller formålet? · (ja, ny ekstern grænseflade)
- Vurdering af rollen · (mulig fabrikant for den ændrede del, forelagt juridisk vurdering)
- Dato og ansvarlig · (dato, navn)
Hvad det kræver, og hvad det koster at lade være
Det kræver, at ændringer i koden skilles fra konfiguration, og at hver kodeændring får en kort vurdering efter de fire spørgsmål om risikoprofilen. For konsulenthuse, der allerede bruger versionsstyring for kundeændringer, er det meste af sporet til stede.
Uden ændringsloggen kan I ikke vise, at en installation kun var en installation. Og hvis en ændring var væsentlig, mangler den risikovurdering og dokumentation, artikel 13 kræver for den berørte del.
Det skal I lade være med
- At blande konfiguration og kodeændringer i samme log · kun ændringer i koden kan være væsentlige ændringer.
- At fjerne sikkerhedskontroller for at få en integration til at virke · det er et typisk tegn på en ændring, der påvirker bilag I.
- At lægge rolleafgørelsen ind i kontrakten uden en vurdering · rollen følger af forordningen.
Det skal auditten kunne vise
- ☐ En ændringslog pr. kundeinstallation, der skiller kodeændringer fra konfiguration.
- ☐ En dateret vurdering af hver kodeændring mod artikel 3, nr. 30.
- ☐ Ved væsentlige ændringer: en vurdering af, om den ændrede udgave er bragt i omsætning.
- ☐ Hvor rollen er fabrikant: risikovurdering og dokumentation for den berørte del.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 3, nr. 30, artikel 13, 14 og 22 og betragtning 39, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, afsnit 4.3, punkt 59, 117-121, fodnote 16 og eksempel 19 og 51, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Vælg tre kundeinstallationer, og skil kodeændringer fra konfiguration i hver af dem.
Læs også: Fabrikant, forvalter eller ingen af delene? · I ændrer en andens kommercielle software
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
