Isolated / Bench
Air-gapped lab or test rig, no external communication — the development and integration baseline.
- Host OS hardening as the floor.
- Per-robot identity established.
ROS 2 / DDS Security
A bench prototype and an internet-reachable, remotely operated robot don't need the same controls. We profile each robot by where it actually runs, harden it to a recognized IEC 62443 level, and then watch for anything that doesn't fit that profile — then hand back a layered findings document and the controls to keep your robots there.
Our Customers
The Evidence
The accelerator behind this practice was built and tested on real ROS 2 / rosbridge endpoints — not slideware. The numbers come from a reproducible test rig.
The Exposure Profiles
Four profiles, from an air-gapped bench rig to a robot taking commands over an untrusted network. Where a robot sits decides which controls it needs — and what counts as normal once it's running.
Air-gapped lab or test rig, no external communication — the development and integration baseline.
The classic warehouse-AMR case: robots and a site controller on an isolated network, no control from the wider network.
Telemetry up, tasks down from a cloud fleet manager, no direct public teleop. Adds everything in P1.
Control issued over a public or untrusted network — teleop or remote intervention. The highest baseline. Adds everything in P2.
Our Approach
RoboSentry's agent reads the live ROS 2 graph and the host and surfaces the gaps — safe by design, it only observes, so it can't disrupt a running robot.
Each robot's operating domain sets its profile (P0–P3) and target IEC 62443 level.
Discovery of each robot's real behavior, checked against the profile its domain calls for — flagging where a robot is more exposed than its domain implies.
Apply the controls the profile calls for, parameterized to your stack.
Once hardened, the robot's own profile becomes the live runtime baseline — and anything outside it is flagged.
Where The Controls Sit
One control library, applied across four layers. SROS 2 is the top layer, not the whole story — the controls beneath it are where robots are usually exposed, and where Benison's networking, kernel, and host depth lives.
What You Own
Every engagement hands back artifacts you keep and re-run — mapped to IEC 62443 and structured for your SIEM.
Each robot's real reachability versus the profile its domain calls for, with the gaps named.
IEC 62443 SL-mapped, schema-validated: agent status, host posture, software inventory, drift.
The layer-by-layer controls to reach target, parameterized to your distro, OS, and middleware.
Reproducible drills on real ROS 2 types — rogue publisher, odometry spoof, topic-flood DoS.
Common Questions
Straight answers to the doubts that decide whether this is worth a call.
Across the stack. SROS 2 sits on top; beneath it are DDS-Security, host hardening, keystore and key ownership, and eBPF DDS-to-process attribution — and Benison works every one of those layers, not just the bottom. The robot application is where you build; everything supporting it is where we work.
Both, in sequence. The agent maps your exposure; our embedded engineers then harden — SROS 2 policy, isolate or safe-stop responses — onto your robot's own safety path; and the profile then runs as the live baseline we watch against at runtime. It doesn't stop at a paper report.
No. Zero writes; it never publishes to control topics. The response-plane seam stays a no-op until you explicitly enable a policy-gated action.
Self-hostable ingest (Benison cloud, your cloud, or on-prem), no hardcoded host and no license key, with SIEM fan-out in CEF / syslog / LEEF. You own the artifacts and the deployment.
Get Started
Begin with a RoboSentry engagement. We profile the robot, flag what doesn't fit, and hand back a security profile you own.
If you're a tech geek or know someone who is, fill in the form to work with us.