28 juli 2026 | Voor de technische dienst en de productieleiding

Wie heeft toegang tot uw machines?

Stel de vraag eens op een willekeurige maandagochtend: wie kan er op dit moment inloggen op de besturing van lijn 3? Meestal volgt een stilte, en daarna een lijstje dat langer wordt naarmate men langer nadenkt. De ploeg. De TD. Die ene engineer die twee jaar geleden is vertrokken. En de machinebouwer, want die had toch een verbinding voor storingen?

Dat lijstje is het echte antwoord op de vraag of uw productieomgeving beveiligd is. Niet het beleidsdocument, niet de firewall, maar de vraag wie er vanmiddag binnen zou komen als hij dat wilde.

Waarom toegangsbeheer in productie anders werkt dan op kantoor

Op kantoor is dit opgelost. Iedereen heeft een account, dat account hangt aan een centrale administratie, en als iemand uit dienst gaat wordt het uitgezet. Eén handeling, klaar.

Op de vloer geldt vrijwel niets daarvan:

• De machine kent uw gebruikersadministratie niet. Een HMI heeft eigen accounts, vaak drie: operator, onderhoud en engineering. Die staan lokaal op het paneel en weten niets van wie er bij u in dienst is.
• Werken moet altijd doorgaan. Om drie uur 's nachts bij een storing wil niemand een wachtwoord kwijt zijn. Daarom staat het op een briefje in de kast, en daar begint het.
• De leverancier moet erbij kunnen. Voor garantie, voor storingen, voor updates. Die toegang is een keer aangelegd en daarna nooit meer bekeken.
• Vervanging is duur. Een besturing van twaalf jaar oud ondersteunt geen moderne authenticatie, en de machine vervangen om die reden alleen is niet uit te leggen.

Dat is geen slordigheid. Dat is een omgeving waarin beschikbaarheid voorgaat, en dat is de juiste prioriteit voor een fabriek. Het probleem is niet dat het zo gegroeid is, maar dat vrijwel niemand in kaart heeft hoe het er nu voor staat.

De vier plekken waar het in de praktijk misgaat

1. Het gedeelde account op de lijn

Eén login voor de hele ploeg. Praktisch, en meestal ooit bewust zo ingericht. Twee gevolgen die u moet kennen:

• Na een incident kunt u niet zien wie wat gedaan heeft. Alle handelingen staan op naam van hetzelfde account, dus uw logboek vertelt niets.
• Het wachtwoord verdwijnt niet als iemand vertrekt. Wie er ooit mee gewerkt heeft, kan er in principe nog steeds mee inloggen.

Een gedeeld account is niet per definitie fout. Er zijn situaties waarin het de enige werkbare optie is. Maar dan hoort u te weten dat u geen herleidbaarheid heeft, en hoort het wachtwoord om te gaan bij personeelswissels. Dat laatste is de goedkoopste maatregel op deze hele pagina.

2. Het standaardwachtwoord dat er nog op staat

Nieuwe apparatuur komt binnen met een standaardwachtwoord uit de handleiding. Voor een switch, een converter of een IO-module wordt dat vaak nooit gewijzigd, omdat het ding "toch alleen intern" hangt. Die handleidingen staan online.

Dit is de meest gebruikte manier om ergens binnen te komen, en tegelijk de goedkoopste om te repareren. Begin bij wat u het laatst heeft geplaatst, want daar is de kans het grootst dat niemand eraan gedacht heeft.

3. De leverancier die nog steeds binnen kan

Voor een storing is ooit een verbinding aangelegd. Die staat er nog. Niemand weet precies wie er aan de andere kant meekijkt, of dat het account daar nog bij dezelfde persoon hoort.

Wat u wilt is toegang die op verzoek aangaat, herleidbaar is naar een persoon, en weer dichtgaat. Dat is geen technisch project maar een afspraak, en die afspraak wordt eenvoudiger zodra u kunt laten zien welke verbindingen er nu openstaan.

Er komt hier bovendien druk van buiten bij. Valt uw opdrachtgever onder de Cyberbeveiligingswet, dan moet hij op grond van het Cyberbeveiligingsbesluit (artikel 10 lid 2) zijn directe leveranciers periodiek toetsen. Die vragenlijst komt dan bij u terecht, en dit is een van de vragen die erin staat.

4. De fysieke toegang tot de kast

