IT en OT: de 5 duurste fouten op de fabrieksvloer

26 juli 2026 | Geschreven door iemand die als besturingstechnicus in een productiebedrijf werkt

Als een productielijn stilstaat, wijst iedereen eerst naar de techniek. Vaak ligt de oorzaak ergens anders: in de structurele misverstanden tussen de IT-afdeling op kantoor en de technische dienst op de vloer. Twee groepen die allebei hun werk goed doen, en die elkaar systematisch in de weg zitten.

Reken zelf even mee. Wat kost een uur stilstand op uw drukste lijn, alles bij elkaar: gemiste productie, personeel dat wacht, orders die schuiven? Dat getal is het budget waarmee u de rest van dit stuk moet lezen. Bij het ene bedrijf is het een paar honderd euro, bij het andere loopt het in de tienduizenden. Dat verschil bepaalt welke van de vijf fouten hieronder u zich kunt permitteren.

Fout 1: de virtualisatieval, oftewel de zwarte doos

De wens van kantoor: alles op een centrale server of in de cloud. Efficienter, beter uitbreidbaar, en het belangrijkste: we kunnen het centraal back-uppen. De logica lijkt waterdicht.

Wat er op de vloer gebeurt: het bedieningsscherm loopt vast en de lijn staat stil. De monteur, een vakman maar geen systeembeheerder, kan er niet meer bij. De server is voor hem een zwarte doos. Hij maakt een ticket aan en wacht op een afdeling die niet is ingericht op wat een uur productiestilstand kost.

Het risico dat niemand benoemt: om die centrale back-up mogelijk te maken, wordt de fabrieksomgeving gekoppeld aan het kantoornetwerk. Een aanvaller richt zich altijd eerst op dat kantoornetwerk, want daar zit e-mail. Is hij binnen, dan ligt er door die koppeling een rechte lijn van een besmette kantoor-pc naar het hart van de productie. De maatregel die bescherming moest bieden, is de route naar binnen geworden. En de back-up waar het allemaal om begon, is nu zelf het doelwit.

Fout 2: het kaartenhuis, oftewel de ene kabel

De pijn: de halve fabriek valt stil door een probleem met een netwerkkabel of een centrale switch. Een vastgelopen server, een defecte poort. Dat is de definitie van een single point of failure.

De nuchtere analyse: dit is zelden een technische fout. Het is bijna altijd een zakelijke beslissing geweest. Een dubbel uitgevoerd netwerk kost meer in aanschaf, en die post sneuvelt vrijwel altijd in de offertefase.

De stilstand van de halve fabriek is dus niet de schuld van de kabel. Het is de uitkomst van een businesscase die de operationele kosten negeerde om te besparen op de aanschaf.

Fout 3: waarom Windows XP voor de fabriek een succesverhaal is

Hier zit de fundamentele botsing, en het is geen kwestie van gelijk hebben.

IT werkt met een levenscyclus van drie tot vijf jaar en zet vertrouwelijkheid bovenaan. Voor OT geldt een levensduur van vijftien tot dertig jaar en staat beschikbaarheid bovenaan. Beide volgorden zijn juist voor hun eigen domein.

Een IT-beheerder ziet een bedieningspaneel op Windows XP en noemt het verouderd en onveilig. Terecht, vanuit zijn kader. Maar voor de technische dienst is datzelfde paneel het bewijs dat een investering van twintig jaar geleden nog steeds geld oplevert. De software zit vast aan de machine en de machineleverancier ondersteunt niets anders.

Een mogelijk datalek in de toekomst weegt in die afweging niet op tegen het zekere verlies van een fabriek die uren stilligt. De weerstand van de technische dienst is geen koppigheid. Het is een risicoafweging die is gebaseerd op wat er gebeurt als het misgaat.

Fout 4: de patchruzie

IT weegt de waarschijnlijkheid van een hack. OT weegt de zekerheid van productieverlies door de patch zelf.

Dat is de hele discussie in een zin, en beide partijen hebben gelijk.

Patchen vereist geplande stilstand die geld kost. Het is soms niet toegestaan door de machineleverancier, waardoor de garantie of de certificering vervalt. Het kan een stabiel systeem van tien jaar oud laten crashen. En voor veel oude systemen bestaan er domweg geen patches meer.

Dat is precies waarom de zorgplicht uit de Cyberbeveiligingswet niet vraagt of u alles patcht, maar of u weet welke systemen wel en niet gepatcht kunnen worden, en wat u doet waar het niet kan. Die laatste vraag is het antwoord dat u op een leveranciersvragenlijst moet geven, en de meeste vragenlijsten hebben er geen hokje voor.

Fout 5: edge of cloud

Het IT-standpunt: data moet naar de cloud, want voorspellend onderhoud en analyse vragen om een centrale, schaalbare plek waar productiedata en ERP-data samenkomen.

Het OT-standpunt: verwerking moet lokaal, want de vertraging van een cloudverbinding is onacceptabel voor een besturingslus die in milliseconden moet reageren.

De vraag eronder is wat data primair moet dienen: lokale sturing of centrale analyse. Het antwoord is meestal allebei, op verschillende plekken, en dan is de discussie waar de grens ligt en niet wie gelijk heeft.

Van conflict naar samenwerking: vijf regels

1. Stop met tegenstrijdige doelen

De botsing ontstaat omdat IT wordt afgerekend op het percentage uitgevoerde patches en OT op de beschikbaarheid van de lijn. Twee doelen die elkaar per definitie bijten.

Vervang beide. Meet bij OT niet de beschikbaarheid maar de veilige beschikbaarheid, dus de uptime minus de uitval door beveiligingsincidenten. Meet bij IT niet het aantal patches maar het aantal opgeloste kritieke risico's. En richt een maandelijks overleg in dat werkelijk knopen mag doorhakken.

2. Respecteer elkaars volgorde

Beide prioriteringen zijn juist voor hun eigen domein. Voer risicoanalyses daarom gezamenlijk uit, en weeg de technische ernst af tegen de operationele werkelijkheid, inclusief de schade van de oplossing zelf. Leg vast dat OT langere patchcycli mag hanteren, mits er iets anders tegenover staat.

3. Gebruik normen als gereedschap, niet als wapen

Beveiliging is er niet om verbindingen te voorkomen, maar om ze zo veilig mogelijk te maken. Het Purdue-model en IEC 62443 geven daarvoor een gedeelde taal.

In de praktijk komt het op drie dingen neer. Deel het netwerk op in zones en conduits volgens IEC 62443, zodat een probleem in een zone niet de hele fabriek meeneemt. Maak een gedemilitariseerde zone, in het Purdue-model niveau 3,5, als enige gecontroleerde doorgang tussen kantoor en fabriek. En zet compenserende maatregelen in waar patchen onmogelijk is, bijvoorbeeld door een kwetsbaarheid af te schermen met een netwerkregel in plaats van de machine aan te raken.

Wat vaak over het hoofd wordt gezien: IEC 62443 wordt gezien als een beveiligingsnorm, maar om hem toe te passen moet u het netwerk opdelen in zones en daarvoor in kaart brengen welke onderdelen van elkaar afhankelijk zijn. Dat proces legt vanzelf alle single points of failure bloot, precies het probleem uit fout 2. De norm is dus net zo goed een betrouwbaarheidsnorm.

4. Wijs een vertaler aan

Projecten lopen vast bij gebrek aan iemand die beide talen spreekt: die zowel de beveiligingskant begrijpt als de industriele protocollen, en die weet wat een productieproces vraagt.

Bepaal of dat een interne rol is, een team, of iemand van buiten. En geef die persoon mandaat, anders is het een adviseur zonder gevolgen.

5. Stuur elkaar op cursus

Laat IT-beheerders een dag meelopen op de vloer, zodat ze zien wat stilstand betekent. Geef de technische dienst een basistraining over cyberdreigingen, zodat die niet abstract blijven.

Kiest u toch voor centralisatie, dan wordt dit een harde eis en geen goed voornemen. De monteur moet zelfstandig kunnen vaststellen of een virtuele machine draait en of de host verbinding heeft. En de IT-beheerder moet zijn ticketmentaliteit loslaten zodra er een alarm van een productielijn binnenkomt. Leg dat vast in een afspraak met een responstijd erin.

Voordat u een project start

Loop deze vragen langs voordat er iets wordt getekend. Ze zijn geordend naar wie ze moet beantwoorden.

Directie en management

• Wat is het concrete, meetbare doel van dit project?
• Is er steun en budget van zowel de IT-kant als het hoofd technische dienst of de plantmanager?
• Wie is de aangewezen vertaler, en heeft die mandaat van beide kanten?
• Is er tijd vrijgemaakt voor een gemengd team van IT, techniek en operators?

Projectleiding

• Is er een gezamenlijke risicoanalyse gedaan die zowel stilstandkosten als cyberrisico weegt?
• Wat is het escalatiepad buiten kantooruren?
• Wie hakt de knoop door bij een conflict tussen productie stilleggen en een risico accepteren?
• Hoe en hoe vaak spreken de IT- en OT-mensen elkaar formeel?

Techniek

• Is er een actuele, complete inventarisatie van alle betrokken assets, inclusief de besturingssystemen die erop draaien?
• Is het netwerkontwerp, inclusief segmentatie, DMZ en firewallregels, goedgekeurd door zowel beveiliging als de mensen die de machines onderhouden?
• Is het ontwerp expliciet getoetst op single points of failure? Zijn kritieke onderdelen dubbel uitgevoerd, en is dat zakelijk goedgekeurd of alsnog weggestreept?
• Bij virtualisatie: wat is het supportmodel buiten kantooruren, is de technische dienst getraind voor eerste diagnose, en welke responstijd is afgesproken?
• Wat is het plan om terug te draaien als het misgaat?

Het woordenboek

Geen encyclopedie, maar de termen die in een gesprek tussen kantoor en vloer daadwerkelijk misverstanden veroorzaken.

Voor de systeembeheerder: de taal van de vloer

• PLC. De industriele computer die een machine aanstuurt. Geen pc. Hij verwacht een voorspelbaar netwerk en is gevoelig voor gewone IT-handelingen: een standaard netwerkscan kan de processor overbelasten en de productie stilleggen. Levensduur vijftien tot dertig jaar.
• SCADA. Het systeem dat processen op hoger niveau bewaakt en aanstuurt. Ongecoordineerd patchen van een SCADA-server kan een fabriek in een onstabiele toestand brengen.
• HMI. Het bedieningsscherm waarmee een operator een machine bedient. Vaak het meest zichtbare beeldscherm in de fabriek, en vaak draaiend op een verouderd besturingssysteem omdat de software vastzit aan de machine.
• DCS. Een geintegreerd besturingssysteem voor een grote, continue installatie, zoals in de chemie. Kritisch voor de veiligheid. Ongeplande ingrepen zijn hier uitgesloten.
• Latency en jitter. Niet alleen vertraging telt, maar vooral de variatie erin. Een gewoon IT-netwerk doet zijn best; een robotcel heeft zekerheid nodig. Variatie in vertraging kan leiden tot machines die fysiek op elkaar botsen.

Voor de monteur: de taal van kantoor

• ERP. Het centrale systeem voor financien, inkoop, voorraad en planning. Wat u op de vloer registreert, is de brandstof daarvoor.
• API. Een afgesproken manier waarop twee systemen gegevens uitwisselen. Dit is hoe uw machinegegevens gecontroleerd naar kantoor gaan, in plaats van via een export in Excel.
• DMZ. Een bufferzone tussen kantoor en fabriek: de enige gecontroleerde doorgang. Dit voorkomt dat gijzelsoftware van een kantoor-pc rechtstreeks bij de besturing komt.
• Netwerksegmentatie of VLAN. Het opdelen van een groot netwerk in gescheiden stukken. Een plat netwerk waar alles bij alles kan is kwetsbaar. Segmentatie beperkt hoe ver een probleem zich verspreidt, en beschermt daarmee juist de beschikbaarheid.

Gedeelde termen

• MES. De laag tussen planning en uitvoering, tussen ERP en de PLC's. Vergt samenwerking van beide kanten, want het raakt allebei.
• Edge computing. Gegevens verwerken dicht bij de bron in plaats van alles naar de cloud sturen. Dit is het compromis uit fout 5: real-time waar het moet, centraal waar het kan.
• Purdue-model. Geen theorie maar een plattegrond van de fabriek, in niveaus. Niveau 0 tot 2 is de vloer, niveau 4 en 5 is kantoor, en de DMZ op niveau 3,5 is de sluis ertussen.

Over dit stuk

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

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