IEC 62443 & RTLS — OT cibersegurança.

A IEC 62443 herda a Purdue Enterprise Reference Architecture: um modelo em camadas onde o Nível 0 são sensores/atuadores, o Nível 1 é controle básico, o Nível 2 é supervisão (HMI), o Nível 3 é operações de manufatura (MES) e o Nível 4–5 é TI empresarial.

Os componentes do RTLS vivem em múltiplas camadas: âncoras e gateways no L1-L2, plataforma de inteligência de localização no L3, análises e relatórios no L4. A arquitetura deve respeitar os condutos entre essas zonas.

IEC 62443 define quatro Níveis de Segurança por capacidade do atacante: SL 1 contra uso indevido casual, SL 2 contra ataques intencionais não sofisticados, SL 3 contra ataques sofisticados especificamente direcionados, SL 4 contra ataques sofisticados de recursos extensivos.

A maioria das implantações industriais do RTLS tem como alvo o SL 2 em toda a plataforma, com o SL 3 para as camadas de gerenciamento e integração. Alcançar isso requer tanto a capacidade do fornecedor quanto as escolhas de design de implantação.

Toda arquitetura IEC 62443 define zonas (agrupamentos lógicos de equipamentos com requisitos comuns de segurança) e condutos (os caminhos de comunicação controlados entre eles).

Para o RTLS, isso normalmente significa: uma zona âncora dedicada para o RTLS em L1-L2, uma zona analítica em L3 e condutos explícitos e monitorados para o MES, WMS e o historian.

O tráfego entre zonas utiliza protocolos autenticados e criptografados com listagem de permissão rigorosa — não redes planas.

A IEC 62443 exige segurança contínua ao longo de todo o ciclo de vida da implantação, não apenas na transferência de emprego.

Isso significa processos documentados de gerenciamento de patches, configurações de fornecedores seguros por padrão, avaliação periódica de vulnerabilidades e manuais de resposta a incidentes específicos para OT (onde 'desligar a tomada' raramente é uma resposta aceitável).

Esses são projetados como parte dos estágios 1 e 3 do Método do Programa TRACIO.

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.

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.

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.

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.

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.

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.

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.

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.