En virksomhed, der sælger maskiner med styring, app eller kundeportal, laver software, også selv om den aldrig ville kalde sig et softwarehus. Softwaren har brug for en navngiven ansvarlig med mandat over versioner, opdateringer, underleverandører og supportperiode, for kunden køber den som en del af maskinen under jeres navn. Mange maskinbyggere har aldrig placeret det ansvar, fordi softwaren er vokset frem i el-afdelingen, hos en integrator eller hos en dygtig tekniker. Her er det, en direktør skal vide, og det, I selv kan afklare.
Sådan ser det ud i dag
Et tænkt eksempel: En maskinbygger med 60 ansatte leverer pakkelinjer. Styringen er programmeret af en ekstern integrator, skærmen ved maskinen af en underleverandør, og servicefolkene bruger en kundeportal, som et bureau har bygget. Tre leverandører, tre aftaler og ingen, der kan sige, hvilken version der kører hos hvilken kunde.
Fire spørgsmål viser, om I ligner den virksomhed:
- Hvem kan sige, hvilke softwareversioner der kører på de maskiner, I har solgt?
- Hvem beslutter, om en rettelse skal ud til maskiner, der allerede står hos kunderne?
- Hvem har kildekoden til styringen, og står det i en aftale?
- Hvem svarer, når en kunde spørger, hvor længe softwaren bliver opdateret?
Får I forskellige navne eller ingen, mangler softwaren ledelse.
Er maskinen omfattet af CRA?
CRA, Cyber Resilience Act eller på dansk forordningen om cyberrobusthed, gælder både hardware og software. Kommissionens vejledning nævner hardware med indlejret software som en af produkttyperne, og afgørende er, om produktet er beregnet til at udveksle data med andre enheder, direkte eller indirekte. Elektronik alene er ikke nok. Vejledningen er ikke bindende, så tag konklusionen for jeres maskine med en advokat.
Leverer I maskinen erhvervsmæssigt under jeres eget navn eller mærke, er I ifølge vejledningen fabrikant. Det gælder, selv om koden er skrevet af andre. Kører der software hos jer eller i skyen, som maskinen ikke kan udføre en funktion uden, kan det være fjerndatabehandling og dermed en del af produktet. Det gælder egen kode på en lejet platform. En tredjeparts færdige tjeneste, som indgår i løsningen, behandles som en komponent. Jeres egne systemer til løn, HR og kunder er uden for. Forskellen mellem produkt og virksomhedens egen IT er forklaret i Cyber Resilience Act for softwareproducenter. Styringen af de maskiner, I selv producerer med, er et andet emne, se produktionsvirksomheden og IT-ledelsen.
To datoer tæller. Underretningspligten har gældt siden 11. september 2026 og omfatter også produkter, der allerede er solgt. Hovedkravene gælder fra 11. december 2027. De øvrige krav rammer maskiner, der allerede er på markedet på den dato, først når de ændres væsentligt derefter. Hvem der gør hvad, når meldingen skal ud inden for 24 timer, står i 24 timer til ENISA.
Maskinen har også sine egne produktregler. De står uden for denne artikel. Samspillet med CRA bør I tage med den, der står for maskinens CE-mærkning, eller med en advokat.
Supportperioden møder maskinens levetid
Supportperioden er den tid, I retter sårbarheder i produktet. Vejledningen sætter bunden ved fem år, hvis produktet ikke forventes brugt kortere. Forventes det brugt i længere tid, skal perioden følge med, og maskiner står ofte længe hos kunden. Slutdatoen skal oplyses ved købet.
For en maskinbygger er det en ledelsesbeslutning med tre sider. Kan I selv holde softwaren vedlige i hele perioden? Kan de komponenter, I har købt, følge med? Og hvordan når en rettelse ud til en maskine, der står på en fabrik uden jeres adgang? Spørgsmålene er uddybet i supportperiode.
Underleverandørens software er jeres
I skal som fabrikant udvise omhu ved valg af komponenter, også fri software, og udarbejde en softwarekomponentliste, altså en liste over de dele, softwaren består af. Listen skal ikke offentliggøres, men markedsovervågningen kan bede om den. En sårbarhed i en komponent skal indberettes af jer, hvis den er aktivt udnyttet i jeres produkt.
Bed derfor hver leverandør af styring, skærm eller portal om svar på fem ting:
- Hvilke komponenter indeholder leverancen, og kan vi få listen?
- Hvor længe får de opdateringer, og hvad sker der bagefter?
- Hvor hurtigt får vi besked, hvis der findes en sårbarhed?
- Hvem må ændre koden, og har vi adgang til den?
- Hvad sker der med softwaren, hvis samarbejdet slutter?
Svarene hører hjemme i aftalen. Hvordan det kan formuleres, står i de tekniske krav i udviklingsaftalen, og tredjepartsbiblioteker, SBOM og byggepipeline forklarer listen.
Produktansvar og data
Lovforslaget om produktansvar, L 32, er fremsat og mangler vedtagelse. Det foreslår ikrafttræden 9. december 2026. Forslaget regner software for et produkt, også når den er en komponent i et andet produkt. For en maskinbygger betyder det mest, at en person, der kommer til skade, kan rejse krav. Efter forslaget hører tab hos erhvervskunder ikke med, for det er fysiske personer, der kan kræve erstatning, og ejendele, der kun bruges erhvervsmæssigt, er uden for. En defekt, der skyldes manglende sikkerhedsopdateringer inden for jeres kontrol, kan I efter forslaget ikke fritages for. Status og konsekvenser for en konkret maskine er et spørgsmål til advokat. Oversigten står i nyt produktansvar.
Samler maskinen data om sin brug og kan dele dem, er den et forbundet produkt efter dataforordningen, og data skal være tilgængelige for brugeren. For produkter bragt i omsætning efter 12. september 2026 gælder reglerne om direkte adgang, når det er relevant og teknisk muligt. Mikro- og små virksomheder slipper som udgangspunkt for pligten til at dele data, undtagen når de har en større partner- eller tilknyttet virksomhed eller har fået produktet lavet i underentreprise.
Hvem skal lede det?
Ansvaret kan ligge hos en produktchef, en udviklingschef eller en ekstern leder, så længe der er tale om én navngiven person. Personen skal have mandat til fire ting: at beslutte, hvad der frigives, at stille krav til leverandørerne, at fastsætte supportperioden sammen med direktionen og at sige stop, når en leverance ikke kan vedligeholdes.
En teknisk leder på deltid, ofte kaldet fractional CTO, kan dække den del, der handler om ledelse, leverandører, teknologivalg og team. Programmeringen af styringen, maskinsikkerheden og CE-mærkningen ligger hos dem, der har den faglighed i dag. Hvordan rollen afgrænses, står i artiklen om mandatet.
Det skal I lade være med
- At lade softwaren følge med i maskinens stykliste uden ejer · den skal vedligeholdes, længe efter at maskinen er leveret.
- At love en supportperiode, før leverandørerne har svaret · jeres løfte hviler på deres komponenter.
- At antage, at integratoren bærer ansvaret · sælger I under eget navn, står I selv som fabrikant.
Det skal I kræve af den eksterne
- ☐ Et overblik over software, versioner, leverandører og aftaler pr. maskintype.
- ☐ Et forslag til supportperiode med begrundelse.
- ☐ Krav til underleverandørerne, som kan skrives ind i aftalerne.
- ☐ En navngiven plan for underretning, herunder stedfortræder.
- ☐ Klar besked om, hvad der ligger uden for opgaven og hører hos advokat, maskinsikkerhed eller integrator.
Kilder
- Kommissionens vejledning til CRA, C(2026) 5252: afsnit 2 om omfattede produkter og dataforbindelse, afsnit 3 om fabrikant, afsnit 8 om fjerndatabehandling samt supportperiode (nr. 125 til 128). Ikke bindende.
- Kommissionens FAQ om CRA: komponenter og ældre produkter.
- Europa-Kommissionen: CRA reporting: underretningspligten.
- Lovforslag L 32 om produktansvar: forslag, ikke vedtaget.
- Digitaliseringsstyrelsen: Forbundne produkter og relaterede tjenester.
Senest gennemgået: november 2026.
Næste skridt
Læs også: CE-mærke på software · Sådan styrer I en udviklingsleverandør
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
