Cybersikkerhed til maskinproducenter

Fra 2027 er en maskine med styresystem, førerdisplay eller dataforbindelse omfattet af to EU-forordninger. Begge tager udgangspunkt i det samme spørgsmål: Hvilken software er der på denne maskine, version for version, og hvad indeholder den?

1. 11. september 2026Cyber Resilience Acts rapportering af aktivt udnyttede sårbarheder og alvorlige hændelser træder i kraft.
2. 20. januar 2027Maskinforordningen, (EU) 2023/1230, finder anvendelse og erstatter maskindirektivet.
3. 11. december 2027Cyber Resilience Act, (EU) 2024/2847, gælder fuldt ud.

Maskinforordningen

To væsentlige sundheds- og sikkerhedskrav i bilag III handler om cybersikkerhed:

• 1.1.9, beskyttelse mod forvanskning. Tilslutning af en anden enhed til maskinen, direkte eller via fjernadgang, må ikke føre til en farlig situation. Software og data, der er kritiske for, at maskinen opfylder de væsentlige sundheds- og sikkerhedskrav, skal identificeres og beskyttes mod utilsigtet eller forsætlig forvanskning. Maskinen skal identificere den software, der er installeret på den, og som den har brug for for at fungere sikkert, og til enhver tid kunne levere disse oplysninger. Den skal også indsamle bevis for legitime eller illegitime indgreb i softwaren eller dens konfiguration.
• 1.2.1, styresystemers sikkerhed og pålidelighed. Styresystemer skal kunne modstå rimeligt forudsigelige ondsindede forsøg fra tredjeparter, der fører til en farlig situation. Efter 1.2.1(f) skal de føre en sporingslog over indgreb og over de versioner af sikkerhedssoftware, der er uploadet, efter at maskinen blev bragt i omsætning, i fem år efter uploaden.

Cyber Resilience Act

En maskine med dataforbindelse, eller en del af den, der sælges særskilt, er et produkt med digitale elementer. Producenten skal udvise rettidig omhu med de tredjepartskomponenter, den integrerer, udarbejde en SBOM, der som minimum dækker afhængighederne på øverste niveau, håndtere sårbarheder i supportperioden, som er mindst fem år, medmindre produktet forventes at være i brug i kortere tid, og opbevare den tekniske dokumentation i mindst ti år eller i supportperioden, alt efter hvad der er længst.

Ikke automatisk. Cyber Resilience Act giver ingen formodning om overensstemmelse med maskinforordningen. Ifølge betragtning 53 kan opfyldelse af CRA's væsentlige krav lette overholdelsen af maskinforordningens krav om beskyttelse mod forvanskning og om styresystemers sikkerhed og pålidelighed. Der står også, at producenten skal påvise dette, for eksempel ved at anvende harmoniserede standarder efter en risikovurdering, og at begge forordningers procedurer for overensstemmelsesvurdering stadig gælder.

Den harmoniserede standard, der udarbejdes til 1.1.9, er EN 50742, Safety of machinery – Protection against corruption. I november 2026 forelå den som endeligt udkast, FprEN 50742, der dækker 1.1.9 og de tilhørende punkter i 1.2.1, og så længe referencen til en endelig udgave ikke er offentliggjort i Den Europæiske Unions Tidende, giver den ingen formodning om overensstemmelse. Den kombinerer risikovurderingen i EN ISO 12100 med sikkerhedsbegreber fra IEC 62443 og anerkender en konsekvent anvendelse af IEC 62443-4-1, IEC 62443-3-3 og IEC 62443-4-2 som en ligeværdig måde at nå beskyttelsesmålene på. IEC 62443-4-2 fastlægger de tekniske sikkerhedskrav til komponenter i styresystemer, inddelt efter security capability level. I Tyskland omsætter prøvningsprincipperne GS-IFA-M25 fra juli 2026 beskyttelse mod forvanskning til 66 prøvningskriterier med begreberne fra prEN 50742. Et af dem, T46, kræver, at produktet på anmodning kan oplyse sin installerede softwareversion og konfiguration. For at kunne svare på det for hver konfiguration skal man have en registrering af, hvad hver softwareversion indeholder.

Maskinforordningen har sin egen formodning, og den går en anden vej: EU-ordninger for cybersikkerhedscertificering vedtaget under cybersikkerhedsforordningen, forordning (EU) 2019/881. Et certifikat eller en overensstemmelseserklæring under en sådan ordning giver formodning om overensstemmelse med 1.1.9 og 1.2.1, i det omfang det dækker disse krav.

Én risikovurdering og ét sæt dokumentation kan altså tjene begge forordninger, men du påviser overensstemmelse med hver af dem. Har din maskine en dataforbindelse, så planlæg for begge. Dokumentationen for softwaren, altså SBOM'er, sårbarhedsregistreringer og opdateringshistorikken, er den del, de har til fælles.

I januar 2026 bad maskinindustriens brancheorganisationer om at udskyde 1.1.9 og 1.2.1(f), og i marts 2026 om at lade dem gælde fra CRA's dato, 11. december 2027. Det er en anmodning, ikke lov: I november 2026 var der ikke vedtaget nogen udskydelse. Datoerne på denne side er datoerne i forordningerne.

• Entreprenør-, materialehåndterings-, mine- og industrimaskiner er omfattet af maskinforordningen og også af CRA, når maskinen eller dens dele har en dataforbindelse.
• Landbrugs- og skovbrugstraktorer, der er omfattet af forordning (EU) nr. 167/2013, er undtaget fra maskinforordningen, bortset fra maskiner monteret på dem. CRA's liste over undtagelser nævner ikke den forordning, så en forbundet traktor kan være omfattet af CRA.
• Vejkøretøjer, der er typegodkendt efter forordning (EU) 2019/2144, er undtaget fra CRA.
• Komponenter, der sælges særskilt. CRA gælder også for software- og hardwarekomponenter, der bringes i omsætning særskilt. En leverandør, der sælger en ECU eller en telematikenhed særskilt, er selv producent under CRA. Når enheden kun bygges ind i maskinen, bærer maskinproducenten forpligtelsen for hele maskinen og skal udvise rettidig omhu med leverandørens komponent.

Dette er generel information, ikke juridisk rådgivning. Kontrollér klassificeringen af dit eget produkt.

I en og samme maskine kommer softwaren fra forskellige steder, og kun det team, der bygger et stykke software, kan pålideligt sige, hvad der er i det. Som vi hører fra maskinproducenter, indeholder ECU'er uden operativsystem kun lidt open source, mens software til Linux, Android og Windows indeholder meget.

Små mængder, stor variation. En maskinproducent kan have hundredvis af platforme på markedet, sælge en håndfuld enheder af hver om året og konfigurere mange maskiner efter ordre. Hver konfiguration er et særskilt sæt software, så en SBOM for hvert build betyder mere end en SBOM for hver produktlinje.

Lang levetid. Maskiner er i drift i ti år eller mere, mens leverandører skiftes ud eller går konkurs. Registreringen af, hvad der gik ind i en softwareversion, skal laves, når den bygges, for den kan ikke rekonstrueres år senere.

Leverandørsoftware dominerer, og leverandørernes SBOM'er er ofte mangelfulde. Vi hører om leverandør-SBOM'er med manglende komponenter, uden package URLs eller CPE'er, uden licenser og uden hashes, nogle skrevet i hånden og afvist ved skemavalidering. Binæranalyse af en flashet ECU er en nødløsning: Den gætter på indholdet i stedet for at registrere det.

Risikoen ligger i de forbundne lag. Meget ECU-logik genereres ud fra modeller og indeholder kun lidt open source. Open source-koden og netværkseksponeringen samler sig i Linux-, forbindelses- og app-lagene, så læg din indsats der først.

Et illustrativt eksempel: softwarestakken i en fiktiv hjullæsserplatform, fra skyen ned til ECU'erne.

1. Cloud-backend og ledsagerappEgen udvikling. Mest open source og eksponeret mod netværk. Cyber Resilience Act.
2. Telematik-gatewayEmbedded Linux, mest open source, forbundet til mobilnettet. Cyber Resilience Act og 1.1.9 for fjernforbindelsen.
3. FørerdisplayEmbedded Linux-image med et UI-framework, mest open source, forbundet til maskinens bus og til serviceværktøjer. Cyber Resilience Act og 1.1.9.
4. MaskinstyringEgen applikation på en leverandørplatform, sikkerhedsrelevant. 1.1.9 og 1.2.1 samt Cyber Resilience Act, hvor den kan nås via en forbindelse.
5. ECU'er til hydraulik, styring og motorLeverandørfirmware, proprietær og modelgenereret, kun lidt open source, sikkerhedsrelevant. 1.1.9 og 1.2.1; Cyber Resilience Act via maskinen.

Open source-koden og netværkseksponeringen ligger i de tre øverste lag, og det er også der, dine egne build-pipelines som regel er. Start der.

Maskinproducenter stiller nu SBOM-krav til den software, de køber, for eksempel package URLs eller CPE'er, licenser, hashes og et format, der består validering, og sender filer, der ikke lever op til kravene, tilbage. Hvis du bygger på GitHub Actions, laver CRACI SBOM'en ud fra selve buildet, så den viser, hvad der faktisk gik ind i releasen, inklusive de komponenter, som ingen lockfile nævner, med en package URL og erklæret licens for hver komponent. Tjek eksporten mod den fulde liste over felter, din kunde beder om. Læs mere om at besvare kunders SBOM-forespørgsler.