RTLS for IT and OT.
RTLS is operational technology. It rides your network, integrates with systems you already secure, and creates new data that has to be governed. This is the IT and OT lens — the questions that should be answered before any hardware is ordered.
The network, segmentation and IEC 62443
RTLS deployments fail security review when they are treated as IT projects rather than OT projects.
The right starting point is a Purdue-model-aware architecture: where do the anchors, gateways and middleware sit? Which zone? What conduits? Modern RTLS platforms support IEC 62443-aligned segmentation,
mutual TLS, role-based access and audit logging — but only when designed in from gate 1.
Retro-fitting security after the architecture is signed costs more than redesigning.
Identity and access — who can see what location
Location data is sensitive by design: it can identify staff, expose process knowledge, and create regulatory exposure (GDPR, works-council).
The right control plane segregates raw position telemetry from derived analytics, applies role-based access at the API layer, and logs every query. The default settings on most vendor platforms are wrong for European enterprise contexts — they need explicit tuning.
Integration patterns that actually scale
Three integration patterns work at enterprise scale: streaming (MQTT or Kafka for high-frequency position events into a digital twin or analytics layer),
API-driven (REST or gRPC for the WMS, MES or EMR to pull location on demand), and ESB-mediated (where you already run an enterprise service bus, MuleSoft, Boomi).
The wrong pattern locks you into the vendor's data model. We design for the pattern your stack already uses.
Supplier and supply-chain scrutiny
Modern procurement requires SBOM, SOC 2 or ISO 27001 attestation, and patch-management commitments from RTLS suppliers. Not all vendors meet that bar — and the ones that do are not always the technically-strongest.
We run vendor scrutiny against your specific security posture (often with your CISO directly) and produce a scorecard that survives third-party-risk review.
Frequently asked questions
Does RTLS need its own VLAN, or can it ride existing infrastructure?
Depends on the technology and your operational risk tolerance. BLE and Wi-Fi-based RTLS can ride existing infrastructure carefully; UWB anchors typically benefit from a dedicated VLAN. We design segmentation as part of the architecture, not as an afterthought.
How is location data secured in transit and at rest?
Modern platforms support mutual TLS for transit and AES-256 at rest, with role-based access and audit logging. We verify the implementation, not the marketing claim, during gate 1 review and the pilot.
Can we run RTLS in an air-gapped or restricted-network environment?
Yes — common in defence, pharma, and some industrial contexts. We have architected systems that run fully on-premises with no outbound connectivity, including in classified facilities. The vendor shortlist gets shorter; we navigate it.
What's the integration effort with our existing SIEM?
Most RTLS platforms emit syslog, JSON or CEF-formatted events that integrate cleanly with Splunk, Sentinel, Elastic or QRadar. Specific event mapping is scoped in stage 1 with your security team.
Last updated: