Security robot IT integration: IT/OT guide

Security robots are not standalone devices. Anyone operating them as autonomous toys violates NIS-2 Article 21 and §8a BSIG. The security robot IT integration determines whether a robot replaces the Posten or becomes another noise source for the control room. This text describes the interfaces, protocols and network requirements an IT lead must clarify with the OT owner before procurement.

Security robot IT integration: what must be integrated

Five integration points are mandatory, not optional.

• Video stream via RTSP, ONVIF Profile S and Profile T into existing VMS platforms. Milestone XProtect, Genetec Security Center and Qognify VMS are the three common systems in the DACH market. The robot appears there as a mobile camera with geo coordinates.
• Event stream into the SIEM. Common targets are Splunk Enterprise Security, IBM QRadar, Microsoft Sentinel and Wazuh. Transport via MQTT, webhook or syslog, depending on the SIEM connector.
• Access control. Interfaces to Lenel OnGuard, Bosch Access Management System and Siemens SiPass enable door releases along the patrol route and tour triggers on card swipe.
• Control room link per ISO 22320 for alarm handover to PSIM or NSL gateway. Without structured escalation the robot stays a data producer without a recipient.
• Identity management from Active Directory via SAML 2.0 or OpenID Connect. Local user accounts on the robot dashboard are an audit finding, not an operating model.

Anyone leaving one of these five fields empty pushes the compliance problem into the next audit. Details on the sensor layer: QR-2 sensor profile for 24/7 outdoor patrol.

Network architecture: OT/IT separation per IEC 62443

A security robot does not belong in the office VLAN. Period.

• Dedicated VLAN at Layer 2, isolated from the production network. Outbound connections only via an application gateway that terminates and re-initiates protocols.
• Purdue Level 3.5 DMZ as data hub to VMS and SIEM. No direct connection from the robot to the office network, no direct connection to the cloud without proxy.
• 5G standalone slice or private LTE as primary bearer. WLAN only as fallback, because 802.11 roaming fails reproducibly at hall edges. The bearer switch must be tested in the robot stack, not on customer site.
• mTLS with certificate-based authentication. Static API keys in the field are no longer negotiable in 2025. Certificate rotation runs automated, documented in the SLA.
• Egress whitelisting on the firewall, documented per robot series (QR-1, QR-2, QR-3). Every new firmware brings an updated list of permitted target FQDNs and ports.

The architecture follows IEC 62443-3-3. KRITIS operators check the zoning against the requirement profile under KRITIS requirements for operators.

Data flows and protocols in detail

Concrete numbers, not marketing slides.

• Live video: RTSP over TLS, H.265 codec. Bandwidth 2–6 Mbit/s per stream depending on resolution (1080p to 4K); value based on H.265 reference measurements per ITU-T H.265. At three robots per site the network engineer plans for 18 Mbit/s peak in the uplink, headroom included.
• Telemetry: MQTT 3.1.1 with QoS 1, JSON payload. Topic hierarchy per schema site/{location}/robot/{serial}/{channel}. This keeps the ACL per tenant cleanly separable.
• Alarm events: webhook POST with HMAC-SHA256 signature in the header. Retry logic with exponential backoff up to 5 minutes, then escalation to secondary endpoint. Idempotency key prevents duplicate alarms.
• Log aggregation: syslog RFC 5424 over TLS into the central SIEM. Minimum retention 90 days; for KRITIS evidence obligations per §8a BSIG usually 12 months agreed contractually.
• LiDAR point clouds with the QR-3 with LiDAR and drone detection: processing local on the robot GPU. Metadata goes to the cloud (object class, bounding box, timestamp, confidence), not the raw point cloud. That is a clear decision criterion for plant managers and data protection officers. No geometry data of the facility leaves the plant premises.

This separation of raw and metadata is the most important architecture decision in the stack. It is fixed in writing at contract signing.

NIS-2 and KRITIS requirements for the integration

The security robot IT integration sits under two rulebooks: NIS-2 for cybersecurity, KritisV and the upcoming KRITIS-Dachgesetz (KRITIS Umbrella Act) for the physical protection duty.

