De Machineverordening vanaf 20 januari 2027: wat ze vraagt van de software in uw machines

Op 20 januari 2027 wordt de Machinerichtlijn vervangen door Verordening (EU) 2023/1230, de Machineverordening. Het meeste ervan zal bekend aanvoelen voor iedereen die machines met CE-markering bouwt. Eén deel niet. Voor het eerst legt de machinewetgeving rechtstreeks verplichtingen op aan software: de machine moet aangeven welke software ze nodig heeft om veilig te werken, merken wanneer die software of haar configuratie verandert, bestand zijn tegen corruptie, en vijf jaar lang een spoor bijhouden van updates van veiligheidssoftware.

Dit artikel is geschreven voor hoofden engineering en besturingstechniek bij machinebouwers. Levert u na die datum machines in de EU, dan komen deze eisen terecht in uw PLC-programma's, uw HMI, uw toegang op afstand en de backend voor uw updates.

Wat de wet werkelijk zegt

De Europese Commissie stelt dat de verordening “vanaf 20 januari 2027 verplicht van toepassing is” en dat ze “bepalingen integreert voor cyberveiligheid van softwaregegevens die relevant zijn voor de conformiteit en van veiligheidsbesturingssystemen”. In de tekst die in 2023 werd gepubliceerd, stond 14 januari; een rectificatie heeft de datum verschoven.

De softwareverplichtingen staan in twee essentiële veiligheids- en gezondheidseisen in bijlage III van de verordening.

Punt 1.1.9, bescherming tegen corruptie. Kort samengevat:

• Het aansluiten van een ander apparaat op de machine, rechtstreeks of op afstand, mag niet tot een gevaarlijke situatie leiden.
• Software en gegevens die van cruciaal belang zijn voor de naleving van de veiligheidseisen, moeten als zodanig worden geïdentificeerd en beschermd tegen onopzettelijke of opzettelijke corruptie.
• Hardware die signalen of gegevens doorgeeft waarmee toegang tot die software mogelijk is (denk aan een programmeerpoort of een netwerkinterface naar de veiligheidscontroller), moet ook worden beschermd, en de machine moet bewijs verzamelen van ingrepen daarin.
• De machine moet de daarop geïnstalleerde software identificeren die nodig is voor een veilige werking, en die informatie te allen tijde in een gemakkelijk toegankelijke vorm kunnen verstrekken.
• De machine moet bewijs verzamelen van een rechtmatige of onrechtmatige ingreep in de software, of van een wijziging van de software die op de machine of het aanverwante product is geïnstalleerd, of van de configuratie daarvan.

Punt 1.2.1, veiligheid en betrouwbaarheid van besturingssystemen. Besturingssystemen moeten bestand zijn tegen redelijkerwijs voorzienbare kwaadwillige pogingen van derden die tot een gevaarlijke situatie leiden. Punt f) voegt de logplicht toe: een traceerlogboek van de gegevens die bij een ingreep worden gegenereerd, en van de versies van veiligheidssoftware die na het in de handel brengen van de machine zijn geüpload, blijft gedurende vijf jaar na zo'n upload ingeschakeld. Het logboek bestaat om op een met redenen omkleed verzoek van een nationale autoriteit de conformiteit aan te tonen, en voor niets anders.

Ook op de lijst: de technische documentatie moet op verzoek van een autoriteit de broncode of de programmeerlogica van de veiligheidsgerelateerde software kunnen leveren (bijlage IV).

Welke machines eronder vallen

De regels gelden voor machines die vanaf 20 januari 2027 in de handel worden gebracht. Machines die vóór die datum onder de oude richtlijn in de handel zijn gebracht, mogen verder worden verkocht (artikel 52), en het machinepark dat al in het veld staat, wordt niet door de nieuwe softwareregels geraakt.

Het addertje zit in wat “in de handel brengen” betekent. De Blauwe Gids van de Commissie zegt dat het begrip “op elk afzonderlijk product betrekking heeft, niet op een producttype”. Elke eenheid die vanaf 20 januari 2027 uw fabriek verlaat voor een klant in de EU, moet aan de nieuwe eisen voldoen, software inbegrepen. Een productfamilie die doorlopend wordt geleverd, heeft haar besturingssoftware klaar nodig vóór de eerste eenheid van 2027, niet bij de volgende modelwissel.

Ook latere updates vragen aandacht. Een wijziging “met fysieke of digitale middelen” die de fabrikant niet had voorzien en die een nieuw gevaar creëert of een risico vergroot, kan een substantiële wijziging zijn. Overweging 32 zegt dat de risicobeoordeling de software-updates moet dekken die bij het in de handel brengen zijn voorzien, dus beschrijf uw updatepad daar nu.

Wat het betekent in elke laag van de machine

Veiligheidscontroller en PLC

• Bepaal wat veiligheidsrelevant is. Meestal is dat het veiligheidsprogramma, maar het kan ook standaard-PLC-code omvatten die een veiligheidsfunctie voedt, veiligheidsparameters in aandrijvingen, en de configuratie van laserscanners of lichtschermen. Leg het per machinefamilie vast; al het andere hangt ervan af.
• Basislijn en vergelijking. Leg voor elke vrijgegeven configuratie een checksum of handtekening vast van elk veiligheidsrelevant onderdeel. Bij het opstarten en met tussenpozen vergelijkt de machine wat er draait met die basislijn en registreert ze elk verschil. Zo vangt u de ingreep op die om uw toegangsbeveiliging heen ging, zoals een laptop die rechtstreeks op de controller is aangesloten.
• Sluit de engineeringtoegang af. Wachtwoorden op het veiligheidsprogramma, ongebruikte poorten en diensten uitgeschakeld, en engineeringtoegang alleen via een pad dat de persoon authenticeert en vastlegt wat hij heeft gedaan.

HMI

• Een scherm met software-identificatie dat de veiligheidsrelevante software toont met versies en checksums. Lees de waarden live uit de apparaten. Een pagina die bij de release is uitgetypt, raakt los van de werkelijkheid, en de eis zegt “te allen tijde”.
• Parameterschermen. Punt 1.2.1, onder d), sluit wijzigingen van instellingen of regels uit die tot gevaarlijke situaties kunnen leiden. Veiligheidsgerelateerde parameters horen achter toegangsniveaus, met grenzen die in de controller worden afgedwongen en niet alleen in de HMI, en met elke wijziging vastgelegd: wie, wanneer, de oude waarde en de nieuwe.

Toegang op afstand

Punt 1.1.9 noemt apparaten op afstand uitdrukkelijk. In de praktijk:

• Veiligheidsfuncties blijven lokaal. Een sessie op afstand kan lezen, diagnosticeren en een wijziging klaarzetten. Ze kan geen stop, afscherming of vrijgave-inrichting overbruggen.
• Sessies worden per persoon geauthenticeerd, niet via een gedeeld serviceaccount, en de klant kan zien wanneer er een openstaat.
• Elk begin en einde van een sessie en elke wijziging komt in hetzelfde bewijslogboek als lokale ingrepen.

Backend en updatepijplijn

Levert u na verzending updates, dan valt uw updateserver binnen de reikwijdte van het werk. Per serienummer moet u weten welke versie van de veiligheidssoftware is geüpload, wanneer en door wie. Onderteken de updates, en laat de machine de handtekening controleren voordat ze iets installeert.

Het traceerlogboek zelf

De verordening zegt niet waar het logboek staat. Onze opvatting: het exemplaar dat telt, staat op de machine, omdat veel klanten geen permanente verbinding toestaan. Een spiegel in de cloud is nuttig, maar kan niet het enige exemplaar zijn.

Het volume is klein: ingrepen en uploads van veiligheidssoftware, geen procesdata. Vijf jaar past in lokale opslag als u die bewust dimensioneert. Bescherm het logboek tegen verwijdering en zorg dat het een vervanging van de controller overleeft. Noemen regels een monteur, dan zijn dat persoonsgegevens op de locatie van de klant: leg vast wat de eis vraagt en niets meer.

Wat uw controllerleverancier u geeft, en wat niet

Uw controllerplatform levert een deel hiervan. Controleer voordat u iets bouwt wat het biedt: een handtekening of checksum over het veiligheidsprogramma, wachtwoordbeveiliging, gebruikersbeheer, een wijzigingslogboek, het uitlezen van versies. Gebruik wat er is.

Dat zijn bouwstenen. De leverancier weet niet welke van uw aandrijvingen en scanners veiligheidsrelevant zijn, ziet uw gateway voor toegang op afstand en uw updateserver niet, en kan niet beslissen hoe bewijs vijf jaar en een vervanging van de controller overleeft. Die functies configureren, ze over de hele machine met elkaar verbinden en het resultaat documenteren, is het werk van de bouwer, en de bouwer ondertekent de conformiteitsverklaring.

Hoe dit zich verhoudt tot de Cyber Resilience Act

De Cyber Resilience Act heeft een eigen kalender. De meldplichten gelden sinds 11 september 2026, en de volledige eisen gelden vanaf 11 december 2027. De Machineverordening valt daartussen.

De CRA erkent de overlap. Overweging 53 van Verordening (EU) 2024/2847 zegt dat fabrikanten van machines die ook een product met digitale elementen zijn, aan beide moeten voldoen, en dat naleving van de CRA de naleving van de punten 1.1.9 en 1.2.1 kan vergemakkelijken. De fabrikant moet die synergie aantonen. Bijlage I van de CRA vraagt om bescherming van de integriteit van commando's, programma's en configuratie, en om rapportage over corruptie, wat dicht in de buurt komt van wat 1.1.9 vraagt.

Eén verschil doet ertoe voor het ontwerp van uw logboek. De eis van de CRA om interne activiteit te registreren en te monitoren, gaat gepaard met een mogelijkheid voor de gebruiker om zich af te melden. Het traceerlogboek van de Machineverordening moet vijf jaar ingeschakeld blijven. Bouw desgewenst één logmechanisme, maar laat de afmeldmogelijkheid van de CRA het machinelogboek niet uitschakelen.

Bouw nu voor de Machineverordening, omdat die eerst komt, en ontwerp het zo dat dezelfde bewijsopslag, ondertekening en updateregistratie in december 2027 ook de CRA dienen.

Normen en het mislukte uitstel

Reken er niet op dat er op 20 januari 2027 een geharmoniseerde norm is aangewezen die deze eisen dekt. De pagina over geharmoniseerde normen van de Commissie, bijgewerkt in september 2026, zegt dat de eerste lijst onder de Machineverordening in voorbereiding is. Die neemt de meeste normen over die onder de richtlijn waren aangewezen en verduidelijkt ze waar ze de nieuwe eisen “nog niet volledig dekken”, en ze “mag vóór het einde van dit jaar worden verwacht”.

In januari 2026 vroegen CEMA, CECE, CECIMO, EGMF en FEM in een gezamenlijk standpunt van de industrie om 1.1.9 en 1.2.1, onder f), uit te stellen tot 11 december 2027, gelijk met de CRA. Ze schatten de nalevingskosten op “meer dan € 1 miljoen per platformarchitectuur” en zeiden dat de verwachte normen zeer algemeen blijven over het gegevenslogboek uit 1.2.1, onder f).

Dat verzoek is niet overgenomen. De Machineverordening werd in juli 2026 gewijzigd bij Verordening (EU) 2026/1744, maar die wijziging gaat over AI-systemen met een hoog risico in machines en laat de toepassingsdatum ongemoeid. Plan op 20 januari 2027.

