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](/knowledge/glossary/ros2/) and [SROS2](/knowledge/glossary/sros2/) deployment assessment, [DDS](/knowledge/glossary/dds/) and [RTPS](/knowledge/glossary/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](/knowledge/glossary/dds/) is the publish-subscribe middleware beneath ROS 2 and several other robotics frameworks. [RTPS](/knowledge/glossary/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](/services/architecture-cloud-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](/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](/trust/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](/knowledge/glossary/mlps/) for connected service robots, sector-specific guidance for medical-robotics deployments ## Engagement model | Scope | Engagement model | |---|---| | Single-platform SROS2 / ROS 2 assessment | [Scoped Assessment](/engagement-models/scoped-assessment/) | | Multi-platform fleet plane review | [Custom Engagement](/engagement-models/custom-engagement/) | | Continuous engagement across product evolution | [Retainer](/engagement-models/retainer/) | > "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](/services/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](/engagement-models/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](/knowledge/faq/ros1-vs-ros2-security/) for the framing. ### Related - [Industries — Robotics](/industries/robotics/) - Companion research: [IoT Supply-Chain Vulnerabilities — Procurement Responsiveness Profile](/research/iot-supply-chain-2026/) (for robotics component selection) - [What is ROS2?](/knowledge/glossary/ros2/) - [What is SROS2?](/knowledge/glossary/sros2/) - [What is DDS?](/knowledge/glossary/dds/) - [Methodology](/methodology/)