EUs maskinforordning fra 20. januar 2027: hva den krever av maskinprogramvaren din

Automatisert produksjonscelle med robotarm, styringsmoduler og operatørskjerm

Den 20. januar 2027 erstattes maskindirektivet av forordning (EU) 2023/1230, maskinforordningen. Det meste vil virke kjent for alle som bygger CE-merkede maskiner. Én del vil ikke det. For første gang legger maskinregelverket plikter direkte på programvare: maskinen må oppgi hvilken programvare den trenger for å fungere sikkert, merke når den programvaren eller konfigurasjonen endres, motstå korrumpering og ta vare på et spor av oppdateringer av sikkerhetsprogramvaren i fem år.

Dette er skrevet for ledere for utvikling og styringssystemer hos maskinprodusenter. Sender du maskiner inn i EU etter den datoen, havner disse kravene i PLS-programmene dine, i HMI-et, i fjerntilgangen og i backenden for oppdateringer.

Hva loven faktisk sier

Europakommisjonen skriver at forordningen «gjelder obligatorisk fra 20. januar 2027», og at den «integrerer bestemmelser om cybersikkerhet for samsvarsrelevante programvaredata og sikkerhetsstyringssystemer». Teksten som ble publisert i 2023, sa 14. januar; en rettelse flyttet datoen.

Pliktene for programvare ligger i to grunnleggende helse- og sikkerhetskrav i vedlegg III til forordningen.

Punkt 1.1.9, beskyttelse mot korrumpering. Kort fortalt:

Å koble en annen enhet til maskinen, direkte eller via fjerntilgang, må ikke føre til en farlig situasjon.
Programvare og data som er kritiske for å oppfylle sikkerhetskravene, «skal identifiseres som sådan» og beskyttes mot utilsiktet eller forsettlig korrumpering.
Maskinvare som overfører signaler eller data som gir tilgang til den programvaren (tenk på en programmeringsport eller et nettverksgrensesnitt inn til sikkerhetsstyringen), må også beskyttes, og maskinen må samle bevis på inngrep i den.
Maskinen «skal identifisere programvaren som er installert på den og som er nødvendig for at den skal fungere sikkert, og skal til enhver tid kunne gi den informasjonen i en lett tilgjengelig form».
Maskinen «skal samle bevis på et legitimt eller illegitimt inngrep i programvaren eller en endring av programvaren som er installert på maskinen eller det tilhørende produktet, eller av konfigurasjonen».

Punkt 1.2.1, styringssystemers sikkerhet og pålitelighet. Styringssystemer må tåle «rimelig forutsigbare ondsinnede forsøk fra tredjeparter som fører til en farlig situasjon». Bokstav f legger til loggføringsplikten: en sporingslogg over dataene som genereres av et inngrep, og over versjonene av sikkerhetsprogramvare som er lastet opp etter at maskinen ble brakt i omsetning, «er aktivert i fem år etter en slik opplasting». Loggen finnes for å vise samsvar når en nasjonal myndighet kommer med en begrunnet anmodning, og for ingenting annet.

Også på listen: den tekniske dokumentasjonen må kunne fremlegge «kildekoden eller programmeringslogikken til den sikkerhetsrelaterte programvaren» hvis en myndighet ber om det (vedlegg IV).

Hvilke maskiner som omfattes

Reglene gjelder maskiner som bringes i omsetning fra 20. januar 2027. Maskiner som er brakt i omsetning under det gamle direktivet før den datoen, kan fortsatt selges videre (artikkel 52), og maskinparken som allerede står ute hos kundene, nås ikke av de nye programvarereglene.

Haken er hva «bringe i omsetning» betyr. Kommisjonens Blue Guide sier at begrepet «gjelder hvert enkelt produkt, ikke en produkttype». Hver enhet som forlater fabrikken din til en kunde i EU fra 20. januar 2027, må oppfylle de nye kravene, også programvarekravene. En produktfamilie som leveres fortløpende, trenger styringsprogramvaren klar før den første enheten i 2027, ikke ved neste modellskifte.

Senere oppdateringer krever også omtanke. En endring gjort «med fysiske eller digitale midler» som produsenten ikke forutså, og som skaper en ny fare eller øker en risiko, kan være en vesentlig endring. Fortalepunkt 32 sier at risikovurderingen bør dekke programvareoppdateringer som var forutsett da maskinen ble brakt i omsetning, så beskriv oppdateringsveien din der nå.

Hva det betyr i hvert lag av maskinen

Sikkerhetsstyring og PLS

Bestem hva som er sikkerhetsrelevant. Det er som regel sikkerhetsprogrammet, men det kan omfatte vanlig PLS-kode som mater en sikkerhetsfunksjon, sikkerhetsparametere i drivere og konfigurasjonen av laserskannere eller lysgardiner. Skriv det ned per maskinfamilie; alt annet avhenger av det.
Referanselinje og sammenligning. For hver frigitt konfigurasjon registrerer du en sjekksum eller signatur for hvert sikkerhetsrelevant element. Ved oppstart og med jevne mellomrom sammenligner maskinen det som kjører, med den referanselinjen og registrerer eventuelle avvik. Det fanger opp inngrepet som gikk utenom tilgangskontrollen din, som en bærbar PC koblet rett inn i styringen.
Steng ned ingeniørtilgangen. Passord på sikkerhetsprogrammet, ubrukte porter og tjenester deaktivert, og ingeniørtilgang bare gjennom en vei som autentiserer personen og logger hva vedkommende gjorde.

HMI

Et skjermbilde for programvareidentifikasjon som viser den sikkerhetsrelevante programvaren med versjoner og sjekksummer. Les verdiene direkte fra enhetene. En side som ble skrevet inn ved frigivelse, glir fra virkeligheten, og kravet sier «til enhver tid».
Parameterskjermbilder. Punkt 1.2.1 bokstav d utelukker endringer i innstillinger eller regler som kan føre til farlige situasjoner. Sikkerhetsrelaterte parametere hører hjemme bak tilgangsnivåer, med grenser som håndheves i styringen og ikke bare i HMI-et, og hver endring registreres med hvem, når, gammel verdi og ny verdi.

Fjerntilgang

Punkt 1.1.9 nevner fjernenheter uttrykkelig. I praksis:

Sikkerhetsfunksjonene forblir lokale. En fjernsesjon kan lese, diagnostisere og klargjøre en endring. Den kan ikke overstyre en stopp, et vern eller en aktiveringsinnretning.
Sesjoner autentiseres per person, ikke gjennom en delt tjenestekonto, og kunden kan se når en sesjon er åpen.
Hver start og slutt på en sesjon og hver endring går inn i den samme bevisloggen som lokale inngrep.

Backend og oppdateringsløype

Leverer du oppdateringer etter levering, er oppdateringsserveren din en del av arbeidet. For hvert serienummer må du vite hvilken versjon av sikkerhetsprogramvaren som ble lastet opp, når og av hvem. Signer oppdateringene, og la maskinen kontrollere signaturen før den installerer noe.

Selve sporingsloggen

Forordningen sier ikke hvor loggen skal ligge. Vårt syn: kopien som teller, ligger på maskinen, fordi mange kunder ikke vil tillate en permanent tilkobling. Et speil i skyen er nyttig, men kan ikke være den eneste kopien.

Volumet er lite: inngrep og opplastinger av sikkerhetsprogramvare, ikke prosessdata. Fem år får plass i lokal lagring hvis du dimensjonerer den bevisst. Beskytt den mot sletting, og sørg for at den overlever et bytte av styringsenhet. Navngir oppføringene en tekniker, er det personopplysninger hos kunden: logg det kravet trenger og ikke mer.

Hva leverandøren av styringssystemet gir deg, og hva den ikke gir

Plattformen for styringssystemet ditt vil levere en del av dette. Før du bygger noe, sjekk hva den tilbyr: en signatur eller sjekksum over sikkerhetsprogrammet, passordbeskyttelse, brukeradministrasjon, en endringslogg, uthenting av versjon. Bruk det som finnes.

Dette er byggeklosser. Leverandøren vet ikke hvilke av driverne og skannerne dine som er sikkerhetsrelevante, kan ikke se fjerntilgangsgatewayen eller oppdateringsserveren din, og kan ikke bestemme hvordan bevisene skal overleve fem år og et bytte av styringsenhet. Å konfigurere de funksjonene, koble dem sammen på tvers av hele maskinen og dokumentere resultatet er produsentens jobb, og produsenten signerer samsvarserklæringen.

Hvordan dette henger sammen med Cyber Resilience Act

Cyber Resilience Act følger sin egen kalender. Rapporteringspliktene har gjeldt siden 11. september 2026, og de fullstendige kravene gjelder fra 11. desember 2027. Maskinforordningen kommer mellom de to.

CRA erkjenner overlappen. Fortalepunkt 53 i forordning (EU) 2024/2847 sier at produsenter av maskiner som også er produkter med digitale elementer, bør oppfylle begge, og at etterlevelse av CRA «kan lette» etterlevelsen av punkt 1.1.9 og 1.2.1. Det er produsenten som må dokumentere den synergien. Vedlegg I til CRA krever beskyttelse av integriteten til «kommandoer, programmer og konfigurasjon» og rapportering om korrumpering, noe som ligger nær det 1.1.9 krever.

Én forskjell betyr noe for utformingen av loggen. CRAs krav om å registrere og overvåke intern aktivitet kommer «med en mulighet for brukeren til å reservere seg». Sporingsloggen i maskinforordningen må være aktivert i fem år. Bygg gjerne én loggmekanisme, men ikke la reservasjonsmuligheten i CRA slå av maskinloggen.

Bygg for maskinforordningen nå, fordi den kommer først, og design det slik at det samme bevislageret, signeringen og oppdateringsregistrene tjener CRA i desember 2027.

Standarder og utsettelsen som ikke kom

Ikke regn med at en harmonisert standard som dekker disse kravene, er sitert innen 20. januar 2027. Kommisjonens side om harmoniserte standarder, oppdatert i september 2026, sier at den første listen under maskinforordningen er under arbeid. Den vil videreføre de fleste standardene som er sitert under direktivet, og presisere dem der de «ennå ikke fullt ut dekker» de nye kravene, og den «kan forventes før utgangen av året».

I januar 2026 ba CEMA, CECE, CECIMO, EGMF og FEM i et felles bransjestandpunkt om at 1.1.9 og 1.2.1 bokstav f ble utsatt til 11. desember 2027, i takt med CRA. De anslo etterlevelseskostnadene til «mer enn 1 million euro per plattformarkitektur» og sa at de ventede standardene forblir svært generelle når det gjelder dataloggen i 1.2.1 bokstav f.

Den anmodningen ble ikke tatt til følge. Maskinforordningen ble endret i juli 2026 ved forordning (EU) 2026/1744, men den endringen gjelder KI-systemer med høy risiko i maskiner og lar anvendelsesdatoen stå. Planlegg etter 20. januar 2027.

Du har altså kanskje ingen standard som gir presumsjon om samsvar for disse to kravene på dag én. Den tekniske dokumentasjonen må da beskrive løsningen du har valgt for hvert av dem (vedlegg IV). Skriv det mens du bygger, ikke etterpå. For maskiner som er oppført i vedlegg I del B, er det ett trinn til: egenvurdering er bare mulig hvis harmoniserte standarder eller felles spesifikasjoner dekker alle de relevante kravene; ellers kobles et teknisk kontrollorgan (notified body) inn (artikkel 25). Maskiner som ikke er oppført i vedlegg I, egenvurderes uansett.

En plan over 15 uker

Fra mandag 5. oktober 2026 til fristen er det litt over 15 uker, med juleferien midt i. Det er knapt, men gjennomførbart hvis du prioriterer etter leveringsdato: familier med EU-enheter som sendes i januar, kommer først.

Uke 1 og 2 (5. til 16. oktober): avgrensning. List opp hver maskinfamilie som vil levere enheter til EU etter 20. januar 2027. For hver av dem, list opp den sikkerhetsrelevante programvaren og dataene: sikkerhetsprogram, vanlig kode som er kritisk for samsvar, sikkerhetsparametere i drivere og sensorer, HMI, fastvare, fjerntilgangsgateway. Utpek én ansvarlig per familie.
Uke 3 og 4 (19. til 30. oktober): risikovurdering og gap. Oppdater risikovurderingen for tilkoblinger, fjerntilgang, ondsinnede forsøk og oppdateringsveien. Sjekk hva plattformen for styringssystemet tilbyr, og hva som er slått på.
Uke 5 til 9 (2. november til 4. desember): utvikling. Skjermbilde for programvareidentifikasjon, sammenligning mot referanselinje, tilgangskontroll på ingeniør- og fjerntilgang, sporingsloggen med kapasitet for fem år, signerte oppdateringer og registre per serienummer i backenden.
Uke 10 og 11 (7. til 18. desember): test det slik en tekniker og en angriper ville gjort. Endre en sikkerhetsparameter direkte med leverandørens verktøy, og bekreft at maskinen registrerer det. Bytt en styringsenhet og sjekk at loggen overlever. Kutt strømmen under en oppdatering.
Uke 12 og 13 (21. desember til 1. januar): helligdager. Planlegg ikke noe utviklingsarbeid; la en langtidstest fylle loggen mot størrelsen for fem år.
Uke 14 og 15 (4. til 15. januar): dokumentasjon og frigivelse. Oppføringer i den tekniske dokumentasjonen for 1.1.9 og 1.2.1, en bruksanvisning som forklarer hvordan kunden leser programvareidentifikasjonen og hva fjerntilgangen kan og ikke kan gjøre, og et produksjonstrinn som laster inn den frigitte referanselinjen og registrerer den per serienummer.

Trenger flere plattformarkitekturer dette enn det får plass til i det vinduet, si fra til salg nå: en enhet som ikke er klar, kan ikke lovlig bringes i omsetning på EU-markedet.

Hvem dette ikke er for

Maskiner som er brakt i omsetning før 20. januar 2027, nås ikke av disse programvarereglene, med mindre noen senere endrer dem vesentlig. Kjøper du maskiner i stedet for å bygge dem, ligger plikten hos leverandøren; din del er å be om programvareidentifikasjonen og tilgang til loggen i kravspesifikasjonene dine.

Hvor du får hjelp

Vi er et programvareselskap, ikke et teknisk kontrollorgan eller et advokatfirma. Vi bygger og endrer programvaren disse kravene havner i: HMI- og backend-applikasjoner, gatewayer for fjerntilgang, oppdateringsløyper og bevislogging, i samarbeid med automasjonsingeniørene som eier sikkerhetsprogrammet. Eldre plattformer med mange år med opphopet kode er det vanskeligste tilfellet, og det er der arbeidet vårt med vedlikehold av eldre systemer som regel starter, og CRA-siden er dekket i vår guide til Cyber Resilience Act. Har teamet ditt planen, men ikke hendene til å bli ferdig innen januar, skriv til office@c9group.dev.