Cyberbeveiliging voor machinebouwers

Vanaf 2027 valt een machine met een besturing, een bedieningsdisplay of een dataverbinding onder twee EU-verordeningen. Beide beginnen bij dezelfde vraag: welke software staat er op deze machine, versie voor versie, en wat zit erin?

1. 11 september 2026De meldplicht van de Cyber Resilience Act voor actief uitgebuite kwetsbaarheden en ernstige incidenten gaat gelden.
2. 20 januari 2027De machineverordening, (EU) 2023/1230, gaat gelden en vervangt de machinerichtlijn.
3. 11 december 2027De Cyber Resilience Act, (EU) 2024/2847, is volledig van toepassing.

Machineverordening

Twee essentiële veiligheids- en gezondheidseisen in bijlage III gaan over cyberbeveiliging:

• 1.1.9, bescherming tegen corruptie. Het direct of op afstand verbinden van een ander apparaat met de machine mag niet leiden tot een gevaarlijke situatie. Software en gegevens die cruciaal zijn voor de overeenstemming van de machine met de essentiële veiligheids- en gezondheidseisen moeten worden geïdentificeerd en beschermd tegen onopzettelijke of opzettelijke corruptie. De machine moet de daarop geïnstalleerde software identificeren die zij nodig heeft om veilig te werken, en die informatie te allen tijde verstrekken. Ook moet zij bewijs verzamelen van rechtmatige of onrechtmatige ingrepen in die software of de configuratie ervan.
• 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. Volgens 1.2.1(f) moeten ze een traceerlog bijhouden van ingrepen en van de versies van veiligheidssoftware die zijn geüpload nadat de machine in de handel is gebracht, tot vijf jaar na de upload.

Cyber Resilience Act

Een machine met een dataverbinding, of een los verkocht onderdeel ervan, is een product met digitale elementen. De fabrikant moet gepaste zorgvuldigheid betrachten bij de componenten van derden die hij integreert, een SBOM opstellen die ten minste de afhankelijkheden op het hoogste niveau omvat, kwetsbaarheden afhandelen gedurende de ondersteuningsperiode, die ten minste vijf jaar bedraagt tenzij het product naar verwachting korter wordt gebruikt, en de technische documentatie ten minste tien jaar of gedurende de ondersteuningsperiode bewaren, afhankelijk van welke langer is.

Niet automatisch. De Cyber Resilience Act geeft geen vermoeden van overeenstemming met de machineverordening. Overweging 53 zegt dat voldoen aan de essentiële eisen van de CRA de naleving kan vergemakkelijken van de eisen van de machineverordening inzake bescherming tegen corruptie en inzake de veiligheid en betrouwbaarheid van besturingssystemen. Ze zegt ook dat de fabrikant dit moet aantonen, bijvoorbeeld door na een risicobeoordeling geharmoniseerde normen toe te passen, en dat de conformiteitsbeoordelingsprocedures van beide verordeningen blijven gelden.

De geharmoniseerde norm die voor 1.1.9 wordt opgesteld, is EN 50742, Safety of machinery – Protection against corruption. In november 2026 lag die er als eindontwerp, FprEN 50742, dat 1.1.9 en de bijbehorende punten van 1.2.1 behandelt; zolang de referentie van een definitieve versie niet in het Publicatieblad van de EU is bekendgemaakt, geeft de norm geen vermoeden van overeenstemming. De norm combineert de risicobeoordeling van EN ISO 12100 met beveiligingsconcepten uit IEC 62443 en erkent consequente toepassing van IEC 62443-4-1, IEC 62443-3-3 en IEC 62443-4-2 als gelijkwaardige manier om de beschermingsdoelen te halen. IEC 62443-4-2 legt de technische beveiligingseisen vast voor componenten van besturingssystemen, ingedeeld naar security capability level. In Duitsland vertalen de keuringsprincipes GS-IFA-M25 van juli 2026 bescherming tegen corruptie in 66 toetscriteria, met de begrippen van prEN 50742. Een daarvan, T46, vraagt dat het product op verzoek de geïnstalleerde softwareversie en configuratie kan geven. Om dat voor elke configuratie te beantwoorden, is een vastlegging nodig van wat elke softwareversie bevat.

De machineverordening kent een eigen vermoeden, en dat loopt via een andere route: Europese regelingen voor cyberbeveiligingscertificering die zijn vastgesteld op grond van de cyberbeveiligingsverordening, Verordening (EU) 2019/881. Een certificaat of conformiteitsverklaring onder zo'n regeling geeft een vermoeden van overeenstemming met 1.1.9 en 1.2.1, voor zover die eisen erdoor worden gedekt.

Eén risicobeoordeling en één set bewijs kunnen dus beide verordeningen dienen, maar u toont de overeenstemming met elk afzonderlijk aan. Heeft uw machine een dataverbinding, plan dan voor beide. Het softwarebewijs, dus SBOM's, kwetsbaarheidsrecords en de updategeschiedenis, is het deel dat ze delen.

In januari 2026 vroegen brancheverenigingen van de machinebouw om uitstel van 1.1.9 en 1.2.1(f), en in maart 2026 om ze te laten gelden vanaf de datum van de CRA, 11 december 2027. Het is een verzoek, geen wet: per november 2026 was er geen uitstel vastgesteld. De data op deze pagina zijn de data in de verordeningen.

• Bouw-, materiaalbehandelings-, mijnbouw- en industriële machines vallen onder de machineverordening, en ook onder de CRA wanneer de machine of haar onderdelen een dataverbinding hebben.
• Landbouw- en bosbouwtrekkers die onder Verordening (EU) nr. 167/2013 vallen, zijn uitgesloten van de machineverordening, behalve de machines die erop zijn gemonteerd. De lijst met uitsluitingen van de CRA noemt die verordening niet, dus een verbonden trekker kan onder de CRA vallen.
• Wegvoertuigen die zijn goedgekeurd op grond van Verordening (EU) 2019/2144 zijn uitgesloten van de CRA.
• Los verkochte componenten. De CRA geldt ook voor software- en hardwarecomponenten die afzonderlijk in de handel worden gebracht. Een leverancier die een ECU of een telematica-unit los verkoopt, is zelf fabrikant onder de CRA. Wordt de unit alleen in de machine ingebouwd, dan draagt de machinebouwer de verplichting voor de hele machine en moet hij gepaste zorgvuldigheid betrachten bij het component van de leverancier.

Dit is algemene informatie, geen juridisch advies. Controleer de classificatie van uw eigen product.

Binnen één machine komt de software uit verschillende bronnen, en alleen het team dat een stuk software bouwt, kan betrouwbaar zeggen wat erin zit. Zoals we van machinebouwers horen, bevatten bare-metal-ECU's weinig open source, terwijl Linux-, Android- en Windows-software er veel bevat.

Kleine aantallen, grote variatie. Een machinebouwer kan honderden platforms op de markt hebben, van elk maar een handvol eenheden per jaar verkopen en veel machines op bestelling configureren. Elke configuratie is een andere set software, dus een SBOM voor elke build telt zwaarder dan een SBOM voor elke productlijn.

Lange levensduur. Machines blijven tien jaar of langer in gebruik, terwijl leveranciers wisselen of verdwijnen. De vastlegging van wat er in een softwareversie is gegaan, moet ontstaan bij de build, want jaren later valt die niet meer te reconstrueren.

Leverancierssoftware overheerst, en SBOM's van leveranciers zijn vaak slecht. We horen over SBOM's van leveranciers met ontbrekende componenten, zonder package URL's of CPE's, zonder licenties en zonder hashes, sommige met de hand geschreven en niet door de schemavalidatie heen. Binaire analyse van een geflashte ECU is een noodoplossing: die raadt naar de inhoud in plaats van hem vast te leggen.

Het risico zit in de verbonden lagen. Veel ECU-logica wordt uit modellen gegenereerd en bevat weinig open source. De open source en de blootstelling aan het netwerk concentreren zich in de Linux-, connectiviteits- en applagen, dus besteed uw inspanning daar eerst.

Een illustratief voorbeeld: de softwarestack van een fictief wielladerplatform, van de cloud tot aan de ECU's.

1. Cloudbackend en companion-appEigen ontwikkeling. Grotendeels open source en via het netwerk bereikbaar. Cyber Resilience Act.
2. TelematicagatewayEmbedded Linux, grotendeels open source, verbonden met het mobiele netwerk. Cyber Resilience Act, en 1.1.9 voor de verbinding op afstand.
3. BedieningsdisplayEmbedded Linux-image met een UI-framework, grotendeels open source, verbonden met de machinebus en met servicetools. Cyber Resilience Act en 1.1.9.
4. MachinebesturingEigen applicatie op een leveranciersplatform, veiligheidsrelevant. 1.1.9 en 1.2.1, en de Cyber Resilience Act waar ze via een verbinding bereikbaar is.
5. Hydrauliek-, besturings- en motor-ECU'sLeveranciersfirmware, propriëtair en uit modellen gegenereerd, weinig open source, veiligheidsrelevant. 1.1.9 en 1.2.1; de Cyber Resilience Act via de machine.

De open source en de blootstelling aan het netwerk zitten in de bovenste drie lagen, en daar draaien meestal ook uw eigen buildpipelines. Begin daar.

Machinebouwers stellen nu SBOM-eisen aan de software die ze inkopen, zoals package URL's of CPE's, licenties, hashes en een formaat dat door de validatie komt, en sturen bestanden terug die niet voldoen. Als u op GitHub Actions bouwt, maakt CRACI de SBOM uit de build zelf, zodat die vermeldt wat er werkelijk in de release is gegaan, inclusief de componenten die in geen enkele lockfile staan, met een package URL en gedeclareerde licentie voor elk component. Controleer de export aan de hand van de volledige lijst velden die uw klant vraagt. Meer over het beantwoorden van SBOM-verzoeken van klanten.