Skip to content

Robotics Security — ROS 2, SROS2, DDS, Fleet-Management Assessment

Threat-model-led robotics security engagement — ROS 2 / SROS2 deployment assessment, DDS and RTPS network attack-surface testing

By Tatiana K.

Robotics has moved from research benches into factories, warehouses, surgical theaters, and customer-facing service deployments. The communication and identity model in most production robotics deployments was inherited from research-grade origins — open communication, minimal authentication, generous network trust — that no longer match the operational reality.

Melina supports robotics vendors and operators across ROS2 and SROS2 deployment assessment, DDS and RTPS network testing, robotic arm and mobile-platform security, and fleet-management plane security.

What this service covers

ROS 2 / SROS2 deployment assessment

Production-grade ROS 2 deployments typically face a small set of recurring questions: is SROS2 enabled, are governance and permission documents configured restrictively, is the certificate-authority management operational, what’s the rotation model for compromised credentials.

We assess the actual deployed configuration — not the documented configuration — and provide remediation guidance scoped to the operational reality:

  • SROS2 enablement and policy posture
  • Governance and permission file analysis
  • Certificate-authority and key-management operational review
  • Inter-node communication trust model

DDS and RTPS network attack-surface testing

DDS is the publish-subscribe middleware beneath ROS 2 and several other robotics frameworks. RTPS is the wire-level protocol. Both expose attack surface that depends on DDS-Security configuration and the specific DDS implementation (Fast DDS, CycloneDDS, Connext, OpenDDS).

We test the deployed configuration on real hardware, including: participant-discovery sniffing, topic enumeration, replay and injection on motion-control topics, and misconfigured DDS-Security policy identification.

Robotic arm, AGV/AMR, mobile platform testing

Hands-on testing on the physical platform:

  • Motion-control safety-bypass attack scenarios
  • Sensor-spoofing attack-surface where in scope (LiDAR, vision, force-torque)
  • Fleet-management API attack surface
  • Operator-interface security (teach pendant, HMI panels, web consoles)
  • Tool-changer and end-effector control-channel security
  • E-stop and safety-PLC interaction with cybersecurity controls

Robotics fleet and cloud control-plane

Robotics deployments at scale ride on cloud or on-premises fleet-management platforms — scheduling, tasking, telemetry, remote-control. The fleet plane is the highest-leverage attack surface in production robotics: a single compromise affects every robot in the fleet.

We assess the fleet plane as a cloud architecture review scope, with robotics-specific threat scenarios — tasking abuse, telemetry manipulation, OTA-update integrity, multi-tenant isolation across customer deployments.

Robotics OTA update security

Robotic platforms with field-update capability inherit the same attack-surface considerations as connected IoT: secure-update channel, image signing and verification, anti-rollback, key revocation. We assess the OTA path as part of the engagement scope.

Methodology

Each robotics engagement follows our six-stage methodology: Discovery, Scoping, Threat Modeling, Testing, Reporting, 60-day Re-check. For robotics engagements, motion-control bypass testing is executed under explicit envelope constraints and operator-monitored authorization to avoid hardware damage.

What this service does not include

  • Functional-safety engineering proper (ISO 10218, ISO/TS 15066, IEC 61508) — we support cybersecurity work that interfaces with functional safety, but functional-safety engineering is a separate discipline
  • Industrial control-system penetration testing in active production lines without operator coordination — see Rules of Engagement

Compliance and standards we work within

  • ISO 10218 / ISO/TS 15066 (industrial robot safety)
  • IEC 61508 functional-safety alignment where cybersecurity affects safety
  • IEC 62443 for industrial robotics in plant networks
  • ANSI/RIA R15.06, ANSI/RIA R15.08 for mobile robots
  • Regional radio-equipment and EMC standards as applicable
  • China-market: MLPS for connected service robots, sector-specific guidance for medical-robotics deployments

Engagement model

ScopeEngagement model
Single-platform SROS2 / ROS 2 assessmentScoped Assessment
Multi-platform fleet plane reviewCustom Engagement
Continuous engagement across product evolutionRetainer

“The substantive architectural fix in production robotics is rarely ‘add SROS2’ — most deployments already have SROS2 enabled. The fix is reversing the inherited research-grade trust model, which is structurally different work than the team initially expects when they engage us.” — Tatiana K., CEO, Melina Security

What buyers ask us first

Three questions surface in nearly every initial discovery call with a robotics vendor or operator:

“How invasive is motion-control testing?” We design motion-control tests with explicit envelope constraints (joint-angle limits, velocity caps, force ceilings), use isolated test units where the customer can provide them, and run with operator-monitored execution where damage risk exists. Testing on customer-deployed production units happens only under written authorization with operator presence. The combination of constraints lets us produce meaningful findings without unacceptable hardware-damage risk.

“Should we test individual robots or the fleet plane?” The fleet plane, when budget supports both, but if you have to pick one — the fleet plane. A single fleet-plane compromise affects every robot in the fleet, which is a much larger blast radius than a per-robot finding. Per-robot testing surfaces specific exploitable conditions but the operational risk per finding is bounded; fleet-plane findings can move from 0 to 100 robots’ worth of impact in a single exploit chain.

“Can the assessment coordinate with our safety case?” Yes. For safety-relevant robotics deployments (industrial robots, surgical robots, autonomous mobile robots in shared workspaces), we document cybersecurity findings in a form the safety engineering team can ingest, with explicit safety-implication tagging on findings that cross from pure-cybersecurity into safety-relevant scope. The cybersecurity assessment is not a substitute for safety certification, but the two artifact streams need to talk to each other.

Frequently asked questions

Will motion-control testing damage our hardware?

Motion-control tests are designed with explicit envelope constraints, isolated test units where possible, and explicit operator-monitored execution where damage risk exists. Testing on customer-deployed production units happens only under written authorization with operator presence; we do not run motion-control bypass tests on live deployments without that authorization.

Do you work with research-grade ROS 2 deployments?

Yes. Research-grade deployments often pre-stage the security issues that arrive at production scale; assessment at the research-prototype stage produces architectural guidance that’s much cheaper to implement than retrofitting at production scale.

How do you handle perception-model security (LiDAR / vision spoofing)?

Where in scope, perception-model adversarial robustness is part of AI/ML Security engagement framing. We coordinate with the robotics engagement team to ensure perception findings feed into the broader robotics threat model and that safety-critical-control implications are explicit.

Do you work with surgical and medical robotics?

Yes, with the additional engagement-frame requirements that medical-device regulation imposes (FDA premarket considerations, EU MDR, China NMPA). Medical-robotics engagements typically run as Custom Engagement given the regulatory overlay.

What if our deployment uses ROS 1 (not ROS 2)?

ROS 1 has no built-in security model — assessment scope is shaped accordingly, focusing on network isolation, operational-control compensations, and migration-path planning to ROS 2 with SROS2. See ROS1 vs ROS2 security — FAQ for the framing.