IEC 62443 & RTLS — OT cybersecurity.
RTLS is operationele technologie. Het werkt naast je PLC's, SCADA, MES en historian, en het compromis ervan kan zich uitbreiden tot productie.
IEC 62443 is het raamwerk dat de meeste enterprise OT-teams gebruiken om het te scopen en te beveiligen. Dit is de samenvatting op operatorniveau.
Het Purdue-model en waar RTLS woont
IEC 62443 erft de Purdue Enterprise Reference Architecture: een gelaagd model waarbij niveau 0 sensoren / actuatoren is, niveau 1 basisbesturing, niveau 2 toezicht (HMI), niveau 3 productieactiviteiten (MES) en niveau 4–5 enterprise IT.
RTLS-componenten bestaan over meerdere lagen: ankers en gateways op L1-L2, locatie-intelligentieplatform op L3, analytics en rapportage op L4. De architectuur moet de leidingen tussen deze zones respecteren.
Beveiligingsniveaus — SL 1 tot en met SL 4
IEC 62443 definieert vier beveiligingsniveaus per aanvallercapaciteit: SL 1 tegen toevallig misbruik, SL 2 tegen opzettelijke ongeavanceerde aanvallen, SL 3 tegen geavanceerde specifiek gerichte aanvallen, SL 4 tegen geavanceerde aanvallen met uitgebreide hulpbronnen.
De meeste industriële RTLS-implementaties richten zich op SL 2 over het hele platform, met SL 3 voor de management- en integratielagen. Om dit te bereiken zijn zowel leverancierscapaciteit als implementatie-ontwerpkeuzes nodig.
Zones, leidingen en wat ze overstekt
Elke IEC 62443-architectuur definieert zones (logische groeperingen van apparatuur met gemeenschappelijke beveiligingseisen) en leidingen (de gecontroleerde communicatieroutes tussen hen).
Voor RTLS betekent dit doorgaans: een speciale RTLS-ankerzone op L1-L2, een analytics-zone op L3, en expliciete, gemonitorde kanalen naar de MES, WMS en historian.
Cross-zone verkeer gebruikt geauthenticeerde, versleutelde protocollen met strikte toestemmingslijst — geen vlakke netwerken.
Patchbeheer, veilige implementatie en de levenscyclus
IEC 62443 vereist voortdurende beveiliging gedurende de hele implementatielevenscyclus, niet alleen bij overdracht.
Dit betekent gedocumenteerde patchbeheerprocessen, standaard veilige leveranciersinstellingen, periodieke kwetsbaarheidsbeoordeling en incidentrespons-playbooks specifiek voor OT (waarbij 'de stekker eruit trekken' zelden een acceptabele reactie is).
Deze zijn ontworpen als onderdeel van fase 1 en 3 van de TRACIO Programmamethode.
Treat RTLS as IACS, not as another IT SaaS
IEC 62443 is the dominant framework for industrial automation and control system security. RTLS anchors, gateways, positioning servers and MES integrations sit across Purdue levels — typically L1–L2 for field gear, L3 for location services, L4 for enterprise analytics. Flat networks that drop UWB backhaul onto the plant VLAN fail security review.
Define zones (shared security requirements) and conduits (controlled channels between them). A practical pattern: dedicated RTLS field zone, tightly filtered conduit to the location server zone, separate conduit to MES/WMS, and a locked-down management plane. Allow-list protocols; disable unused services; prefer mutual TLS where platforms support it.
Security Levels (SL-T targets) come from risk assessment (62443-3-2), not from a vendor brochure claiming 'SL2 ready'. Critical infrastructure and safety-interlocked proximity systems often need stronger targets on management interfaces than on raw ranging traffic.
Threats unique to locating systems
Published research on UWB RTLS has shown risks of sniffing, spoofing and location manipulation when air interfaces and management planes are weak. Compromised location can disable geofencing, falsify mustering, or reveal high-value asset and people patterns.
Supply-chain and patch reality: industrial RTLS products have shipped with serious CVEs. Demand SBOMs, signed updates, vulnerability disclosure processes, and a patch window that matches your OT change calendar — not consumer IoT update habits.
Segment cloud control planes carefully. If the vendor requires outbound management, put it through a monitored DMZ with certificate pinning and break-glass procedures for disconnect.
What to demand in procurement
Ask for zone/conduit reference architectures, authentication models for anchors, encryption defaults (not optional add-ons), role separation between OT engineers and vendor support, and logging suitable for your SIEM (syslog/CEF/JSON).
Include OT cybersecurity in gate 1 alongside RF design. Retrofitting segmentation after anchors are powered is a programme-rescue pattern — expensive, slow, and politically painful.
Monitoring, incident response and vendor remote access
Pipe locating logs into the OT SOC with use cases for anchor storms, unexpected management logins, certificate expiry and geofence rule changes. Remote vendor access should be brokered, recorded and time-boxed — perpetual VPN into the field zone is an unacceptable default.
Tabletop a scenario where location is spoofed during an evacuation drill. If safety systems trust RTLS blindly, add corroborating controls.
Independent OT-aware locating architecture
We co-design zones/conduits with your CISO and OT architects, score vendors on secure-by-default posture, and refuse 'flat VLAN for the pilot' shortcuts that become permanent. Cybersecurity is a gate criterion, not a phase-2 wish.
Cloud, edge and sovereign deployment patterns
Some plants allow SaaS location servers in region; others require on-prem or sovereign cloud. Architecture patterns differ: edge buffering, certificate PKI, and update channels must match the chosen pattern without weakening conduits.
Write the pattern into the RFP. Vendors that only offer multi-tenant global SaaS may be disqualified early for defence, pharma or KRITIS contexts — better before PoC spend.
Safety functions that depend on location integrity
When location drives machine-stop geofences or evacuation decisions, integrity and availability requirements rise. Consider independent corroboration (access readers, fixed light curtains) and fail-safe behaviour on RTLS loss. IEC 62443 work should join functional-safety colleagues, not only IT.
RFP language that raises the bar
Require zone/conduit diagrams, default-on encryption, SBOM availability, vulnerability SLA, recorded remote-access brokerage, and a secure configuration baseline as deliverables — not optional professional-service extras.
Score vendors down for shared support accounts and flat network reference designs.
Veelgestelde vragen
Hebben we IEC 62443-certificering nodig, of alleen uitlijning?
De meeste ondernemingen streven naar IEC 62443-afstemming met gedocumenteerde ontwerp- en operationele praktijken — niet formele certificering.
Formele certificering (meestal 62443-4-1 voor producten of 62443-2-1 voor processen) is alleen vereist in specifieke gereguleerde contexten (sommige kritieke infrastructuur, sommige verdediging).
Uitlijning is voldoende voor de overgrote meerderheid van industriële implementaties.
Op welk beveiligingsniveau moeten we ons richten?
SL 2 voor de meeste industriële RTLS, SL 3 voor de beheer- en integratielagen en voor implementaties in kritieke infrastructuur of met verhoogde dreigingsprofielen. We helpen u samen met uw CISO het juiste niveau per zone bij gate 1 te bepalen.
Hoe beïnvloedt dit de keuze van leveranciers?
Belangrijk. Leveranciers die hun Security Development Lifecycle niet kunnen verwoorden (meestal 62443-4-1-capabel) vallen uit de shortlist. De meeste enterprise RTLS-leveranciers zijn er nu wel, maar verificatie is niet triviaal — we voeren het uit tijdens leveranciersevaluatie.
Kunnen we IEC 62443-uitlijning aanpassen aan een bestaande implementatie?
Ja, maar duurder dan het ontwerpen erin. Retrofit betekent meestal het hersegmenteren van het netwerk, het opnieuw sleutelen van apparaatcertificaten, het versterken van platformconfiguraties en het herbouwen van incidentresponsprocedures.
We doen dit werk als onderdeel van Programma Redding verlovingen.
Laatst bijgewerkt: