CRA voor machinefabrikanten na de richtsnoeren van de Commissie van 27 juli 2026. Wat moet er nu echt worden geïmplementeerd?

Jarenlang liet de cyberbeveiliging van een machine zich in drie stappen samenvatten: een merk-PLC, een VPN “omdat dat nu eenmaal zo hoort” en de klassieke redenering “de klant beveiligt het netwerk wel”. En als er dan ook nog een firewall in de schakelkast zat, werd het onderwerp al snel als afgedaan beschouwd — tenminste totdat iemand wilde nagaan wat er bij een echte aanval gebeurt, en niet alleen in een presentatie.

Alleen: cyberbeveiliging loopt niet via PROFINET vanzelf mee. Componenten kunnen certificaten, verklaringen en “secure by design” in de marketingbrochure hebben, maar de machine als geheel kan nog steeds voorspelbaar zijn op een manier die niets met veiligheid te maken heeft. Net zoals een veiligheidsrelais een systeem niet veilig maakt als de besturingslogica het mogelijk maakt het te omzeilen, lost een “veilig” HMI het probleem van architectuur, integratie, rechten, updates en wat er gebeurt zodra iemand ophoudt om toestemming te vragen, niet op.

CRA (Cyber Resilience Act, Verordening van het Europees Parlement en de Raad (EU) 2024/2847) is geen extraatje voor IT. Het is een productregelgeving die zonder toestemming van de automatiseringsafdeling de levenscyclus van de machine binnenkomt. Ze omvat het ontwerp van de besturing, de risicoanalyse, de toeleveringsketen, configuratie, updates en ook het onderhoud van het product lang nadat de FAT is ondertekend en de machine de hal heeft verlaten. En nee, het argument “we hangen haar niet aan het internet” sluit de kwestie niet af. In de praktijk zijn een servicelaptop, een USB-stick, tijdelijke diagnose op afstand of integratie met een fabriekssysteem al genoeg om de grens tussen isolatie en blootstelling te laten verdwijnen.

De richtsnoeren van de Commissie van 27 juli 2026 hebben de verordening zelf niet gewijzigd, maar wel de interpretatieruimte aanzienlijk beperkt die eerder toeliet cyberbeveiliging als een optionele laag te behandelen. Ze verduidelijken onder meer de productgrens, de rol van verwerking op afstand, de verantwoordelijkheid voor wijzigingen na levering en het feit dat “na de FAT is het niet meer ons probleem” geen veilige aanname meer is.

De belangrijkste verandering is echter fundamenteler: een cyberaanval is niet langer uitsluitend een IT-gebeurtenis, maar wordt een scenario dat de functionele veiligheid van de machine beïnvloedt. Als een ongeautoriseerde wijziging van het programma kan leiden tot asbeweging, het omzeilen van een vergrendeling, wijziging van procesparameters of verlies van veiligheidsfuncties, dan hebben we het niet meer over een “netwerkincident”. Dan hebben we het over potentieel ongecontroleerd gedrag van de machine — ongeacht of de oorzaak een configuratiefout, een kwetsbaarheid in de software of opzettelijke manipulatie was.

In die context is een eenmalige pentest vóór de FAT geen bewijs van conformiteit meer, maar slechts een momentopname van de toestand van het systeem op een bepaald tijdstip. De CRA vereist een continue aanpak: van ontwerp, via productie en inbedrijfstelling, tot updates, beheer van kwetsbaarheden, incidentrespons en onderhoud gedurende de opgegeven ondersteuningsperiode.

In de praktijk betekent dit afscheid nemen van het denken “gereed = veilig” en overstappen op “onderhouden = beheerst”. Zonder de illusie dat een firewall in de schakelkast, een VPN en een componentcertificaat de zaak afdoen. En zonder de aanname dat cyberbeveiliging eindigt op het moment dat het opleveringsprotocol is ondertekend.

In dit artikel ontleden we wat de CRA-richtsnoeren in de praktijk veranderen voor fabrikanten, integratoren en moderniseerders van machines — zonder het hele onderwerp terug te brengen tot de slogan “laten we het wachtwoord veranderen en een checkbox cybersecurity toevoegen”.

1. Om buiten de CRA te vallen, zou een machine bijna volledig op contactoren moeten draaien

In veel projecten wordt de reikwijdte van de CRA met één vraag getoetst:

Wordt de machine met het internet verbonden?

Nee.

Dus is de zaak afgedaan.

Op het schema staan een PLC, HMI, enkele aandrijvingen, decentrale in- en uitgangen, een ventieleiland, een veiligheidsscanner en een poort om het programma in te laden. De besturing communiceert met het paneel via PROFINET, wisselt met de aandrijvingen stuur- en statuswoorden uit, en sensoren leveren gegevens via IO-Link.

Maar een router met simkaart is er niet.

Zoals bekend worden gegevens pas echt gegevens zodra ze de productiehal verlaten.

Alleen vraagt de CRA niet of de machine toegang heeft tot het internet.

De vraag is of het beoogde gebruik of het redelijkerwijs te verwachten gebruik ervan een directe of indirecte, logische of fysieke gegevensverbinding met een apparaat of netwerk omvat. Dat hoeft geen verbinding met de cloud, de server van de fabrikant of het openbare internet te zijn. Het kan via een kabel lopen, via radiogolven, via een programmeerinterface of als onderdeel van een groter systeem.

En dan nu de kernvraag: wat in een typische machine verzendt er in werkelijkheid gegevens?

Leest het HMI toestanden uit de PLC en schrijft het setpoints weg?

Stuurt de PLC een stuurwoord naar de aandrijving en ontvangt die in reactie snelheid, status en een foutcode?

Geeft het in- en uitgangseiland het procesbeeld door?

Verstuurt een IO-Link-sensor de meetwaarde, de apparaat-ID en diagnostische gegevens?

Communiceert de safety PLC met modules via PROFIsafe?

Worden programma, hardwareconfiguratie of firmware vanaf een servicelaptop geladen?

Kunnen recepten, rapporten of updates via USB worden overgezet?

Als het antwoord ook maar één keer “ja” luidt, dan is er waarschijnlijk sprake van een gegevensverbinding.

En dat verandert niet door het feit dat:

• de machine werkt in een lokaal netwerk,
• er is geen openbaar IP-adres,
• de Ethernet-poort wordt alleen tijdens de inbedrijfstelling gebruikt,
• alleen de service sluit een laptop aan,
• de communicatie vindt uitsluitend binnen het besturingssysteem plaats,
• de klant heeft beloofd de machine nooit met internet te verbinden.

De CRA omvat niet alleen het gebruik dat in de handleiding als basisgebruik is beschreven, maar ook redelijkerwijs te voorzien gebruik. Een servicepoort houdt dus niet op gegevens te verzenden alleen omdat er op het schema “SERVICE ONLY” bij staat.

De richtsnoeren van de Commissie van 27 juli 2026 brengen echter een belangrijk onderscheid aan.

Niet elke kabel en niet elk elektrisch signaal is een gegevensverbinding.

Als een signaal uitsluitend dient om een bepaalde functie in te schakelen, uit te schakelen of van voeding te voorzien en geen digitaal gecodeerde informatie overdraagt, dan is het enkele feit dat er twee elektrische toestanden zijn nog niet voldoende om het als een gegevensverbinding aan te merken.

Een drukknop die spanning naar de spoel van een contactor stuurt, wordt niet ineens een digitale interface alleen omdat de toestand ervan als nul of één kan worden beschreven.

Op dezelfde manier kan een klassieke eindschakelaar die in een relais-contactorcircuit is opgenomen, alleen het circuit onderbreken of sluiten. Zo’n schakelaar verzendt geen apparaatnummer, proceswaarde, diagnosecode, firmwareversie of telegram met meerdere gegevens.

Maar wanneer diezelfde toestand een intelligent apparaat bereikt, wordt gecodeerd, via een bus verzonden, aan diagnose gekoppeld en door de ontvanger als informatie geïnterpreteerd, dan ligt de situatie anders.

De grens loopt dus niet tussen een “online” en een “offline” machine.

Die loopt tussen een gewoon stuursignaal en de uitwisseling van digitaal gecodeerde informatie.

Daarom zou een machine die alleen buiten de CRA zou vallen wegens het ontbreken van een gegevensverbinding, in de praktijk meer moeten lijken op een klassieke schakeling met drukknoppen, eindschakelaars, relais en contactoren dan op een modern project dat in TIA Portal wordt geopend.

Dat is uiteraard geen wettelijke uitzondering voor contactoren.

Je kunt een eenvoudige machine met een PLC bouwen die na een gedetailleerde analyse niet aan het toepassingscriterium voldoet. Je kunt ook aan een contactorschakeling een digitale regelaar, service-interface of communicatiemodule toevoegen en dan precies aan de andere kant van de grens uitkomen.

De naam van het component beslist de zaak niet.

Bepalend is wat het product feitelijk doet en waarmee het gegevens uitwisselt.

Daarom moet je, voordat je de vraag beantwoordt of een bepaalde machine onder de CRA valt, eerst vaststellen:

• waar de grens van het beoordeelde product loopt,
• welke apparaten en software-elementen er deel van uitmaken,
• over welke fysieke en logische interfaces het beschikt,
• welke informatie via die interfaces wordt verzonden,
• welke verbindingen direct zijn en welke via een groter systeem verlopen,
• welke daarvan voorkomen tijdens normaal bedrijf, inbedrijfstelling, diagnose, updates of service,
• welke gebruikswijzen redelijkerwijs te voorzien zijn, ook als de fabrikant die liever niet zou voorzien.

Zolang we deze vragen niet beantwoorden, weten we niet of de machine buiten het toepassingsgebied van de CRA blijft.

We hebben hoogstens een handige formulering:

“De machine is niet met internet verbonden”.

Alleen is dat een antwoord op een vraag die de CRA niet stelt.

PROFINET is geen internet. Voor de CRA hoeft het dat ook helemaal niet te zijn.

2. Cyberbeveiliging verspreidt zich niet via PROFINET

In veel projecten begint het onderwerp machineconformiteit al in de inkoopfase.

PLC van een gerenommeerde fabrikant.
HMI met actuele firmware.
Managed switch.
Industriële router met VPN.
Aandrijvingen met veiligheidsfuncties.
Safety PLC met het juiste certificaat.

Bij elk apparaat een conformiteitsverklaring, handleiding en een paar documenten met termen als “secure”, “encrypted” en “defence in depth”.

Op het schema ziet alles er professioneel uit.

Alleen is nog steeds niet duidelijk of de complete machine cyberveilig is.

Want cyberbeveiliging wordt niet “doorgegeven” via PROFINET.

Het is een beetje zoals met een slot in een deur:
je kunt in elke kamer een uitstekend slot hebben, gecertificeerd, getest, met prachtige documentatie en een “secure”-hologram, maar dat garandeert nog steeds geen veiligheid als iemand de voordeur wagenwijd heeft laten openstaan “omdat dat bij de inbedrijfstelling sneller was”.

En precies zo is het hier ook: componenten kunnen voorbeeldig zijn, terwijl het systeem toch… creatief openstaat.

Een PLC “geeft” geen beveiliging door aan een HMI.
Een firewall “herstelt” de applicatielogica niet.
Een switch “ordent” de gebruikerstoegang niet.
En het feit dat elk element een certificaat heeft, betekent nog niet dat de hele machine niet één groot, keurig gedocumenteerd lek is.

PROFINET verzendt gegevens.

Het verzendt geen verantwoordelijkheid.
En helaas verzendt het ook geen gezond verstand.

De CRA heeft zowel betrekking op complete producten als op componenten die afzonderlijk in de handel worden gebracht. Dat betekent dat een besturing, bedienpaneel of communicatiemodule afzonderlijk kan worden beoordeeld. Maar de machinefabrikant moet nog steeds aantonen dat het geheel veilig werkt in de werkelijke configuratie bij de klant — dus in die versie waarin iemand “zeker weten niets meer heeft gewijzigd… toch?”.

En hier ontstaat de meest voorkomende fout.

Dat is precies hetzelfde mechanisme dat we al jaren kennen uit de machineveiligheid.

Het lichtscherm heeft PL e.
De safety-PLC heeft SIL 3.
De aandrijving heeft STO.

Betekent dat automatisch dat de hele machine op datzelfde niveau zit?

Net zoals het feit dat elk onderdeel van een steiger aan de veiligheidsnormen voldoet, nog niet garandeert dat de volledige constructie stabiel is.

Nee.

Want je moet nog steeds nagaan hoe alles samenwerkt — oftewel die weinig populaire stap van “systeemdenken”, waarvoor helaas geen knop “auto-certify” bestaat.

In cyberbeveiliging is dat precies hetzelfde.

Je kunt “veilige” componenten hebben, maar in de praktijk:

• ziet de operator meer gegevens en kan hij meer wijzigen dan nodig is, omdat “dat nu eenmaal handiger was”,
• werkt één servicewachtwoord op alle machines, omdat “de service toch wel weet wat ze doet”,
• is de servicepoort toegankelijk “voor het geval dat”, dus eigenlijk voor elk denkbaar geval,
• omvat externe toegang het hele netwerk, omdat ooit iemand zei: “het is toch alleen voor diagnose”,
• kunnen updates zonder controle worden geïnstalleerd, omdat “er nog nooit iets mis is gegaan”,
• vertrouwen apparaten elkaar zonder beperkingen, omdat vertrouwen goedkoper is dan segmentatie,
• en gaat de integratie ervan uit dat niemand ooit een fout maakt, wat — zoals de geschiedenis laat zien — de meest optimistische aanname in de techniek is.

Elk onderdeel afzonderlijk kan correct zijn.

Maar het systeem als geheel kan van die correcte onderdelen iets maken dat wel werkt… alleen niet per se zoals bedoeld.

En dat is cruciaal: het risico zit niet in de apparaten zelf, maar in hun onderlinge koppeling, configuratie en in die legendarische “tijdelijk open gelaten” toegang.

CRA verlangt van de machinefabrikant meer dan het verzamelen van verklaringen alsof het trofeeën zijn. Het vereist dat wordt gecontroleerd of wat uit componenten is opgebouwd, als geheel nog steeds veilig is — en niet alleen “er goed uitziet in een conformiteitstabel”.

In de praktijk betekent dat eenvoudige, zakelijke vragen:

• heeft elke gebruiker alleen toegang tot wat hij echt nodig heeft, en niet “omdat het ooit nog van pas kan komen”,
• is externe toegang tot het minimum beperkt, of juist tot het maximum aan gemak opgerekt,
• heeft de service niet “overal volledige rechten”, omdat iemand vond dat dat het werk versnelt,
• is het netwerk niet één gemeenschappelijk vlak, omdat segmentatie “het project ingewikkelder maakt”,
• worden updates gecontroleerd uitgevoerd, of eerder volgens het principe “erin zetten en hopen op het beste”,
• kan snel worden vastgesteld welke machines blootgesteld zijn, of pas “na een incident”,
• opent een storing in één onderdeel niet meteen het hele systeem, omdat “het zo uit de integratie is gekomen”.

Dit zijn geen technische vragen “voor engineers van de moeilijke dingen”.

Dit zijn vragen over bedrijfsrisico: stilstand, kosten, aansprakelijkheid en dat kleine detail dat de productie gewoon moet blijven draaien.

Daarom is het niet genoeg om te zeggen:

“alle componenten zijn conform”

Want dat geeft nog steeds geen antwoord op de vraag:

is de hele machine veilig in werkelijk gebruik, of alleen in de PowerPoint van de projectreview?

De verklaring van de leverancier is belangrijk.

Maar die heeft slechts betrekking op één onderdeel — precies dat onderdeel dat onder laboratoriumomstandigheden is getest, en niet in een omgeving “ergens in de hal, met VPN, USB en tijdsdruk”.

Ze zegt niets over hoe het is toegepast.
Ze zegt niets over de configuratie.
Ze zegt niets over de integratie.
Ze zegt niets over beslissingen die “snel tijdens de inbedrijfstelling zijn genomen, omdat de klant wachtte”.
Ze zegt niets over wat er gebeurt na jaren van gebruik, wanneer niemand zich nog herinnert waarom iets “tijdelijk open” stond.

Daarom mag de beoordeling niet eindigen bij een lijst met apparaten.

Je moet naar het systeem als geheel kijken:

• wie heeft toegang en waarom (en niet “omdat dat altijd al zo was”),
• wat is echt nodig en wat is alleen “blijven staan omdat het niet stoorde”,
• waar kunnen gegevens buiten controle weglekken, omdat iemand vond dat “het alleen diagnose is”,
• wat gebeurt er als iemand legale toegang op een illegale manier gebruikt (dus precies zoals aanvallen verlopen),
• hoe snel kan worden gereageerd zodra er een probleem ontstaat, en niet pas “na de kwartaalreview”.

Zolang er geen antwoord is op deze vragen, hebben we alleen een set zeer degelijke componenten.

We hebben nog geen veilige machine.

Conformiteit van componenten leidt niet automatisch tot conformiteit van het systeem. De conformiteit van de machine moet worden ontworpen, gecontroleerd en — het moeilijkste van alles — in stand gehouden, ondanks de verleiding om “er niets meer aan te doen, want het werkt”.

3. Zet een cyberaanval niet zomaar op de lijst met gevaren. Verbind de twee analyses op de juiste plek

Op de machinebouwmarkt is een formele cyberbeveiligingsrisicoanalyse nog steeds eerder een uitzondering dan een standaardonderdeel van het project.

Meestal is er een industriële router.

Er is een VPN.

Er is een wachtwoord voor de PLC.

Soms is er een managed switch, waar vervolgens niemand meer iets mee beheert.

In de ambitieuzere variant krijgt de fabrikant van de leverancier een presentatie over “defence in depth” en concludeert dan dat de risicoanalyse van de cyberbeveiliging voor de hele machine daarmee is afgerond.

Dat is niet zo.

Hij heeft een paar technische maatregelen gekocht.

Dat is nog geen analyse.

Het heeft dus geen zin om het probleem te beschrijven alsof in elk project twee professionele beoordelingen worden gemaakt — één volgens ISO 12100, de andere voor cyberbeveiliging — die vervolgens alleen per ongeluk niet met elkaar zijn verbonden.

Meestal wordt er maar één opgesteld.

Risicobeoordeling van de machine.

En een cyberbeveiligingsanalyse van het product komt er helemaal niet.

Een risicobeoordeling volgens ISO 12100 bestaat er niet uit dat je in een tabel invult:

storing van de sensor → onverwachte beweging → beknelling.

Dat kan een onderdeel zijn van een concreet scenario, maar het is niet het vertrekpunt.

Eerst moeten de grenzen van de machine worden bepaald.

Wat is het beoogde gebruik?

Wat zijn de fasen van de levenscyclus?

Wie gaat de machine gebruiken?

Welke taken worden uitgevoerd tijdens transport, montage, inbedrijfstelling, productie, afstelling, reiniging, het verhelpen van storingen, onderhoud, diagnose en demontage?

In welke bedrijfsmodi kan de machine werken?

Waar bevindt de mens zich tijdens elk van deze handelingen?

Welke delen van de machine staan dan nog onder spanning, druk, belasting of zijn in beweging?

Welk gebruik is niet in overeenstemming met de handleiding, maar blijft toch redelijkerwijs voorzienbaar?

Pas daarna worden voor een concrete taak of handeling onder meer de volgende zaken geïdentificeerd:

