Skip to content
Melina Security

Robotics Security for Industrial, Service, and Mobile Robotics Vendors

ROS2 and SROS2 deployment assessment, DDS and RTPS security, robotic arm and AGV/AMR security testing, robotics fleet management security.

By Melina Editorial

Robotics has moved from research benches into factories, warehouses, logistics fleets, surgical theaters, and customer-facing service deployments. The security model in production robotics is often inherited from research-grade origins — open communication, minimal authentication, generous network trust — that no longer match the deployment context.

Melina supports robotics vendors and operators across the design, integration, and operations layers.

Where Melina engages on robotics security

ROS 2 / SROS2 deployment assessment

ROS2 is the dominant robotics middleware in industrial and research deployments. 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 documented and operational, and 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.

DDS and RTPS network attack-surface assessment

DDS is the publish-subscribe middleware that sits beneath ROS 2 and beneath several other robotics frameworks. RTPS is the wire-level protocol. Both expose attack surface that depends on DDS-Security configuration and the implementation choice (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, and mobile platform testing

Hands-on testing on the physical platform:

  • Motion-control safety-bypass attack scenarios
  • Sensor-spoofing attacks (LiDAR, vision, force-torque) where in scope
  • Fleet-management API attack surface
  • Operator-interface security (teach pendant, HMI panels)
  • Tool-changer and end-effector control-channel security

Robotics fleet and cloud-control plane

Robotics deployments at scale ride on cloud or on-premises fleet-management platforms that handle scheduling, tasking, telemetry, and remote-control. The fleet-management plane is the highest-leverage attack surface in a production robotics deployment — 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.

Service mapping

Robotics engagements typically draw across:

Compliance and standards frame

Robotics engagements typically operate 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
  • Regional radio-equipment and EMC standards as applicable
  • China-market: MLPS for connected service robots; sector-specific guidance for medical-robotics deployments

Engagement model

ROS 2 / SROS2 readiness assessment is typically Scoped Assessment. Multi-platform fleet security review is typically Custom Engagement. Continuous engagement across product evolution is typically Retainer.

“Production robotics deployments tend to inherit the trust model of the research deployments they grew out of. Open communication, minimal authentication, generous network trust — these were correct choices in the research phase. The architectural fix in production is not adding more security controls; it’s reversing the inherited trust model deliberately, which is a different scope of work than most teams initially expect.” — Tatiana K., CEO, Melina Security

What buyers ask us first

Discovery calls with robotics teams cluster around four questions:

  1. “Is SROS2 enough?” — SROS2 enables transport-layer authentication and encryption between participants. It is necessary but not sufficient for production deployments. The governance and permissions documents have to express the intended trust model, and the certificate-authority lifecycle has to be operational. We see deployments with SROS2 enabled but with permissive permission files that nullify the security benefit.
  2. “What about safety-rated functions?” — Cybersecurity assessment for safety-relevant robotics functions has to coordinate with the safety case. We document cybersecurity findings in a form that the safety engineering team can ingest, and we explicitly call out where a cybersecurity finding has safety implications versus pure availability or confidentiality implications.
  3. “Can you assess the perception stack?” — Where in scope, yes, through the AI/ML Security team. Perception-model robustness against adversarial inputs is a distinct discipline from middleware security; we run them as coordinated tracks within a single engagement when both are in scope.
  4. “How do we handle multi-vendor fleets?” — Most production robotics deployments mix hardware from multiple vendors with a fleet-management plane operated either by the integrator or the customer. The fleet plane is where assessment leverage is highest; we typically scope the fleet plane as the primary assessment target and treat per-robot testing as supporting evidence.

Sector-specific patterns we see

The threat patterns we see in robotics engagements tend to repeat across deployments. We’ve noted these in published research and in customer briefings:

  • Permissive defaults inherited from research deployments. Production code paths still carry the open-trust assumptions that made research iteration fast. Detection is easy; remediation requires a deliberate posture change and is rarely backwards-compatible.
  • Fleet-plane API surface that wasn’t designed for adversarial use. Tasking and telemetry APIs are often implemented as internal-only assumptions, then exposed for partner-integrator access without revisiting the authorization model.
  • Operator-interface devices on shop-floor networks. Teach pendants, HMI panels, and supervisory consoles are frequently older platforms with limited update support, sitting on the same network as the robots they control.
  • Diagnostic and maintenance channels. Vendor maintenance access is often the highest-privilege path into a robotics deployment; assessment of the vendor side of this channel is usually out of scope but worth flagging.

How a robotics engagement is typically structured

A robotics engagement for a single platform with a defined fleet plane runs 6-10 weeks across our six-stage methodology. Discovery and threat modeling consume the first 2-3 weeks because the architecture surface area is wide: hardware, middleware, fleet plane, operator interfaces, vendor maintenance channels.

Testing concentrates on the highest-leverage layer first (typically the fleet plane). Reporting includes a recommended posture-change roadmap for issues that can’t be patched without architectural change. The 60-day remediation re-check verifies fixes against the posture-change plan, not just the patch list.

Frequently asked questions

Will testing motion-control bypass risk damage to expensive hardware?

We design motion-control tests with explicit envelope constraints, isolated test units where possible, and explicit operator-monitored execution where damage risk exists. Testing on customer-deployed production units is conducted 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 or only production?

Both. 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. Production deployments get higher-priority finding triage.

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

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

What does fleet-plane assessment look like in practice?

A fleet-plane assessment treats the cloud or on-premises management platform as the primary target, with individual robot units as supporting evidence rather than as standalone scope. The work covers: tasking and telemetry API authorization, multi-tenant isolation (if the platform serves multiple customers or operational zones), credential and key management for fleet-to-robot communication, and remote-control / remote-maintenance pathways. Findings at the fleet plane affect every robot in the fleet, which is why we prioritise this scope when budget supports it.

How does supply-chain risk affect robotics component selection?

Connected-robotics platforms inherit supply-chain risk from their silicon, networking stacks, and embedded operating systems — the same component categories assessed in our Procurement Responsiveness Profile. Production robotics teams making component decisions benefit from applying the three-dimension profile (Disclosure Cadence, Time-to-Fix, Coverage Breadth) at procurement rather than discovering the supply-chain implications during incident response.

Services we run for Robotics Security for Industrial, Service, and Mobile Robotics Vendors

Outcomes we package for this sector