IT/OT — architecture de RTLS, RFID et IoT.

Not just "how do we deploy this technology?" — but "how does this technology integrate cleanly into our enterprise architecture, conform to our security posture, respect IT/OT segmentation boundaries,

and not add long-term platform complexity?" Most RTLS programmes that fail at the IT/OT level fail because they were procured by operations without architecture review — the deployment lands, and then IT/OT has to clean up the segmentation, identity and integration aftermath.

The integration architecture is the part of an RTLS deployment that creates the most lasting value or the most lasting debt.

Best practice: data flows from the RTLS platform into a defined integration tier (event broker, ESB, iPaaS) and from there into business systems (WMS, MES, EMR, ERP).

Avoid: point-to-point integrations between the RTLS platform and individual business systems. This pattern doesn't scale, doesn't survive vendor changes, and creates tight coupling between operations technology and enterprise systems.

See /integrations for our enterprise integration patterns across SAP, Oracle, Manhattan, Blue Yonder, Epic, Cerner.

RTLS infrastructure spans both worlds. Anchors, gateways and tag-management traffic live in OT segmentation zones; integration to business systems and analytics live in IT. The deployment crosses these boundaries multiple times, often in subtle ways.

The IT/OT leader should require: documented IT/OT segmentation boundary diagram for the RTLS data flows; explicit conduit definitions for cross-segment traffic;

IEC 62443-aligned security controls; minimal cross-segment write paths (most should be read-only ingestion to analytics).

We've designed RTLS for IT/OT-converged environments at scale. See /compliance/iec-62443.

RTLS adds devices, edge compute and cloud connections — all of which expand attack surface.

Key controls: authenticated device identity (no shared keys at scale); mutual TLS for device-to-platform communication; signed firmware and OTA update integrity;

least-privilege RBAC for platform admin and API access; audit logging of position-data access; data-protection for any PII (staff or patient identifiers).

For regulated industries (defence, pharma, healthcare, critical infrastructure), additional controls apply. See /services/ot-cybersecurity.

Position data is sensitive — for staff (works council and employment law), patients (HIPAA / GDPR), high-value assets (theft and operations).

The IT/OT leader should require: explicit data-classification for each data category; documented retention and deletion policies; role-based access control with auditable trail;

explicit consent and opt-out flows where applicable; data-residency and cross-border-transfer compliance for multi-region deployments.

We design data-governance in stage 1 alongside the technical architecture.

Many enterprises end up with multiple location platforms — one from a vendor for hospital RTLS, another for warehouse RFID, another for fleet GNSS — none of which talk to each other or to the central operations stack.

The IT/OT leader should require a consolidation strategy at the deployment-architecture stage: shared event broker, shared identity, shared analytics.

Even if vendors stay separate at the radio layer, integration consolidation reduces long-term platform complexity. See /for-it-ot for the dedicated IT/OT persona page.