Tracking systems that IT and OT can both own.
Identity and location as a clean feed into systems of record, with security, spectrum and support boundaries that survive an audit.
Flat wireless and unclear ownership strand locating systems.
Shared RACI
Who patches gateways, who owns identity, who approves change windows.
Segment early
OT zoning before supplier convenience.
Exit pack
Credentials and as-builts stay yours.
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 supplier 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 supplier'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 suppliers meet that bar, and the ones that do are not always the technically-strongest.
We run supplier scrutiny against your specific security posture (often with your CISO directly) and produce a scorecard that survives third-party-risk review.
Related reading.
Global industrial group · programme recoveryEarlier work by our advisers
Buying criteria for IT/OT locating architecture
IT and OT jointly own whether locating stays maintainable. Criteria:
- Shared RACI: who patches gateways, who owns certificates, who approves change windows.
- Segmentation first: dedicated paths where risk demands; BLE/Wi-Fi riding existing gear only with explicit risk acceptance.
- Integration patterns that scale: normalized location events into MES/WMS/ERP/EHS via APIs or brokers, not one-off scripts.
- Exit pack: credentials, as-builts, tag registries and data exports remain yours.
Suppliers pitch single-pane platforms. SIs pitch ready-to-run installs. Enterprise architects should buy a locating data layer that can survive a hardware swap.
Architecture failure modes
- Unclear ownership between IT networking and OT engineering after go-live.
- Point integrations that break on supplier version upgrades.
- Spectrum and channel plans ignored until production interference appears.
- Identity tied to supplier cloud tenancy with no enterprise IdP.
- No capacity model for tag and event growth across sites.
Questions for locating suppliers and SIs
- Document the reference architecture for our Purdue zones and identity provider.
- Which open protocols and export formats do we get on day one?
- Who supports firmware, certificates and reader health after warranty, named SLA?
- How do you deduplicate and time-order events before they hit MES/WMS?
- What is the migration path if we change radio suppliers in year three?
How TRACIO differs for IT and OT
TRACIO delivers buyer-side architecture and programme governance for locating (RF survey, segmentation, integration design and supplier scrutiny) without a hardware or platform SKU. We keep both sides of the IT/OT split in a single RACI the steering group can audit.
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 design systems that run fully on-premises with no outbound connectivity. The supplier 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: