EU:s maskinförordning från 20 januari 2027: vad den kräver av programvaran i dina maskiner

automatiserad produktionscell med en robotarm, styrmoduler och en operatörsskärm

Den 20 januari 2027 ersätts maskindirektivet av förordning (EU) 2023/1230, maskinförordningen. Det mesta kommer att kännas bekant för den som bygger CE-märkta maskiner. En del gör det inte. För första gången lägger maskinlagstiftningen skyldigheter direkt på programvara: maskinen ska ange vilken programvara den behöver för att fungera säkert, märka när den programvaran eller dess konfiguration ändras, stå emot korrumpering och spara spår av uppdateringar av säkerhetsprogramvaran i fem år.

Texten vänder sig till tekniska chefer och chefer för styrsystem hos maskintillverkare. Levererar du maskiner till EU efter det datumet hamnar de här kraven i dina PLC-program, ditt HMI, din fjärråtkomst och din bakomliggande plattform för uppdateringar.

Vad lagen faktiskt säger

Europeiska kommissionen skriver att förordningen ”ska tillämpas obligatoriskt från och med den 20 januari 2027” och att den ”innehåller bestämmelser om cybersäkerhet för programvarudata och säkerhetsstyrsystem som är relevanta för efterlevnaden”. Texten som publicerades 2023 angav 14 januari; en rättelse flyttade datumet.

Skyldigheterna för programvara finns i två väsentliga hälso- och säkerhetskrav i bilaga III till förordningen.

Avsnitt 1.1.9, skydd mot korrumpering. I korthet:

Att ansluta en annan enhet till maskinen, direkt eller på distans, får inte leda till en farlig situation.
Programvara och data som är avgörande för att säkerhetskraven ska uppfyllas ”ska identifieras som sådana” och skyddas mot oavsiktlig eller avsiktlig korrumpering.
Maskinvara som överför signaler eller data som ger åtkomst till den programvaran (tänk på en programmeringsport eller ett nätverksgränssnitt in i säkerhetsstyrningen) ska också skyddas, och maskinen ska samla in bevis på ingrepp i den.
Maskinen ”ska identifiera den programvara som är installerad i den och som är nödvändig för att den ska fungera säkert, och ska alltid kunna tillhandahålla den informationen i en lättillgänglig form”.
Maskinen ”ska samla in bevis på legitima eller illegitima ingrepp i programvaran eller ändringar av den programvara som är installerad i maskinen eller den relaterade produkten, eller av dess konfiguration”.

Avsnitt 1.2.1, styrsystemens säkerhet och tillförlitlighet. Styrsystem ska tåla ”rimligen förutsebara illasinnade försök från tredje part som leder till en farlig situation”. Led f lägger till loggningsplikten: en spårningslogg över de data som genereras vid ett ingrepp, och över de versioner av säkerhetsprogramvara som laddats upp efter att maskinen släppts ut på marknaden, ”ska vara aktiverad i fem år efter en sådan uppladdning”. Loggen finns för att visa överensstämmelse när en nationell myndighet lämnar en motiverad begäran, och för inget annat.

Också på listan: den tekniska dokumentationen ska kunna ta fram ”källkoden eller programmeringslogiken för den säkerhetsrelaterade programvaran” om en myndighet begär det (bilaga IV).

Vilka maskiner som omfattas

Reglerna gäller maskiner som släpps ut på marknaden från och med den 20 januari 2027. Maskiner som släppts ut på marknaden enligt det gamla direktivet före det datumet får fortfarande säljas vidare (artikel 52), och den maskinpark som redan finns ute nås inte av de nya programvarureglerna.

Haken är vad ”släppa ut på marknaden” betyder. Kommissionens Blå guide säger att begreppet ”avser varje enskild produkt, inte en produkttyp”. Varje enhet som lämnar din fabrik till en kund i EU från och med den 20 januari 2027 måste uppfylla de nya kraven, programvaran inräknad. En maskinfamilj som levereras löpande behöver ha sin styrprogramvara klar före den första enheten 2027, inte vid nästa modellbyte.

Senare uppdateringar kräver också eftertanke. En ändring som görs ”på fysisk eller digital väg”, som tillverkaren inte har förutsett och som skapar en ny fara eller ökar en risk, kan vara en väsentlig ändring. Skäl 32 säger att riskbedömningen bör omfatta programvaruuppdateringar som förutsetts när maskinen släpps ut på marknaden, så beskriv din uppdateringsväg där redan nu.

Vad det innebär i maskinens olika lager

Säkerhetsstyrning och PLC

Bestäm vad som är säkerhetsrelevant. Det är oftast säkerhetsprogrammet, men det kan också omfatta vanlig PLC-kod som matar en säkerhetsfunktion, säkerhetsparametrar i drivsystem och konfigurationen av laserskannrar eller ljusridåer. Skriv ner det per maskinfamilj; allt annat bygger på det.
Fastställ en referens och jämför. Registrera för varje släppt konfiguration en kontrollsumma eller signatur för varje säkerhetsrelevant del. Vid uppstart och med jämna mellanrum jämför maskinen det som körs med referensen och registrerar varje avvikelse. Det fångar ingrepp som har gått förbi din behörighetskontroll, som en bärbar dator som kopplats direkt till styrningen.
Lås programmeringsåtkomsten. Lösenord på säkerhetsprogrammet, oanvända portar och tjänster avstängda, och programmeringsåtkomst bara via en väg som autentiserar personen och loggar vad den gjorde.

