Robot cybersecurity protects the authority, integrity, confidentiality and availability of commands and state that can change the physical world. The assets include operator sessions, ROS 2 nodes, DDS participants, topics, services, actions, parameter paths, controllers, update systems, credentials and the network that joins them.
ROS 2 security can use DDS Security capabilities through supported middleware to authenticate participants, control access and protect communication. Those mechanisms need a public-key infrastructure, signed policy, protected private keys and lifecycle operations. They do not replace operating-system hardening, network segmentation, monitoring or independent safety functions.
Use this guide with the ROS 2 real-time control guide and robot network comparison. Security controls must be tested for both adversarial rejection and bounded robot behavior when communication fails.
Map commands, assets and physical consequences
Start with one consequential path, such as an operator sending a trajectory to a controller. List identities, processes, topics, services, discovery, configuration, network zones, credentials and final actuators. State what unauthorized publish, subscribe, replay, denial or parameter change could cause physically.
Include maintenance laptops, CI systems, fleet services, remote support and backups. Trust often enters through update or credential issuance rather than the runtime topic itself. Assign owners and expected communication flows so later access rules describe a minimal job, not every node visible during development.
ROS 2 security builds on middleware capabilities
ROS 2 client libraries communicate through an RMW implementation. DDS-based RMWs can apply DDS Security authentication, access-control and cryptographic plugins through ROS 2 security configuration. Feature support and defaults vary by middleware and release, so verify the deployed implementation instead of assuming the ROS API name proves encryption.
Set security to an enforcement mode for production tests. A permissive strategy can allow startup when artifacts are missing, which is useful for diagnosis but can silently remove the intended protection. Capture network traffic and attempt unauthorized joins to prove the active behavior.
| Layer | Control | Evidence | Failure to test |
|---|---|---|---|
| Identity | Certificate and private key | Authenticated participant | Unknown node |
| Authorization | Signed permissions | Allowed graph actions | Forbidden publish |
| Governance | Domain security policy | Discovery and protection settings | Unauthenticated join |
| Transport | Cryptographic plugin | Protected RTPS traffic | Downgrade or clear text |
| Robot application | Command age and bounds | Safe accepted action | Valid but stale command |
Keystores separate trust anchors and enclave artifacts
The SROS 2 keystore contains certificate-authority material, public trust anchors and per-enclave keys, certificates and signed permissions. Identity and permission trust chains can be separate. Protect CA and private key material according to its role; a readable or modifiable key directory can defeat policy without attacking encryption.
The ROS 2 security keystore documentation explains governance, identity, permissions and enclave files. Inventory exact paths, ownership, backup and provisioning method rather than copying one development keystore to a fleet.
Enclaves follow deployment and privilege boundaries
A security enclave gives a process or group of processes an identity and access-control rules. Group only components that truly share authority and lifecycle. Putting every node in one enclave makes policy easier but expands the effect of one compromised process or leaked key.
Align enclaves with containers, services, robots and maintenance roles. Use stable names independent of host paths where practical. Document how a process selects its enclave and what happens when the requested artifact is absent, expired or signed by the wrong trust anchor.
Permissions should express least privilege
Allow only the domains, topic names, services, actions and directions required by a role. Separate command publishers from telemetry subscribers. Restrict parameter and lifecycle operations that can alter controllers. Generated policy from a development graph is a starting point, not proof of least privilege, because temporary tools may be present.
Test negative cases for each critical path: unauthorized publish, subscription to sensitive data, service invocation, action goal and discovery. Keep policy review alongside code review. A new topic or renamed namespace should fail closed until its need and physical impact are assessed.
| Role | Allow | Deny by default | Physical concern |
|---|---|---|---|
| Operator UI | Approved task goals | Direct torque topics | Unbounded motion |
| Controller | State input and drive command | Fleet administration | Actuator authority |
| Perception | Sensor read and estimates | Motion command | Compromised model |
| Logger | Selected read-only telemetry | Services and parameters | Privilege creep |
| Maintenance | Time-limited diagnostics | Automatic production command | Remote misuse |
Network segmentation limits exposure and movement
Separate robot cells, safety networks, control management, enterprise services, wireless devices and internet-facing systems according to required flows. Use firewalls, allow lists, authenticated gateways and monitored remote access. Segmentation reduces reachability even if one credential or host is compromised.
NIST SP 800-82 Revision 3 provides operational-technology security guidance that accounts for performance, reliability and safety constraints. Apply controls with the robot deadline and recovery behavior measured; a security appliance that adds unbounded delay creates another operational hazard.
Credential lifecycle is harder than initial issuance
Define enrollment, storage, renewal, revocation, replacement, clock requirements and emergency access. Short-lived certificates limit exposure but increase renewal dependence. Long-lived credentials reduce operations but expand the window after theft. Hardware-backed keys can reduce extraction risk but still need replacement procedures.
Test expired, not-yet-valid, revoked, corrupted and mismatched credentials. Verify that logs identify the failing identity without exposing private material. Restore from backup and rebuild trust anchors in a clean environment. A recovery plan that has never been exercised is not an availability control.
Security and functional safety are coordinated but distinct
Cybersecurity reduces malicious or accidental misuse of digital authority. Functional safety controls dangerous failure of defined safety functions. Authentication does not prove a command is physically safe, and a safety-rated stop does not prevent credential theft or data exfiltration.
Keep deterministic position, rate, age and workspace checks near the controller and maintain independent protective functions appropriate to the risk. Link this architecture to the robot functional-safety guide. Threat scenarios that can impair safety need joint analysis while preserving separate claims and evidence.
Monitor identity and communication behavior
Log authentication failures, denied graph actions, certificate status, unexpected participants, policy changes, command rates and controller rejections on synchronized clocks. Establish the expected graph and traffic per operating mode so deviation is meaningful. Protect logs from alteration and limit sensitive payload capture.
Detection must lead to a tested response. Isolate a host, revoke an enclave, restrict a zone or stop remote tasks without disabling necessary protective functions. Alert floods and network scans should not starve the control path. Measure both security detection time and robot reaction.
Validate denial, replay and recovery paths
Attempt forged identities, stolen-but-revoked certificates, unauthorized topics, replayed or stale commands, changed namespaces, discovery floods, network partitions and clock errors in a controlled testbed. Verify denial and attribution, then observe whether the robot holds, decelerates or enters a safer state within its contract.
Re-run allowed communication under peak load and key rotation to measure latency and availability. Preserve packet captures, security logs, policy revisions and robot state. Start with one command path, fix the operational lifecycle, then expand to the full graph rather than enabling broad encryption without maintainable recovery.
- Threat-model commands and physical impact.
- Assign enclave identities to deployment units.
- Enforce signed least-privilege permissions.
- Segment robot, management and external networks.
- Test revocation, denial, delay and recovery.
Frequently asked questions
Does enabling ROS 2 security make a robot safe?
No. It can authenticate, authorize and protect communication, but physical command limits and validated safety functions remain separate requirements.
Will encrypting every topic always harm performance?
Cryptography and policy checks add load, but impact depends on middleware, hardware, traffic and configuration. Benchmark the real graph and preserve control deadlines.
Can development certificates be reused in production?
That creates shared trust and weak lifecycle control. Production should use managed identities, protected keys, least-privilege policy, rotation and revocation.
Does a firewall make SROS 2 unnecessary?
No. Segmentation and host-to-host access control complement participant identity and graph-level permissions. Defense in depth limits different failure paths.
What security test should be run first?
Choose one consequential robot command, prove the authorized path works, then prove an unknown identity and a forbidden publisher are denied and safely handled.
Robot Cybersecurity Application Boundary
Robot cybersecurity depends on middleware support, key protection, policy, network architecture and operations. Validate the exact deployment and coordinate any safety impact with independent protective functions.