• Article 21 NIS-2 requires risk management for supply chains, explicitly including networked robot systems. The robot is asset and supplier at the same time.
• Incident notification within 24 hours as early warning, 72 hours initial report to BSI via the MeldeWeb interface, per Art. 23 NIS-2. This applies to security-relevant incidents affecting the robot, the backend or the patrol data.
• Asset inventory per BSI IT-Grundschutz CON.7. Each robot is recorded with MAC address, firmware version, owner and location. Excel is enough, a CMDB link is cleaner.
• Patch management: SLA for critical CVEs below 7 days per BSI TR-03183, documented in the maintenance contract. Anyone not asking for this SLA in the vendor comparison adds it after the first audit.
• Penetration tests once per year, results part of the KRITIS evidence duty per §8a BSIG. The KritisV sets thresholds and duties. The draft KRITIS-Dachgesetz adds the physical protection dimension. Operational guidance comes from the BBK.

A compact overview of duties sits under NIS-2 compliance requirements. Anyone who has not yet set up the BBK notification paths follows the BBK registration step by step.

Identity, access and data protection

Data protection is not the opponent of IT integration. It is part of it.

• Role model with four roles: operator, supervisor, auditor, maintenance. Permissions are separated in the robot dashboard, assignment via central identity. Operator sees live stream and acknowledgments, auditor sees logs, maintenance sees diagnostics, no one sees everything.
• Audit log immutable. Either WORM storage or append-only database with cryptographic chaining. Retention: 5 years. Basis: KRITIS evidence duty and labour-law limitation periods.
• GDPR Art. 35 requires a Data Protection Impact Assessment before go-live as soon as persons are systematically recorded. The DPIA is not a formality, it is a precondition. No DPIA, no go-live.
• Masking of faces and licence plates in the live stream is configurable. Unmasking happens only under the four-eyes principle, documented with reason in the audit log. Standard operation: everything masked, recording encrypted.
• Works council agreement per §87 BetrVG before roll-out. Anyone informing the works council two weeks before commissioning loses four weeks. Templates for the agreement are in the customer portal.

Service robotics follows the safety baseline standard EN ISO 13482. This standard is written for personal assistance robots and serves as reference in the absence of a dedicated standard for security robots.

Implementation plan: 14 days from kickoff to go-live

A realistic schedule if the preconditions are met: VLAN design decision taken, VMS licence available, works council informed.

• Day 1–3: on-site network assessment. VLAN configuration on switches, firewall rules documented in the change DB and approved by the Change Advisory Board. Bearer tests for 5G and WLAN fallback at the critical route sections.
• Day 4–6: VMS integration with a test camera before the robot goes live. Event mapping into the SIEM with three example scenarios: door opening outside shift, person detection in restricted zone, connection loss over 60 seconds. Correlation rules documented.
• Day 7–9: robot onboarding. Patrol routes laid out in the 3D map, geofences and restricted zones defined. Trial runs without alarm forwarding to calibrate false alarms.
• Day 10–12: escalation chains to the control room tested. NSL link verified with live alarms, including acknowledgment time and return channel. Deputisation rules documented.
• Day 13–14: acceptance test with signed protocol. Training operator (4 hours) and supervisor (8 hours, including evaluation and audit log search). Handover into regular operation.

Anyone not live after 14 days usually has a firewall approval problem or an open works council question, not a technical problem with the robot.

Economics and operating model

The security robot IT integration costs money in setup and saves money in operation. Concrete numbers:

• RaaS model from €3,200/month per robot (list price as of Q1 2025, details under Robotics-as-a-Service model). Includes maintenance, firmware updates, 24/7 support and SIM data volume. Hardware stays property of the provider, the operator pays for availability.
• Comparison to a guard post: €15,000–25,000/month for 24/7 staffing in DACH, depending on the Manteltarifvertrag and surcharges (source: BDSW wage structure survey 2024). The robot does not fully replace the human, it takes over the Streife. A complete calculation sits in the TCO comparison guard service versus robotics.
• Integration into the existing console reduces training effort. If the operator sees the robot in the same Milestone client as the fixed cameras, the learning curve drops to a few hours.
• Scaling modular. Another robot is ready for use within 48 hours, the IT link is identical. This applies to QR-1, QR-2 and QR-3 because they speak the same interfaces.
• Minimum contract term 24 months. Exit clauses are documented in the contract. No vendor lock-in: open protocols (RTSP, ONVIF, MQTT, syslog, SAML) allow a provider switch. The backend infrastructure stays unchanged.

What works: robots for Streife in large, thinly staffed areas (logistics yards, solar parks, plant grounds at night). What does not work: robots as replacement for a Posten at a gate with public traffic. This distinction must be settled before procurement. Otherwise expectations arise that no provider can meet.

The next step is the architecture sketch for your site: VLAN plan, firewall rules, VMS and SIEM connectors, escalation chains. We check the preconditions in a 60-minute workshop and deliver a documented integration concept. Book an appointment at book integration workshop.