HMI

En skärm för programvaruidentifiering som listar den säkerhetsrelevanta programvaran med versioner och kontrollsummor. Läs värdena direkt från enheterna. En sida som skrevs in vid releasen glider ifrån verkligheten, och kravet säger ”alltid”.
Parameterskärmar. Punkt 1.2.1 d utesluter ändringar av inställningar eller regler som kan leda till farliga situationer. Säkerhetsrelaterade parametrar hör hemma bakom behörighetsnivåer, med gränser som upprätthålls i styrningen och inte bara i HMI:t, och varje ändring registreras med vem, när, det gamla värdet och det nya.

Fjärråtkomst

Avsnitt 1.1.9 nämner uttryckligen enheter på distans. I praktiken:

Säkerhetsfunktionerna stannar lokalt. En fjärrsession kan läsa, diagnostisera och förbereda en ändring. Den kan inte åsidosätta ett stopp, ett skydd eller en aktiveringsanordning.
Sessioner autentiseras per person, inte via ett delat servicekonto, och kunden kan se när en session är öppen.
Varje sessionsstart, sessionsslut och ändring hamnar i samma bevislogg som lokala ingrepp.

Bakomliggande plattform och uppdateringsflöde

Levererar du uppdateringar efter leverans ingår din uppdateringsserver i arbetet. För varje serienummer behöver du veta vilken version av säkerhetsprogramvaran som laddades upp, när och av vem. Signera uppdateringarna och låt maskinen kontrollera signaturen innan den installerar något.

Själva spårningsloggen

Förordningen säger inte var loggen ska finnas. Vår bedömning: den kopia som räknas ligger på maskinen, eftersom många kunder inte tillåter en permanent uppkoppling. En spegling i molnet är användbar, men den kan inte vara den enda kopian.

Volymen är liten: ingrepp och uppladdningar av säkerhetsprogramvara, inte processdata. Fem år ryms i lokal lagring om du dimensionerar för det med avsikt. Skydda loggen mot radering och se till att den överlever ett byte av styrning. Om posterna namnger en tekniker är det personuppgifter hos kunden: logga det som kravet behöver och inget mer.

Vad din leverantör av styrsystem ger dig, och vad den inte ger

Din styrsystemsplattform kommer att stå för en del av detta. Innan du bygger något, kontrollera vad den erbjuder: en signatur eller kontrollsumma över säkerhetsprogrammet, lösenordsskydd, användarhantering, en ändringslogg, avläsning av versioner. Använd det som finns.

Det är byggstenar. Leverantören vet inte vilka av dina drivsystem och skannrar som är säkerhetsrelevanta, ser inte din fjärrgateway eller uppdateringsserver och kan inte avgöra hur bevisen ska överleva fem år och ett byte av styrning. Att konfigurera de funktionerna, koppla ihop dem över hela maskinen och dokumentera resultatet är maskintillverkarens jobb, och det är maskintillverkaren som undertecknar försäkran om överensstämmelse.

Hur detta förhåller sig till cyberresiliensförordningen

Cyberresiliensförordningen (Cyber Resilience Act) följer sin egen kalender. Dess rapporteringsskyldigheter har gällt sedan den 11 september 2026, och dess fullständiga krav gäller från den 11 december 2027. Maskinförordningen landar mellan de två.

CRA erkänner överlappningen. Skäl 53 i förordning (EU) 2024/2847 säger att tillverkare av maskiner som också är produkter med digitala element bör uppfylla båda, och att efterlevnad av CRA ”skulle kunna underlätta” efterlevnaden av avsnitten 1.1.9 och 1.2.1. Det är tillverkaren som måste visa den synergin. Bilaga I till CRA kräver skydd av integriteten hos ”kommandon, program och konfiguration” och rapportering om korrumpering, vilket ligger nära det som 1.1.9 kräver.

En skillnad spelar roll för hur du utformar loggen. CRA:s krav på att registrera och övervaka intern aktivitet kommer ”med en möjlighet för användaren att välja bort”. Maskinförordningens spårningslogg ska vara aktiverad i fem år. Bygg gärna en gemensam loggningsmekanism, men låt inte CRA:s bortval stänga av maskinloggen.

Bygg för maskinförordningen nu, eftersom den kommer först, och utforma lösningen så att samma bevislager, signering och uppdateringsregister tjänar CRA i december 2027.

Standarder och det misslyckade uppskovet

