EU's maskinforordning fra 20. januar 2027: hvad den kræver af jeres maskinsoftware

Automatiseret produktionscelle med en robotarm, styremoduler og en operatørskærm

Den 20. januar 2027 erstattes maskindirektivet af forordning (EU) 2023/1230, maskinforordningen. Det meste af den vil virke bekendt for alle, der bygger CE-mærkede maskiner. Én del vil ikke. For første gang lægger maskinlovgivningen pligter direkte på software: maskinen skal oplyse, hvilken software den har brug for til sikker drift, opdage, når den software eller dens konfiguration ændres, modstå forvanskning og bevare et spor af opdateringer af sikkerhedssoftware i fem år.

Artiklen er skrevet til udviklings- og styringschefer hos maskinbyggere. Leverer I maskiner til EU efter den dato, lander kravene i jeres PLC-programmer, jeres HMI, jeres fjernadgang og jeres backend til opdateringer.

Hvad loven faktisk siger

Europa-Kommissionen skriver, at forordningen »finder obligatorisk anvendelse fra 20. januar 2027«, og at den »indarbejder bestemmelser om cybersikkerhed for compliancerelevante softwaredata og sikkerhedsstyresystemer«. Teksten, der blev offentliggjort i 2023, sagde 14. januar; en berigtigelse flyttede datoen.

Pligterne for software står i to væsentlige sikkerheds- og sundhedskrav i bilag III til forordningen.

Punkt 1.1.9, beskyttelse mod forvanskning. Kort fortalt:

Tilslutning af en anden anordning til maskinen, direkte eller via fjernforbindelse, må ikke føre til en farlig situation.
Software og data, der er kritiske for overholdelsen af sikkerhedskravene, »skal identificeres som sådan« og beskyttes mod tilsigtet eller utilsigtet forvanskning.
Hardware, der transmitterer signaler eller data, som giver adgang til den software (tænk på en programmeringsport eller en netværksgrænseflade ind til sikkerhedscontrolleren), skal også beskyttes, og maskinen skal indsamle dokumentation for indtrængen i den.
Maskinen »skal identificere softwaren, der er installeret i dem, og som er nødvendig for en sikker drift, og de skal til enhver tid være i stand til at forelægge disse oplysninger i et lettilgængeligt format«.
Maskinen »skal indsamle dokumentation for legitim og illegitim indtrængen i software, eller en ændring i den i maskinen eller det relaterede produkt installerede software eller dens konfiguration«.

Punkt 1.2.1, styresystemernes sikkerhed og pålidelighed. Styresystemer skal kunne modstå »tredjeparters ondsindede handlinger, som med rimelighed kan forudses, og som fører til en farlig situation«. Litra f) tilføjer logningspligten: en sporingslog for de data, der genereres i forbindelse med et indgreb, og for de versioner af sikkerhedssoftware, der er uploadet, efter at maskinen er bragt i omsætning, »er tilgængelig fem år efter en sådan upload af software«. Loggen findes for at påvise overensstemmelse, når en national myndighed fremsætter en begrundet anmodning, og til intet andet.

Også på listen: den tekniske dokumentation skal kunne fremlægge »kildekoden eller den logiske programmering af sikkerhedsrelateret software«, hvis en myndighed beder om det (bilag IV).

Hvilke maskiner der er omfattet

Reglerne gælder for maskiner, der bringes i omsætning fra 20. januar 2027. Maskiner, der er bragt i omsætning efter det gamle direktiv før den dato, kan stadig sælges videre (artikel 52), og den maskinpark, der allerede står ude hos kunderne, berøres ikke af de nye softwareregler.

Hagen er, hvad »bragt i omsætning« betyder. Kommissionens Blå Vejledning (Blue Guide) siger, at begrebet »henviser til hvert enkelt produkt, ikke til en produkttype«. Hver enhed, der forlader jeres fabrik til en EU-kunde fra 20. januar 2027, skal opfylde de nye krav, software inklusive. En produktfamilie, der leveres løbende, skal have sin styringssoftware klar før den første enhed i 2027, ikke ved næste modelskifte.

Senere opdateringer kræver også omtanke. En ændring, der foretages fysisk eller digitalt, som fabrikanten ikke har forudset, og som skaber en ny fare eller øger en risiko, kan være en væsentlig ændring. Betragtning 32 siger, at risikovurderingen bør dække softwareopdateringer, der er forudset, når maskinen bringes i omsætning, så beskriv jeres opdateringsvej dér nu.

Hvad det betyder i hvert lag af maskinen

Sikkerhedscontroller og PLC

Beslut, hvad der er sikkerhedsrelevant. Som regel er det sikkerhedsprogrammet, men det kan omfatte almindelig PLC-kode, der fodrer en sikkerhedsfunktion, sikkerhedsparametre i drev og konfigurationen af laserscannere eller lysgardiner. Skriv det ned pr. maskinfamilie; alt andet afhænger af det.
Baseline og sammenligning. Registrér for hver frigivet konfiguration en checksum eller signatur for hvert sikkerhedsrelevant element. Ved opstart og med mellemrum sammenligner maskinen det, der kører, med baselinen og registrerer enhver forskel. Det fanger det indgreb, der gik uden om jeres adgangskontrol, for eksempel en bærbar sat direkte i controlleren.
Lås ingeniøradgangen ned. Adgangskoder på sikkerhedsprogrammet, ubrugte porte og tjenester slået fra og ingeniøradgang kun via en vej, der autentificerer personen og logger, hvad vedkommende gjorde.

HMI

En skærm med softwareidentifikation, der viser den sikkerhedsrelevante software med versioner og checksummer. Læs værdierne direkte fra enhederne. En side, der blev tastet ind ved frigivelsen, glider væk fra virkeligheden, og kravet siger »til enhver tid«.
Parameterskærme. Punkt 1.2.1, litra d), udelukker ændringer af indstillinger eller regler, der kan føre til farlige situationer. Sikkerhedsrelaterede parametre hører hjemme bag adgangsniveauer, med grænser, der håndhæves i controlleren og ikke kun i HMI'en, og hver ændring registreres med hvem, hvornår, den gamle værdi og den nye.

Fjernadgang

Punkt 1.1.9 nævner udtrykkeligt fjernanordninger. I praksis:

Sikkerhedsfunktioner forbliver lokale. En fjernsession kan læse, diagnosticere og forberede en ændring. Den kan ikke tilsidesætte et stop, en afskærmning eller en aktiveringsanordning.
Sessioner autentificeres pr. person, ikke via en delt servicekonto, og kunden kan se, når en session er åben.
Hver sessions start, afslutning og ændring går ind i den samme dokumentationslog som lokale indgreb.

Backend og opdateringspipeline

Leverer I opdateringer efter levering, er jeres opdateringsserver en del af arbejdet. For hvert serienummer skal I vide, hvilken version af sikkerhedssoftwaren der blev uploadet, hvornår og af hvem. Signér opdateringerne, og lad maskinen kontrollere signaturen, før den installerer noget.

Selve sporingsloggen

Forordningen siger ikke, hvor loggen skal ligge. Vores vurdering: den kopi, der tæller, ligger på maskinen, fordi mange kunder ikke vil tillade en permanent forbindelse. Et spejl i skyen er nyttigt, men det kan ikke være den eneste kopi.

Mængden er lille: indgreb og uploads af sikkerhedssoftware, ikke procesdata. Fem år kan være i lokal lagring, hvis I dimensionerer den bevidst. Beskyt den mod sletning, og sørg for, at den overlever et skift af controller. Nævner posterne en tekniker ved navn, er det personoplysninger hos kunden: log det, kravet kræver, og intet mere.

Hvad jeres controllerleverandør giver jer, og hvad den ikke giver

Jeres controllerplatform vil levere en del af dette. Før I bygger noget, så tjek, hvad den tilbyder: en signatur eller checksum over sikkerhedsprogrammet, adgangskodebeskyttelse, brugerstyring, en ændringslog, udlæsning af version. Brug det, der er.

Det er byggeklodser. Leverandøren ved ikke, hvilke af jeres drev og scannere der er sikkerhedsrelevante, kan ikke se jeres fjern-gateway eller opdateringsserver og kan ikke beslutte, hvordan dokumentationen overlever fem år og et skift af controller. At konfigurere de funktioner, forbinde dem på tværs af hele maskinen og dokumentere resultatet er maskinbyggerens opgave, og det er maskinbyggeren, der underskriver overensstemmelseserklæringen.

Hvordan det hænger sammen med Cyber Resilience Act

Cyber Resilience Act (forordningen om cyberrobusthed) følger sin egen kalender. Dens indberetningspligter har gældt siden 11. september 2026, og dens fulde krav gælder fra 11. december 2027. Maskinforordningen lander mellem de to.

CRA anerkender overlappet. Betragtning 53 i forordning (EU) 2024/2847 siger, at fabrikanter af maskiner, der også er produkter med digitale elementer, bør opfylde begge, og at overholdelse af CRA kan »lette overholdelsen« af punkt 1.1.9 og 1.2.1. Det er fabrikanten, der skal påvise den synergi. CRA's bilag I kræver beskyttelse af integriteten af »kommandoer, programmer og konfigurationer« og melding om korruption, hvilket ligger tæt på det, 1.1.9 kræver.

Én forskel betyder noget for designet af jeres log. CRA's krav om at registrere og overvåge interne aktiviteter kommer »med en fravalgsmekanisme for brugeren«. Maskinforordningens sporingslog skal forblive tilgængelig i fem år. Byg gerne én logningsmekanisme, men lad ikke CRA's fravalg slå maskinloggen fra.

Byg til maskinforordningen nu, fordi den kommer først, og design det, så det samme dokumentationslager, den samme signering og de samme opdateringsregistreringer tjener CRA i december 2027.

Standarder og den udskydelse, der ikke kom

Regn ikke med, at en harmoniseret standard, der dækker disse krav, er offentliggjort senest 20. januar 2027. Kommissionens side om harmoniserede standarder, som opdateret i september 2026, siger, at den første liste under maskinforordningen er under udarbejdelse. Den vil føre de fleste standarder, der er offentliggjort under direktivet, videre og præcisere dem, hvor de »endnu ikke fuldt ud dækker« de nye krav, og den »kan forventes inden udgangen af året«.

I januar 2026 bad CEMA, CECE, CECIMO, EGMF og FEM i en fælles holdning fra branchen om, at 1.1.9 og 1.2.1, litra f), blev udskudt til 11. december 2027, i takt med CRA. De anslog omkostningerne til overholdelse til »mere end 1 million euro pr. platformsarkitektur« og sagde, at de forventede standarder forbliver meget generelle om dataloggen i 1.2.1, litra f).

Den anmodning blev ikke imødekommet. Maskinforordningen blev ændret i juli 2026 ved forordning (EU) 2026/1744, men den ændring handler om højrisiko-AI-systemer i maskiner og lader anvendelsesdatoen være. Planlæg efter 20. januar 2027.

I har altså måske ingen standard, der giver formodning om overensstemmelse for de to krav på dag ét. Jeres tekniske dossier skal så beskrive den løsning, I har anvendt for hvert af dem (bilag IV). Skriv det, mens I bygger, ikke bagefter. For maskiner, der er opført i bilag I, del B, er der et trin mere: egenvurdering er kun mulig, hvis harmoniserede standarder eller fælles specifikationer dækker alle de relevante krav; ellers inddrages et bemyndiget organ (artikel 25). Maskiner, der ikke er opført i bilag I, egenvurderer under alle omstændigheder.

En plan på 15 uger

Fra mandag den 5. oktober 2026 til fristen er der lidt over 15 uger, med juleferien i midten. Det er stramt, men overkommeligt, hvis I prioriterer efter leveringsdato: familier med EU-enheder, der sendes i januar, kommer først.

Uge 1 og 2 (5. til 16. oktober): afgrænsning. List hver maskinfamilie, der vil levere EU-enheder efter 20. januar 2027. List for hver den sikkerhedsrelevante software og de sikkerhedsrelevante data: sikkerhedsprogram, compliancekritisk standardkode, sikkerhedsparametre i drev og sensorer, HMI, firmware, fjern-gateway. Udpeg én ejer pr. familie.
Uge 3 og 4 (19. til 30. oktober): risikovurdering og huller. Opdatér risikovurderingen for forbindelser, fjernadgang, ondsindede handlinger og opdateringsvejen. Tjek, hvad jeres controllerplatform leverer, og hvad der er slået til.
Uge 5 til 9 (2. november til 4. december): udvikling. Skærm med softwareidentifikation, sammenligning med baseline, adgangskontrol på ingeniør- og fjernadgang, sporingsloggen med kapacitet til fem år, signerede opdateringer og registreringer pr. serienummer i backend.
Uge 10 og 11 (7. til 18. december): test det, som en tekniker og en angriber ville. Ændr en sikkerhedsparameter direkte med leverandørens værktøj, og bekræft, at maskinen registrerer det. Skift en controller, og tjek, at loggen overlever. Afbryd strømmen under en opdatering.
Uge 12 og 13 (21. december til 1. januar): ferie. Planlæg intet udviklingsarbejde; lad en langtidstest fylde loggen op mod dens femårsstørrelse.
Uge 14 og 15 (4. til 15. januar): dokumentation og frigivelse. Afsnit i det tekniske dossier om 1.1.9 og 1.2.1, en brugsanvisning, der forklarer, hvordan kunden læser softwareidentifikationen, og hvad fjernadgang kan og ikke kan, og et produktionstrin, der indlæser den frigivne baseline og registrerer den pr. serienummer.

Har flere platformsarkitekturer brug for dette, end der er plads til i det vindue, så sig det til salgsafdelingen nu: en enhed, der ikke er klar, kan ikke lovligt bringes i omsætning på EU-markedet.

Hvem det her ikke er til

Maskiner, der er bragt i omsætning før 20. januar 2027, berøres ikke af disse softwareregler, medmindre nogen senere foretager en væsentlig ændring af dem. Køber I maskiner i stedet for at bygge dem, ligger pligten hos jeres leverandør; jeres del er at kræve softwareidentifikation og adgang til loggen i jeres kravspecifikationer.

Hvor I kan få hjælp

Vi er et softwarefirma, ikke et bemyndiget organ eller et advokatfirma. Vi bygger og ændrer den software, kravene lander i: HMI- og backendapplikationer, gateways til fjernadgang, opdateringspipelines og logning af dokumentation, i samarbejde med de styringsingeniører, der ejer sikkerhedsprogrammet. Ældre platforme med mange års ophobet kode er det sværeste tilfælde, og det er som regel dér, vores arbejde med vedligeholdelse af ældre systemer starter, mens CRA-siden er dækket i vores guide til Cyber Resilience Act. Har jeres team planen, men ikke hænderne til at blive færdig inden januar, så skriv til office@c9group.dev.