• de gevarenbron,
• het soort gevaar,
• de gevarenzone,
• de blootgestelde persoon,
• de gevaarlijke situatie,
• de gevaarlijke gebeurtenis, als die in het betreffende scenario voorkomt,
• de mogelijke gevolgen en het soort letsel.

Zo ziet een risicoanalyse van een machine eruit.

We beginnen niet bij het component.

We beginnen bij de mens die een specifieke taak uitvoert aan een machine die zich in een bepaalde toestand bevindt. ISO 12100 legt precies deze methodiek vast voor het identificeren van gevaren en voor het schatten en beoordelen van risico’s tijdens de relevante fasen van de levenscyclus van de machine.

Laten we een eenvoudig voorbeeld nemen.

Een operator verwijdert een vastgelopen onderdeel uit de binnenzijde van een palletiseercel.

We hebben dus:

Taak: het verhelpen van een blokkade.

Gebruiksfase: exploitatie, ingreep nadat het proces is gestopt.

Bedrijfsmodus: handmatig of servicemodus.

Blootgestelde persoon: operator of medewerker van de technische dienst.

Gevarenzone: de binnenzijde van de cel, in het bijzonder de ruimte tussen grijper, onderdeel en machineconstructie.

Gevarenbron: mechanische energie van de robot, lineaire as of pneumatische grijper.

Gevaarlijke situatie: de persoon bevindt zich in de zone terwijl een beweging nog steeds mogelijk is.

Gevaarlijke gebeurtenis: onverwachte beweging van een as, sluiten van de grijper of vrijkomen van opgeslagen energie.

Mogelijk gevolg: stoten, beknelling, botbreuk of amputatie.

Pas nu kan het risico worden beoordeeld en kunnen maatregelen voor risicoreductie worden bepaald.

Er kan een vergrendeling van de afscherming nodig zijn.

Er kan een veilige stop nodig zijn.

Het kan nodig zijn om onverwacht opstarten te voorkomen.

Mogelijk moet pneumatische energie worden afgevoerd.

Mogelijk mag beweging in handmatige modus uitsluitend plaatsvinden met een toestemmingsschakelaar en veilig begrensde snelheid.

Dit is nog steeds een klassieke risicobeoordeling van een machine.

Waar komt cyberbeveiliging dan in beeld?

Niet als een nieuwe post naast mechanisch, elektrisch en thermisch gevaar.

“Een hacker” is geen bron van mechanisch gevaar

Het toevoegen van de volgende post aan een ISO 12100-tabel:

Gevaar: cyberaanval

voegt weinig toe.

Een cyberaanval is geen roterende as, scherpe rand, hoge temperatuur of pneumatische energie.

Het is ook geen afzonderlijke gevarenzone.

Een operator raakt niet bekneld door een CVE-kwetsbaarheid.

Dat gebeurt door een machineonderdeel dat een beweging uitvoert terwijl de persoon zich op de verkeerde plaats bevindt.

Een cyberaanval kan daarentegen wel de toestand van het besturingssysteem, gegevens, het programma, de configuratie of de werking van een beschermingsmaatregel veranderen.

Daardoor kan die aanval worden:

• de oorzaak van een gevaarlijke gebeurtenis,
• een extra route die leidt tot een gevaarlijke situatie,
• de oorzaak van verlies van effectiviteit van een maatregel voor risicoreductie,
• of een manier om de aannames te omzeilen die bij het ontwerp van veiligheidsfuncties zijn gemaakt.

En dat is precies het juiste raakvlak.

Niet de gevarenlijst.

Maar het gedrag van de machine.

De cyberbeveiligingsanalyse moet afzonderlijk worden opgesteld

Voor een machine of automatiseringssysteem zal een cyberbeveiligingsanalyse een andere structuur hebben dan een risicobeoordeling volgens ISO 12100.

Voor een industrieel automatiseringssysteem biedt IEC 62443-3-2 de meest natuurlijke structuur.

De norm vereist onder meer:

• het definiëren van het systeem dat aan de analyse wordt onderworpen, dus de SUC,
• het opdelen van het systeem in zones en communicatiekanalen,
• het beoordelen van risico’s voor de afzonderlijke zones en kanalen,
• het vaststellen van de beoogde beveiligingsniveaus SL-T,
• het documenteren van de beveiligingseisen.

Dat is een volledig ander vertrekpunt dan in ISO 12100.

In IEC 62443 stellen we onder meer de volgende vragen:

Wat behoort precies tot het geanalyseerde systeem?

Welke assets moeten worden beschermd?

Welke apparaten, applicaties en interfaces bevinden zich in het systeem?

Welke elementen moeten tot dezelfde zone behoren?

Hoe verloopt de communicatie tussen de zones?

Wie kan toegang krijgen?

Vanaf welke locatie?

Via welke interface?

Welke kwetsbaarheden kunnen worden misbruikt?

Welke gegevens, functies of componenten kunnen worden gewijzigd?