Het kan dus zijn dat u op dag één voor deze twee eisen geen norm hebt die een vermoeden van conformiteit geeft. Uw technisch dossier moet dan per eis de oplossing beschrijven die u hebt toegepast (bijlage IV). Schrijf dat tijdens het bouwen, niet achteraf. Voor machines die in bijlage I, deel B, staan, is er nog een stap: de zelfbeoordeling staat alleen open als geharmoniseerde normen of gemeenschappelijke specificaties alle relevante eisen dekken; anders komt er een aangemelde instantie aan te pas (artikel 25). Machines die niet in bijlage I staan, beoordelen zichzelf in beide gevallen.

Een plan van 15 weken

Van maandag 5 oktober 2026 tot de deadline is iets meer dan 15 weken, met de feestdagen in het midden. Dat is krap maar werkbaar als u prioriteert op leverdatum: families waarvan in januari eenheden naar de EU gaan, komen eerst.

1. Week 1 en 2 (5 tot en met 16 oktober): reikwijdte. Maak een lijst van elke machinefamilie waarvan na 20 januari 2027 eenheden naar de EU gaan. Noteer per familie de veiligheidsrelevante software en gegevens: veiligheidsprogramma, standaardcode die cruciaal is voor de conformiteit, veiligheidsparameters van aandrijvingen en sensoren, HMI, firmware, gateway voor toegang op afstand. Wijs per familie één eigenaar aan.
2. Week 3 en 4 (19 tot en met 30 oktober): risicobeoordeling en hiaten. Werk de risicobeoordeling bij voor verbindingen, toegang op afstand, kwaadwillige pogingen en het updatepad. Ga na wat uw controllerplatform biedt en wat er is ingeschakeld.
3. Week 5 tot en met 9 (2 november tot en met 4 december): bouwen. Scherm met software-identificatie, vergelijking met de basislijn, toegangsbeveiliging op engineering en toegang op afstand, het traceerlogboek met capaciteit voor vijf jaar, ondertekende updates en registratie per serienummer in de backend.
4. Week 10 en 11 (7 tot en met 18 december): test zoals een monteur en een aanvaller dat zouden doen. Wijzig een veiligheidsparameter rechtstreeks met de tool van de leverancier en controleer of de machine het vastlegt. Vervang een controller en controleer of het logboek dat overleeft. Haal de stroom eraf tijdens een update.
5. Week 12 en 13 (21 december tot en met 1 januari): feestdagen. Plan geen engineeringwerk; laat een duurtest het logboek naar zijn omvang voor vijf jaar vullen.
6. Week 14 en 15 (4 tot en met 15 januari): documentatie en vrijgave. Onderdelen van het technisch dossier voor 1.1.9 en 1.2.1, een gebruiksaanwijzing die uitlegt hoe een klant de software-identificatie leest en wat toegang op afstand wel en niet kan, en een productiestap die de vrijgegeven basislijn laadt en per serienummer vastlegt.

Hebben meer platformarchitecturen dit nodig dan er in dat venster passen, vertel het verkoop dan nu: een eenheid die niet klaar is, mag niet rechtmatig in de EU in de handel worden gebracht.

Voor wie dit niet is

Machines die vóór 20 januari 2027 in de handel zijn gebracht, worden niet door deze softwareregels geraakt, tenzij iemand ze later substantieel wijzigt. Koopt u machines in plaats van ze te bouwen, dan ligt de plicht bij uw leverancier; uw deel is in uw specificaties te vragen om de software-identificatie en toegang tot het logboek.

Waar u hulp krijgt

Wij zijn een softwarebedrijf, geen aangemelde instantie of advocatenkantoor. Wij bouwen en wijzigen de software waarin deze eisen terechtkomen: HMI- en backendapplicaties, gateways voor toegang op afstand, updatepijplijnen en bewijslogging, samen met de besturingsingenieurs die eigenaar zijn van het veiligheidsprogramma. Oudere platforms met jaren aan opgestapelde code zijn het moeilijkste geval, en daar begint ons werk voor onderhoud van legacysystemen meestal; de kant van de CRA staat in onze gids over de Cyber Resilience Act. Heeft uw team het plan maar niet de handen om het vóór januari af te maken, schrijf dan naar office@c9group.dev.