IEC 62443 & RTLS — OT Cybersicherheit.
RTLS ist Betriebstechnologie. Es läuft parallel zu deinen SPS, SCADA, MES und Historian, und sein Kompromiss kann sich in die Produktion auswirken.
IEC 62443 ist das Rahmenwerk, das die meisten Enterprise-OT-Teams zur Scope-Definition und Sicherung verwenden. Dies ist die Zusammenfassung auf Operator-Ebene.
Das Purdue-Modell und wo RTLS lebt
IEC 62443 übernimmt die Purdue Enterprise Reference Architecture: ein geschichtetes Modell, bei dem Level 0 Sensoren/Aktuatoren ist, Level 1 die Grundsteuerung, Level 2 Supervisory (HMI), Level 3 Fertigungsprozesse (MES) und Level 4–5 Enterprise IT.
RTLS-Komponenten existieren auf mehreren Ebenen: Anker und Gateways bei L1-L2, Location-Intelligence-Plattform bei L3, Analytik und Reporting bei L4. Die Architektur muss die Leitungen zwischen diesen Zonen respektieren.
Sicherheitsstufen — SL 1 bis SL 4
IEC 62443 definiert vier Sicherheitsstufen nach Angreiferfähigkeit: SL 1 gegen gelegentlichen Missbrauch, SL 2 gegen absichtliche, unausgefeilte Angriffe, SL 3 gegen gezielte gezielte Angriffe, SL 4 gegen ausgefeilte Angriffe mit umfangreichen Ressourcen.
Die meisten industriellen RTLS-Implementierungen richten sich auf SL 2 plattformweit, während SL 3 für die Management- und Integrationsschichten zuständig ist. Um diese zu erreichen, sind sowohl die Fähigkeit des Anbieters als auch die Bereitstellungsplanung erforderlich.
Zonen, Leitungen und was sie überquert
Jede IEC 62443-Architektur definiert Zonen (logische Gruppierungen von Geräten mit gemeinsamen Sicherheitsanforderungen) und Leitungen (die kontrollierten Kommunikationswege zwischen ihnen).
Für RTLS bedeutet das typischerweise: eine dedizierte RTLS-Ankerzone bei L1-L2, eine Analysezone bei L3 und explizite, überwachte Leitungen zu MES, WMS und Historiker.
Zonenübergreifender Verkehr verwendet authentifizierte, verschlüsselte Protokolle mit strikter Zulassliste – keine flachen Netzwerke.
Patch-Management, sichere Bereitstellung und der Lebenszyklus
IEC 62443 erfordert kontinuierliche Sicherheit während des gesamten Bereitstellungslebenszyklus, nicht nur bei der Übergabe.
Das bedeutet dokumentierte Patch-Management-Prozesse, standardmäßig sichere Anbietereinstellungen, periodische Schwachstellenbewertungen und Vorfall-Reaktions-Playbooks, die speziell für OT gelten (wobei "Stecker ziehen" selten eine akzeptable Reaktion ist).
Diese sind als Teil der Stufen 1 und 3 der TRACIO-Programmmethode.
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.
Häufig gestellte Fragen
Brauchen wir eine IEC 62443-Zertifizierung oder nur eine Ausrichtung?
Die meisten Unternehmen streben die Ausrichtung IEC 62443 an dokumentierte Design- und Betriebspraktiken an – nicht an formale Zertifizierungen an.
Eine formale Zertifizierung (typischerweise für Produkte 62443-4-1 oder 62443-2-1 für Prozesse) ist nur in bestimmten regulierten Kontexten erforderlich (einige kritische Infrastrukturen, einige Verteidigungsbereiche).
Die Ausrichtung ist für die überwiegende Mehrheit der industriellen Einsätze ausreichend.
Welche Sicherheitsstufe sollten wir anvisieren?
SL 2 für die meisten industriellen RTLS, SL 3 für die Management- und Integrationsschichten sowie für Deployments in kritischer Infrastruktur oder mit erhöhten Bedrohungsprofilen. Wir helfen Ihnen, gemeinsam mit Ihrem CISO die passende Ebene pro Zone am Tor 1 abzugrenzen.
Wie wirkt sich das auf die Auswahl der Anbieter aus?
Erheblich. Anbieter, die ihren Security Development Lifecycle (typischerweise 62443-4-1-fähig) nicht artikulieren können, fallen aus der Shortlist aus.
Die meisten unternehmensweiten RTLS-Lieferanten sind inzwischen vorhanden, aber die Verifizierung ist nicht trivial – wir führen sie während der Lieferantenbewertung durch.
Können wir die IEC 62443-Ausrichtung an eine bestehende Implementierung nachrüsten?
Ja, aber teurer als das Einbauen. Nachrüstung bedeutet in der Regel das Neusegmentieren des Netzwerks, das Neuschlüsseln von Gerätezertifikaten, die Härtung der Plattformkonfigurationen und die Neugestaltung von Incident-Response-Verfahren.
Wir machen diese Arbeit als Teil von Programmrettung Verlobungen.
Zuletzt aktualisiert: