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](/knowledge/glossary/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](/knowledge/glossary/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](/knowledge/glossary/dds/) is the publish-subscribe middleware that sits beneath ROS 2 and beneath 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 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](/services/architecture-cloud-review/) scope, with robotics-specific threat scenarios. ## Service mapping Robotics engagements typically draw across: - [IoT & Embedded Security](/services/iot-embedded-security/) — for the on-platform embedded computing - [Architecture & Cloud Review](/services/architecture-cloud-review/) — for the fleet-management plane - [AI/ML Security](/services/ai-ml-security/) — where the robot integrates perception models or RL-based control ## 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](/engagement-models/scoped-assessment/). Multi-platform fleet security review is typically [Custom Engagement](/engagement-models/custom-engagement/). Continuous engagement across product evolution is typically [Retainer](/engagement-models/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](/services/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](/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](/methodology/) 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](/services/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](/research/iot-supply-chain-2026/). 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. ### Related - [What is ROS2?](/knowledge/glossary/ros2/) - [What is SROS2?](/knowledge/glossary/sros2/) - [What is DDS?](/knowledge/glossary/dds/) - [ROS1 vs ROS2 security — FAQ](/knowledge/faq/ros1-vs-ros2-security/) - Companion research: [IoT Supply-Chain Vulnerabilities — Procurement Responsiveness Profile](/research/iot-supply-chain-2026/) (for robotics component selection)