Toegangsbeheer gaat niet alleen over inloggen. Een besturingskast die openstaat, is toegang. Kasten staan vaak open voor de koeling, of omdat de sleutel kwijt is en niemand er ooit werk van heeft gemaakt.

Dit is de enige maatregel op deze pagina die u vanmiddag kunt afronden: loop de kasten langs en maak een sleutelplan.

Wat de Cyberbeveiligingswet er wel en niet over zegt

De Cyberbeveiligingswet (Stb. 2026, 187) treedt op 15 augustus 2026 in werking. Artikel 21 vraagt passende en evenredige maatregelen, en noemt daarbij expliciet beleid voor toegangsbeheer.

Let op wat daar niet staat. Er staat geen techniek voorgeschreven. Geen verplichte tweefactorauthenticatie, geen verbod op gedeelde accounts, geen minimale wachtwoordlengte. U mag zelf bepalen wat passend is voor uw situatie.

Wat u wel moet kunnen: uitleggen waarom uw keuze passend is. En daar wringt het. "Wij werken met een gedeeld account omdat een storing om drie uur 's nachts geen wachtwoordgedoe verdraagt, het wachtwoord gaat om bij elke personeelswissel, en handelingen aan de besturing loggen we apart" is een verdedigbaar verhaal. "Er staat een account op en dat is altijd zo geweest" is dat niet.

Waar u morgen mee begint

Niet met beleid. Beleid schrijven zonder te weten hoe het er nu voor staat, levert een document op dat niemand leest en dat bij de eerste vraag onderuitgaat. Begin met de inventarisatie, in deze volgorde:

1. Wie kan er nu binnen? Per lijn: welke accounts bestaan er op de HMI's en de besturing, en wie kent die wachtwoorden. Een A4 per lijn is genoeg.
2. Welke verbindingen van buiten staan open? VPN's, remote-support-software, modems in kasten. Van elke verbinding: van wie, waarvoor, en staat hij permanent aan.
3. Waar staat nog een standaardwachtwoord op? Begin bij de apparatuur die het laatst is geplaatst.
4. Welke kasten kan iedereen openen? Rondje door de hal, sleutelplan erbij.
5. Pas daarna: leg vast wat u doet en waarom. Nu heeft u iets om over te schrijven, en is het beleid een beschrijving van de werkelijkheid in plaats van een wens.

Wat software hieraan kan doen, en wat niet

Eerst het eerlijke deel: geen enkel softwarepakket lost het accountbeheer op uw machines op. Die accounts staan op de besturing, en daar komt uw onderhoudssysteem niet bij. Wie u anders vertelt, verkoopt u iets.

Wat software wel doet, is de laag eromheen. Wie een werkvergunning afgeeft, wie een LOTO-stap aftekent, wie een procedure heeft aangepast: dat kan wel per persoon vastliggen, en dat is precies wat u nodig heeft als er iets misgaat en de vraag komt wie wat heeft gedaan.

In RaconWorks is dat als volgt geregeld, en u mag ons daaraan houden:

• Zes rollen, van werkvoorbereider tot beheerder, elk met eigen rechten.
• Begrenzing per locatie. Een beheerder van de ene vestiging komt niet bij de gegevens van een andere. Dat is afgedwongen in de beveiligingsregels van de database zelf, niet in de app, en het is vastgelegd in geautomatiseerde tests. De onderbouwing staat in de security briefing.
• Een auditlogboek dat niet te wijzigen is, met per regel wie, wat, waar en wanneer.
• Onbeperkt gebruikers voor een vaste prijs. Dit is geen bijzaak: zodra een licentie per gebruiker rekent, wordt een gedeeld account financieel aantrekkelijk. Dan werkt uw software tegen uw beveiliging in.

Wat het niet doet: uw HMI-wachtwoorden beheren, uw netwerk segmenteren of uw leverancier buitensluiten. Dat blijft mensenwerk en netwerkwerk.

Over dit stuk

Geschreven door Ritchel Akwali. Ik werk als besturingstechnicus in een productiebedrijf en bouw daarnaast software voor de technische dienst. De situaties hierboven komen uit dat werk, niet uit een adviesrapport.

Klopt er iets niet, of herkent u een situatie die er niet bij staat? Laat het weten via info@raconsoft.nl. Dan wordt dit stuk beter.