Via welk pad kan een aanvaller van de servicerouter naar de PLC, HMI, aandrijving of engineeringstation doordringen?

Wat zijn de gevolgen van verlies van vertrouwelijkheid, integriteit of beschikbaarheid?

Welke beveiligingsmaatregelen zijn nodig?

Voor het proces van veilige productontwikkeling en voor de eisen aan de componenten zelf zijn ook andere delen van de reeks van belang, met name IEC 62443-4-1 en IEC 62443-4-2. IEC 62443-3-3 structureert op zijn beurt de technische beveiligingseisen op systeemniveau.

CRA verplicht een fabrikant vandaag niet om op de omslag van de analyse te zetten: “uitgevoerd volgens IEC 62443”.

IEC 62443 vervangt ook niet het aantonen van conformiteit met de eisen van de CRA.

Voor een industrieel automatiseringssysteem is dit echter een veel logischer referentiekader dan proberen een paar hackerscenario’s toe te voegen aan een tabel volgens ISO 12100.

Dat komt doordat beide methodieken andere vragen beantwoorden.

ISO 12100:

Tijdens welke taak, waar, door welke bron en als gevolg van welke gebeurtenis kan een mens letsel oplopen?

IEC 62443:

Wie kan via welke weg en met gebruik van welke kwetsbaarheid invloed uitoefenen op het systeem, de gegevens of de functies ervan?

Pas daarna moet worden nagegaan of het antwoord uit de tweede analyse het scenario uit de eerste verandert.

Hetzelfde scenario, twee verschillende analyses

Laten we teruggaan naar de operator die een vastgelopen onderdeel verwijdert.

De analyse volgens ISO 12100 heeft aangetoond dat iemand de zone betreedt waar hij door de beweging van de robot of grijper bekneld kan raken.

De risicoreducerende maatregel is een vergrendelde afscherming, een veilige stopfunctie en een lokale reset buiten de gevarenzone.

Nu voeren we een cyberbeveiligingsanalyse van het systeem uit.

We identificeren:

• de router die voor service op afstand wordt gebruikt,
• het serviceaccount,
• de engineeringlaptop,
• de HMI,
• de standaard-PLC,
• de safety PLC,
• de aandrijvingen,
• de programmeerinterface,
• het PROFINET-netwerk en de PROFIsafe-communicatie,
• de mechanismen voor het laden van programma’s en configuraties.

We beschouwen het volgende scenario:

Overname van het serviceaccount maakt toegang op afstand tot de standaard-PLC mogelijk en het verzenden van een bewegingscommando terwijl zich een persoon in de cel bevindt.

Leidt dit scenario tot een gevaarlijke gebeurtenis?

Die vraag is niet te beantwoorden op basis van alleen het feit dat de PLC is overgenomen.

Daarvoor moet de architectuur van de veiligheidsfuncties worden gecontroleerd.

Als het openen van de afscherming wordt bewaakt door de safety PLC, de functie het aandrijfkoppel veilig uitschakelt, de reset uitsluitend lokaal mogelijk is en de standaard-PLC de beweging niet kan herstellen onafhankelijk van de toestand van de veiligheidsfunctie, dan kan overname van de standaardbesturing de productie stilleggen of het proces verstoren.

Maar het zou geen beweging mogen veroorzaken bij geopende afscherming.

In dat geval toont de cyberanalyse een aanval aan.

De risicobeoordeling van de machine toont een mechanisch gevaar aan.

Een correct ontworpen veiligheidsfunctie doorbreekt echter het pad tussen beide.

En nu de tweede variant.

De servicemodus wordt geselecteerd via een gewone HMI.

De waarde van de beperkte snelheid komt uit de standaard-PLC.

De servicemonteur op afstand kan een reset uitvoeren.

Met hetzelfde engineeringaccount kunnen zowel het standaardprogramma als de safety-configuratie worden gewijzigd.

De back-up van het safety-programma is niet gekoppeld aan een specifieke machineversie.

Na de interventie controleert niemand de controlesom.

De aandrijfparameters kunnen op afstand worden gewijzigd.

In deze architectuur betekent overname van het account niet langer alleen verlies van vertrouwelijkheid of een korte stilstand.

Het kan de voorwaarden veranderen waarop de risicoreductie was gebaseerd.

Het kan leiden tot:

• selectie van een onjuiste modus,
• wijziging van een parameter voor veilige beweging,
• een ongeautoriseerde reset,
• het laden van een niet-goedgekeurde configuratie,
• of verzwakking van de functie die onverwacht opstarten moest voorkomen.

En dan moet het cyberscenario worden gekoppeld aan een concreet machineveiligheidsscenario:

taak: vastloper verhelpen → persoon in de gevarenzone → ongeautoriseerde wijziging van het besturingssysteem of de beschermingsfunctie → onverwachte beweging → beknelling.

De bron van het gevaar is niet veranderd.

Dat is nog steeds de mechanische energie van de machine.

De gevarenzone is niet veranderd.

Die bevindt zich nog steeds binnen de cel.

Ook het mogelijke gevolg is niet veranderd.

Dat blijft letsel van de operator.

Wel is het pad veranderd dat naar de gevaarlijke gebeurtenis leidt.

Niet elke kwetsbaarheid hoort in ISO 12100 thuis

Ook dit onderscheid is belangrijk.

Stel dat een kwetsbaarheid in de HMI het mogelijk maakt historische productiegegevens uit te lezen.

Dat kan vanuit het oogpunt van de CRA een relevant probleem zijn.

Het kan de vertrouwelijkheid van gegevens schenden.

Het kan een update, een impactbeoordeling, maatregelen richting gebruikers en onder bepaalde omstandigheden ook rapportage vereisen.

Maar als dit geen invloed heeft op het gedrag van de machine, geen beschermende maatregel verandert en niet tot een gevaarlijke situatie kan leiden, heeft het geen zin om het in de risicobeoordeling volgens ISO 12100 te persen.

Op dezelfde manier kan een aanval die uitsluitend leidt tot onbeschikbare productierapporten een bedrijfsprobleem én een complianceprobleem onder de CRA zijn.

Dat hoeft echter geen risico voor de operator op te leveren.

Omgekeerd kan een ogenschijnlijk onschuldige mogelijkheid om één setpoint te wijzigen weinig betekenen voor de vertrouwelijkheid van gegevens, maar enorme gevolgen hebben voor de fysieke veiligheid.

Bijvoorbeeld wanneer die waarde het volgende bepaalt:

• de maximale assnelheid,
• de aandrukkracht,
• de procestemperatuur,
• de druk,
• de stoppositie,
• de openingstijd van een klep,
• of de toegestane grens tijdens werken met open afscherming.

We classificeren een cyberdreiging dus niet op basis van hoe technisch die klinkt.

We kijken naar wat die in werkelijkheid met de machine kan doen.

De machineverordening dwingt deze brug af

Deze koppeling is niet alleen een kwestie van goede engineeringpraktijk.

Punt 1.2.1 van bijlage III bij de machineverordening vereist dat besturingssystemen zo worden ontworpen en gebouwd dat gevaarlijke situaties worden voorkomen, ook als gevolg van redelijkerwijs te voorziene kwaadwillige handelingen van derden.

De CRA geeft op zijn beurt aan dat de essentiële cyberbeveiligingseisen kunnen bijdragen aan het aantonen van conformiteit, onder meer met de eisen 1.1.9 en 1.2.1 van de machineverordening.

Maar dat gebeurt niet automatisch.

De fabrikant moet dat verband aantonen op basis van een risicobeoordeling. De conformiteitsbeoordeling volgens de CRA en de conformiteitsbeoordeling volgens de machineverordening blijven nog steeds afzonderlijke processen.

Met andere woorden: het is niet genoeg om het volgende op te stellen:

• een risicobeoordeling volgens ISO 12100,
• een IEC 62443-analyse,
• twee aparte rapporten,
• en erop te vertrouwen dat de overeenkomst in normnummers vanzelf een audit trail tussen beide creëert.

Er is een koppeling nodig.

Voor elk relevant cyberscenario moet worden vastgesteld:

1. welk onderdeel of welke functie kan worden overgenomen of gewijzigd,
2. welk machinegedrag daardoor kan ontstaan,
3. of dat gedrag leidt tot een gevaarlijke situatie of een gevaarlijke gebeurtenis,
4. op welke taak en welke gevarenzone dit betrekking heeft,
5. welk mogelijk gevolg in de ISO 12100-beoordeling is vastgesteld,
6. welke risicoreducerende maatregel de verdere ontwikkeling van het scenario moet stoppen,
7. of die maatregel nog doeltreffend blijft nadat het aangevallen onderdeel is overgenomen.

Dat laatste punt is het belangrijkst.

Want als de aanval en de beveiliging afhankelijk zijn van:

• dezelfde controller,
• hetzelfde account,
• hetzelfde netwerk,
• hetzelfde engineeringstation,
• of hetzelfde programma,

dan hebben we mogelijk geen twee onafhankelijke beschermingslagen.

Dan hebben we één laag die in twee documenten is beschreven.

We hebben dus geen enorme tabel nodig met de naam:

“risicobeoordeling safety & cybersecurity”.

We hebben twee correcte analyses nodig, uitgevoerd met de juiste methoden, plus een beheerst raakvlak ertussen.

ISO 12100 moet de mens, de taak, de gevarenbron, de zone, de gevaarlijke situatie, de gevaarlijke gebeurtenis en de mogelijke schade beschrijven.

IEC 62443 moet helpen om het systeem, de zones, de communicatiekanalen, de assets, de dreigingen, de kwetsbaarheden, de aanvalspaden en de vereiste beveiligingsmaatregelen te beschrijven.

En de fabrikant moet aantonen of een scenario uit de tweede analyse een scenario uit de eerste kan activeren, of de doeltreffendheid kan wegnemen van de maatregel die dat scenario juist moest stoppen.

Een cyberaanval hoeft geen nieuw gevaar te creëren. Het is al genoeg als die een nieuwe route opent naar een oud ongeval.

4. Een pentest vóór FAT is een foto. De CRA vereist een film

In veel projecten komt cyberbeveiliging pas twee weken vóór FAT in beeld.

Er wordt een pentest besteld.

Er komt een rapport.

Kritieke kwetsbaarheden worden verholpen, middelzware worden geaccepteerd en het document belandt in de projectmap.

De machine is cyberveilig.

Tot volgende week dinsdag.

Een pentest kan een zeer waardevol onderdeel van de verificatie zijn. Maar die laat alleen de toestand zien van een specifieke productversie, in een specifieke configuratie en op basis van bepaalde testscenario’s.

Die geeft geen antwoord op de vraag wat de fabrikant daarna gaat doen.

En de CRA heeft betrekking op de volledige levenscyclus van het product. De cyberbeveiligingsrisicobeoordeling moet doorwerken in de planning, het ontwerp, de ontwikkeling, de productie, de levering en het onderhoud van het product. Nadat het op de markt is gebracht, moet de fabrikant kwetsbaarheden afhandelen gedurende de opgegeven ondersteuningsperiode.

Laten we teruggaan naar de groenteverpakkingsmachine.

De machine heeft FAT doorstaan.

De pentest heeft geen kritieke kwetsbaarheden aangetoond.

Acht maanden later publiceert de fabrikant van de servicerouter informatie over een kwetsbaarheid waarmee het apparaat kan worden overgenomen.

En dan begint het echte werk.

Welke geleverde machines hebben dit routermodel?

Welke firmwareversie is in elk exemplaar geïnstalleerd?

Is externe toegang actief?

Kan de kwetsbaarheid in de werkelijke configuratie worden misbruikt?

Geeft overname van de router uitsluitend toegang tot diagnose, of ook tot HMI, PLC, aandrijvingen en safety PLC?

Is alleen het uitlezen van gegevens mogelijk, of ook het wijzigen van het programma of parameters?

Kan de aanval invloed hebben op de veiligheidsfunctie?

Heeft de leverancier een patch beschikbaar gesteld?

Verandert een update van de router de certificaten, communicatieregels of de manier waarop de tunnel wordt opgezet?

Moeten na een update de remote service, de communicatie en een deel van de veiligheidsfuncties opnieuw worden gecontroleerd?

Welke klanten moeten worden geïnformeerd?

En voldoet de situatie aan de criteria voor melding van een actief uitgebuite kwetsbaarheid of een ernstig incident?

Een pentestrapport dat vóór de FAT is opgesteld, geeft op geen van deze vragen antwoord.

Het beschrijft een machine die niet meer bestaat.

Sinds het onderzoek zijn namelijk de softwareversies, configuraties, de gebruikersomgeving en de kennis over kwetsbaarheden veranderd.

Daarom heeft de fabrikant niet alleen een test nodig, maar een proces:

• voor het identificeren van hardware-, firmware- en softwareversies in elk geleverd exemplaar,
• voor het monitoren van informatie over kwetsbaarheden,
• voor het beoordelen van de toepasbaarheid ervan in de werkelijke architectuur,
• voor het nagaan van de mogelijke gevolgen voor het proces en de veiligheid van de machine,
• voor het voorbereiden en testen van updates,
• voor het informeren van gebruikers,
• voor het documenteren van genomen beslissingen,
• voor het afhandelen van vereiste meldingen.

Vanaf 11 september 2026 zijn fabrikanten verplicht actief uitgebuite kwetsbaarheden en ernstige incidenten te melden die gevolgen hebben voor de veiligheid van producten met digitale elementen. Een eerste waarschuwing moet binnen 24 uur worden doorgegeven en een volledige melding binnen 72 uur.

Dat betekent dat er na het ontdekken van een probleem geen tijd meer is om pas dan te gaan uitzoeken:

“Wie heeft die router eigenlijk gemaakt en waar hebben we de lijst van machines waarin we hem hebben ingebouwd?”

IEC 62443-4-1 laat goed het verschil zien tussen een eenmalige beveiliging van een product en een veilige ontwikkelcyclus. De norm omvat niet alleen ontwerp en verificatie, maar ook het beheer van defecten, patches en het einde van de levensduur van het product.

De FAT kan dus een projectfase afsluiten.

Maar niet de levenscyclus van het product.

Niet de ondersteuningsperiode.

Niet het monitoren van kwetsbaarheden.

En ook niet dat de configuratie van de dag van oplevering voor de komende vijftien jaar wordt bevroren.

De machine kan lange tijd groenten verpakken voor supermarkten.

De fabrikant kan de cyberbeveiliging ervan echter niet samen met de handleiding inpakken, in folie sealen en aannemen dat die daarmee voorgoed is geleverd.

Een pentest kan een punt op de FAT-lijst afvinken. De CRA opent een proces dat doorloopt tot het einde van de ondersteuningsperiode van het product.