RLSOK vs SROS2

SROS2 boundary

• Authenticate DDS participants using security enclaves and credentials.
• Protect DDS traffic confidentiality and integrity.
• Apply governance and permissions to ROS 2 graph operations.
• Constrain which authenticated participants may publish, subscribe, or call actions and services.

RLSOK boundary

• Identify immutable learned-policy release content.
• Track approval and revocation state.
• Bind short-lived authority to action, robot, controller, and release.
• Recheck immediately before dispatch and record Evidence.

Why authenticated code can still be unauthorized

A participant with valid DDS credentials can still carry a revoked release, the wrong policy hash, stale approval, or an action intended for another robot configuration. Transport identity and graph permission do not inherently encode those release-lifecycle facts.

How they compose

Use SROS2 to protect the ROS 2 communication and participant boundary. Use RLSOK at the application execution boundary to decide whether exact release content has current, context-bound authority. RLSOK does not replace or weaken SROS2.

Shared limitation

Neither layer alone proves policy correctness or physical safety. Keep functional-safety controls, model validation, operational safeguards, and incident response independent.

Sources and verification scope

Source code and guides describe implementation and setup. Release notes identify reported checks and their limits. Publication alone does not establish customer use or physical-robot validation.

• RLSOK authorization boundary
• Official SROS2 repository and DDS-Security documentation

Continue with the relevant guide

Try the local example without an application. For setup or integration help, you can also contact us.