Räkna inte med att en harmoniserad standard som täcker de här kraven har offentliggjorts senast den 20 januari 2027. Kommissionens sida om harmoniserade standarder, uppdaterad i september 2026, säger att den första listan enligt maskinförordningen håller på att tas fram. Den kommer att föra över de flesta standarder som hänvisats till enligt direktivet och förtydliga dem där de ”ännu inte fullt ut behandlar” de nya kraven, och den ”kan väntas före årets slut”.

I januari 2026 begärde CEMA, CECE, CECIMO, EGMF och FEM i en gemensam ståndpunkt från branschen att 1.1.9 och 1.2.1 f skulle skjutas upp till den 11 december 2027, i linje med CRA. De uppskattade kostnaderna för efterlevnad till ”mer än 1 miljon euro per plattformsarkitektur” och menade att de väntade standarderna förblir mycket allmänt hållna när det gäller dataloggen i 1.2.1 f.

Den begäran antogs inte. Maskinförordningen ändrades i juli 2026 genom förordning (EU) 2026/1744, men den ändringen gäller AI-system med hög risk i maskiner och lämnar tillämpningsdatumet orört. Planera för 20 januari 2027.

Det kan alltså hända att ingen standard ger presumtion om överensstämmelse för de här två kraven från första dagen. Din tekniska dokumentation måste då beskriva den lösning du har tillämpat för vart och ett av dem (bilaga IV). Skriv det medan du bygger, inte efteråt. För maskiner som förtecknas i bilaga I del B finns ytterligare ett steg: egenbedömning är bara möjlig om harmoniserade standarder eller gemensamma specifikationer täcker alla relevanta krav; annars blir ett anmält organ inblandat (artikel 25). Maskiner som inte förtecknas i bilaga I bedöms av tillverkaren själv i båda fallen.

En plan på 15 veckor

Från måndagen den 5 oktober 2026 till sista dagen är det drygt 15 veckor, med helgerna mitt i. Det är snävt men går att genomföra om du prioriterar efter leveransdatum: familjer med EU-enheter som skickas i januari kommer först.

Vecka 1 och 2 (5 till 16 oktober): avgränsning. Lista varje maskinfamilj som kommer att leverera EU-enheter efter den 20 januari 2027. Lista för var och en den säkerhetsrelevanta programvaran och datan: säkerhetsprogram, vanlig kod som är kritisk för efterlevnaden, säkerhetsparametrar i drivsystem och sensorer, HMI, firmware och fjärrgateway. Utse en ansvarig per familj.
Vecka 3 och 4 (19 till 30 oktober): riskbedömning och luckor. Uppdatera riskbedömningen för anslutningar, fjärråtkomst, illasinnade försök och uppdateringsvägen. Kontrollera vad din styrsystemsplattform erbjuder och vad som är påslaget.
Vecka 5 till 9 (2 november till 4 december): bygg. Skärm för programvaruidentifiering, jämförelse mot referens, behörighetskontroll för programmerings- och fjärråtkomst, spårningsloggen med kapacitet för fem år, signerade uppdateringar och register per serienummer i den bakomliggande plattformen.
Vecka 10 och 11 (7 till 18 december): testa som en tekniker och en angripare skulle göra. Ändra en säkerhetsparameter direkt med leverantörens verktyg och bekräfta att maskinen registrerar det. Byt en styrning och kontrollera att loggen överlever. Bryt strömmen mitt i en uppdatering.
Vecka 12 och 13 (21 december till 1 januari): helger. Planera inget utvecklingsarbete; låt ett långtidstest fylla loggen mot dess femårsstorlek.
Vecka 14 och 15 (4 till 15 januari): dokumentation och release. Avsnitt i den tekniska dokumentationen för 1.1.9 och 1.2.1, en bruksanvisning som förklarar hur kunden läser programvaruidentifieringen och vad fjärråtkomsten kan och inte kan göra, och ett produktionssteg som laddar in den släppta referensen och registrerar den per serienummer.

Behöver fler plattformsarkitekturer det här än vad som ryms i det fönstret, säg till säljavdelningen nu: en enhet som inte är klar får inte lagligen släppas ut på EU-marknaden.

Vem detta inte gäller

Maskiner som släppts ut på marknaden före den 20 januari 2027 nås inte av de här programvarureglerna, om inte någon senare ändrar dem väsentligt. Köper du maskiner i stället för att bygga dem ligger skyldigheten hos din leverantör; din del är att kräva programvaruidentifiering och tillgång till loggen i dina specifikationer.

Var du får hjälp

Vi är ett mjukvaruföretag, inte ett anmält organ eller en advokatbyrå. Vi bygger och ändrar den programvara som de här kraven landar i: HMI och applikationer i den bakomliggande plattformen, gateways för fjärråtkomst, uppdateringsflöden och bevisloggning, i samarbete med de styrsystemsingenjörer som äger säkerhetsprogrammet. Äldre plattformar med år av ackumulerad kod är det svåraste fallet, och det är där vårt arbete med underhåll av äldre system brukar börja. CRA-sidan går vi igenom i vår guide till cyberresiliensförordningen. Har ditt team planen men inte händerna för att bli klart till januari, skriv till office@c9group.dev.