De fleste driftsafdelinger har skrevet deres egne scripts, små agenter og integrationer mellem systemer. Så længe de kun bruges i virksomheden selv, er de uden for Cyber Resilience Act. De kommer ind, når virksomheden leverer dem til andre, som kører dem på egne maskiner, og så er virksomheden fabrikant.
For en teknisk gennemgang er der derfor to spørgsmål: om koden er sikker, og hvem den leveres til.
Prøven: gjort tilgængelig og kørt hos en bruger
Forordning 2024/2847 omfatter efter artikel 2, stk. 1, produkter med digitale elementer, der stilles til rådighed på markedet. Det sker, når de leveres i erhvervsmæssig sammenhæng, uanset om modtageren betaler (artikel 3, nr. 22). Et program, der gives væk til en kunde, kan altså være omfattet.
Kommissionen skriver i sin vejledning, at software hører ind under forordningen, når brugeren får den udleveret og afvikler den på sit eget system. Software, der kører et andet sted og kun tilgås gennem en browser, er som udgangspunkt ikke selv et produkt. Prøven er gennemgået i artiklen om, hvornår software er leveret til brugeren og kørt hos brugeren.
Kommissionens tjenestegrenes FAQ svarer, at værktøjer, en virksomhed laver til sig selv, som udviklings- og konfigurationsværktøjer, falder uden for, så længe de ikke også sælges eller udleveres som selvstændige produkter. FAQ’en er ikke Kommissionens officielle holdning, men den viser, hvordan Kommissionens folk læser reglen.
Tre situationer, driften kan genkende
Eksemplerne er tænkte, og vurderingen er en forenkling. Den konkrete afgørelse hviler på forordningens ordlyd og jeres egne forhold.
Kun til eget brug. Et script, der hver nat trækker brugerkonti ud af kataloget og sammenligner dem med lønsystemet, kører kun på virksomhedens egne servere. Det er ikke gjort tilgængeligt for andre. Forordningen gælder ikke, og scriptet kontrolleres som alle andre interne systemer.
Leveret til kunder, der installerer det. En virksomhed giver sine kunder et lille program, der skal installeres hos kunden for at sende data til virksomhedens system. Programmet leveres som led i erhvervsvirksomheden og kører hos kunden. Det peger på, at programmet er et produkt, og at virksomheden er fabrikant, også selv om kunden ikke betaler for det.
Udviklet til én bestemt kunde. Software, der laves til én erhvervskunde, er stadig et produkt, når den leveres. Kun to krav kan fraviges ved aftale for et skræddersyet produkt, og det står i artiklen om software udviklet til én erhvervskunde.
En særlig situation er open source, som driften installerer hos en kunde. Kommissionen skriver, at en serviceleverandør, der installerer open source på kundens server uden væsentlig ændring, ikke bringer softwaren i omsætning. Ændres den væsentligt og bringes i omsætning, kan den, der ændrer, blive fabrikant efter artikel 22. Grænsen er gennemgået under open source, der tilpasses hos kunden.
Indberetningen gælder allerede
Langt de fleste krav gælder først fra 11. december 2027 og rammer kun versioner, der kommer på markedet derefter, eller som ændres væsentligt. Indberetningen efter artikel 14 har derimod gældt siden 11. september 2026, og den omfatter også programmer, der blev udleveret før 2027 (artikel 69, stk. 3).
Leverer virksomheden allerede et program til kunder, skal en aktivt udnyttet sårbarhed i programmet altså indberettes nu. Det kræver, at nogen ved, at programmet findes, og hvem der modtager meldinger om det. Det er sjældent driften, der har overblikket, når et script er vokset til et kundeprogram.
Kontrollen af det, der kun bruges internt
For værktøjer til eget brug er det ikke CRA, men de almindelige kontrolpunkter, gennemgangen holder dem op imod. Det er især fire ting.
- Hvor koden ligger. Kode i en kildekodeplatform med adgangsstyring og spor kan efterprøves. Kode på en enkelt medarbejders maskine kan ikke. Kontrolpunkterne står i kildekodeplatform og udrulningskæde.
- Hvilken identitet den kører med. Mange scripts kører med en servicekonto med brede rettigheder. Kontoen skal have en ejer og kun de rettigheder, scriptet bruger.
- Hvor hemmelighederne står. Adgangskoder og nøgler skrevet direkte i et script er et fund. Hvordan forbindelserne opgøres, står i integrationer mellem systemer.
- Hvem der opdaterer komponenterne. Et script, der bruger biblioteker udefra, skal have dem opdateret. De statslige minimumskrav giver egenudviklet software på internetvendte tjenester 30 dage fra færdigtestet opdatering. Fristen er bindende i staten og kan bruges som pejlemærke i private virksomheder.
Registret over egenudviklet kode
Følgende felter er praksis. Tænkte eksempler i parentes.
- Navn og formål (synkronisering af brugere mellem katalog og lønsystem).
- Hvor koden ligger, og hvem der ejer den (kildekodeplatformen, driftschefen).
- Hvor den kører (egen server, intern).
- Om den leveres til nogen uden for virksomheden, og til hvem (nej).
- Konto og hemmeligheder, den bruger (servicekonto, nøgle i nøgleboksen).
- Vurdering efter CRA med begrundelse (kun eget brug, ikke omfattet).
Feltet om levering er det, der afgør, om resten af sagen hører til driften eller til en produktansvarlig.
Det, gennemgangen prøver
Gennemgangen beder om registret og sammenligner det med kildekodeplatformen, de planlagte job på serverne og de servicekonti, der findes. Et job eller en konto uden en række i registret er et fund. For hver kode, der leveres til andre, ses der efter, hvem der er udpeget til at modtage og vurdere meldinger om sårbarheder. Selve gennemgangen af et produkt efter forordningen er en anden opgave end en teknisk gennemgang af driften.
Hvad det kræver, og hvad det koster at lade være
Det kræver et register over egenudviklet kode og et spørgsmål, der stilles hver gang, noget nyt skrives: skal det leveres til nogen uden for huset? Første opgørelse tager tid, fordi scripts sjældent er skrevet ned.
Uden registret kan et internt værktøj blive til et kundeprogram, uden at nogen har opdaget, at virksomheden dermed er fabrikant med en indberetningspligt, der allerede gælder.
Det skal I lade være med
- At regne alt, I selv har skrevet, for internt · det afgørende er, om det leveres til andre.
- At tro, at uden betaling betyder uden for forordningen · levering uden vederlag tæller også.
- At lade scripts køre med personlige konti · de forsvinder, når medarbejderen gør.
Det skal gennemgangen kunne vise
- ☐ Et register over egenudviklet kode med ejer, placering og levering.
- ☐ Afstemning af registret mod planlagte job og servicekonti.
- ☐ En begrundet vurdering efter CRA for kode, der leveres til andre.
- ☐ En udpeget modtager af sårbarhedsmeldinger for leveret kode.
- ☐ Hemmeligheder uden for koden og servicekonti med ejer.
Kilder
- Forordning (EU) 2024/2847 (Cyber Resilience Act), artikel 2, stk. 1, artikel 3, nr. 13 og 22, artikel 14, artikel 22, artikel 69, stk. 2 og 3, artikel 71 og bilag I, læst 13. november 2026.
- Europa-Kommissionen, Commission guidance on the application of Regulation (EU) 2024/2847, C(2026) 5252, 27. juli 2026, punkt 20, 21, 59 og 117 til 121, læst 13. november 2026.
- Europa-Kommissionens tjenestegrene, FAQs on the Cyber Resilience Act, version 1.4 af 4. september 2026, FAQ 1.5 og 4.2.5, læst 13. november 2026.
- Vejledning til de tekniske minimumskrav til it-sikkerhed i staten, september 2025, afsnit 3.9, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Træk de planlagte job fra jeres servere, og skriv ud for hvert script, hvor koden ligger, og om den leveres til andre.
Læs også: Udviklings- og testmiljøer · Udtræk med script og API
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
