IEC 62443 & RTLS — OT cybersecurity.
RTLS is operational technology. It sits beside PLCs, SCADA and MES — so IEC 62443 applies. Segment, authenticate and patch like the rest of the OT estate.
The Purdue model and where RTLS lives
IEC 62443 inherits the Purdue Enterprise Reference Architecture: a layered model where Level 0 is sensors / actuators, Level 1 is basic control, Level 2 is supervisory (HMI), Level 3 is manufacturing operations (MES), and Level 4–5 is enterprise IT.
RTLS components live across multiple layers: anchors and gateways at L1-L2, location-intelligence platform at L3, analytics and reporting at L4. The architecture must respect the conduits between these zones.
Security Levels — SL 1 through SL 4
IEC 62443 defines four Security Levels by attacker capability: SL 1 against casual misuse, SL 2 against intentional unsophisticated attack, SL 3 against sophisticated specifically-targeted attack, SL 4 against sophisticated extensive-resource attack.
Most industrial RTLS deployments target SL 2 across the platform, with SL 3 for the management and integration layers. Achieving these requires both vendor capability and deployment-design choices.
Zones, conduits and what crosses them
Every IEC 62443 architecture defines zones (logical groupings of equipment with common security requirements) and conduits (the controlled communication paths between them).
For RTLS this typically means: a dedicated RTLS-anchor zone at L1-L2, an analytics zone at L3, and explicit, monitored conduits to the MES, WMS and historian. Cross-zone traffic uses authenticated, encrypted protocols with strict allow-listing — not flat networks.
Patch management, secure deployment and the lifecycle
IEC 62443 requires ongoing security across the deployment lifecycle, not just at handover.
This means documented patch-management processes, secure-by-default vendor settings, periodic vulnerability assessment, and incident-response playbooks specific to OT (where ‘pull the plug’ is rarely an acceptable response).
These are designed as part of stage 1 and 3 of the TRACIO Programme Method.
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.
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.
Frequently asked questions
Do we need IEC 62443 certification, or just alignment?
Most enterprises target IEC 62443 alignment with documented design and operational practices — not formal certification.
Formal certification (typically to 62443-4-1 for products or 62443-2-1 for processes) is required only in specific regulated contexts (some critical infrastructure, some defence). Alignment is sufficient for most industrial deployments.
Which Security Level should we target?
SL 2 for most industrial RTLS, SL 3 for the management and integration layers and for deployments in critical infrastructure or with elevated threat profiles. We scope the appropriate level per zone at gate 1, jointly with your CISO.
How does this affect vendor selection?
Significantly. Vendors who can't articulate their Security Development Lifecycle (typically 62443-4-1 capable) drop out of the shortlist. Most enterprise RTLS suppliers are now there, but verification is non-trivial — we run it during vendor evaluation.
Can we retrofit IEC 62443 alignment to an existing deployment?
Yes, but more expensively than designing it in. Retrofit usually means re-segmenting the network, re-keying device certificates, hardening platform configurations and rebuilding incident-response procedures. We do this work as part of programme rescue engagements.
Last updated: