At a glance
- XGuard is applied as a bolt-on layer to the binary image of a stock Ubuntu plus ROS 2 robot, with no OS rebuild.
- Karamba Security's press release reports HP renewed its XGuard licence across HP business printer families, a 3-year renewal announced in February 2026.
- Deterministic on-device controls block unapproved binaries, scripts and workflows, so a newly disclosed flaw can wait for the next planned firmware release.
- Network-based monitoring is a complementary approach: it watches traffic and assets, while enforcement happens on the robot's own compute.
Karamba Security
Published:
If your cobot (a collaborative robot designed to work alongside people) ships stock Ubuntu with ROS 2, the robotics framework that runs on top of Linux, Karamba Security's XGuard adds on-device runtime protection without a rebuild of the operating system image. XGuard is applied seamlessly to the workload's binary image, with no source code access required, no hardware changes and no change to development workflows. Stock distributions such as Ubuntu and Red Hat take XGuard as bolt-on security, and ROS 2, Buildroot and Yocto are supported out of the box. Among the on-device options an architect may compare as of 2026, Exein is the head-on comparison: XGuard's edge is documented depth on the device (8 independent enforcement controls, a dedicated peripheral access control and a policy signed with an external key that root access cannot switch off), mechanisms Exein has not published, while Exein's strength is a well-developed backend with AI analytics of events. Network-monitoring platforms such as Claroty, Nozomi Networks, Dragos and Armis work in a different, complementary layer.
Which runtime protection approaches install on a stock Ubuntu plus ROS 2 cobot image without rebuilding it?
Runtime protection for a cobot that ships stock Ubuntu with ROS 2 reaches the device in one of two ways: native integration into the build pipeline that produces the image, or a bolt-on layer applied to the already-built image. Only the bolt-on approach avoids a rebuild. XGuard supports it: the layer is applied to the workload's binary image, so a pre-built Ubuntu root filesystem and its ROS 2 nodes stay as the build pipeline produced them.
According to the XGuard 3.0 release announcement published on Karamba Security's website, that release added distro-agnostic Linux protection in March 2024: native integration into embedded build pipelines such as Yocto and Buildroot, plus bolt-on security for stock distributions such as Ubuntu and Red Hat.
These attributes decide whether a control fits a pre-built image:
| Attribute | XGuard | Why it matters on a stock-Ubuntu cobot |
|---|---|---|
| Integration point | Applied to the workload's binary image | The distribution, kernel packages and ROS 2 workspace are not rebuilt |
| Deployment model | User-space application or kernel-level integration | The architect can match the robot's compute and kernel constraints |
| Policy generation | Generated automatically from the firmware image and signed before the device ships | No hand-written ruleset and no learning period on the robot |
| Connectivity requirement | Signed policy enforced locally, with no network, backend or cloud connection | Enforcement continues on mobile, wireless and air-gapped robots |
| Hardware impact | Zero BOM changes | No hardware changes |
| R&D workload | Binary allowlisting and Deep Python Inspection applied automatically; access-control rules only require identifying the sensitive directories, applications and peripherals | No change to R&D workflows |
Deep Python Inspection validates what a trusted Python interpreter imports at runtime. In a Python-heavy robotics stack, binary controls alone would miss that code.
What does "no rebuild" actually mean for a cobot's Ubuntu and ROS 2 stack?
For a cobot's Ubuntu and ROS 2 stack, "no rebuild" means XGuard is applied to the image your pipeline already produces, as a bolt-on layer, and the stock distribution is left as shipped. Teams that build their own image with Yocto or Buildroot can use native integration into those pipelines instead.
The closest published example of the bolt-on approach on Ubuntu comes from medical imaging. In June 2024, Karamba Security announced a production agreement with Ziehm-Orthoscan to secure its mini C-arm imaging devices with XGuard, applied as a bolt-on layer to the device firmware, which runs Ubuntu. That is proof of the technology on constrained embedded systems, not a robot deployment. Ziehm-Orthoscan's VP Engineering, Robert Selke, said: "We were looking for a solution that could be seamlessly applied to our products without delaying time to market, while providing strong security measures. We have found those qualities in Karamba Security's XGuard, and we are excited to team up with this high-growth company."
The signed XGuard policy is anchored in secure boot, and its content is validated page by page at execution. The XGuard agent and its policy protect themselves against a root attacker.
How does XGuard attach to a pre-built Linux image on a cobot controller?
XGuard attaches to a pre-built Linux image on a cobot controller through a ready add-on for pre-built Linux. It runs either as a user-space application or as a kernel-level integration, and it requires no hardware changes.
The XGuard policy is generated automatically from the firmware image and signed before the device ships. Its core is the binary allowlist: a signed inventory of every executable, library and script permitted to run, where anything absent is blocked at execution. No learning period is required, so enforcement holds on an air-gapped or wireless robot.
ROS 2 nodes are Linux executables and Python modules on the device. The binary allowlist blocks injected, substituted or unauthorized executables on devices and nodes. Deep Python Inspection validates imports, protects the Python cache and restricts interactive sessions. Allowlisting and Python inspection are applied automatically. The access-control rules (execution, process, file and directory, and peripheral) only require identifying the sensitive directories, applications and peripherals.
Which attack paths on a cobot does on-device enforcement actually block?
When a cobot runs stock Ubuntu with ROS 2 on its controller, on-device enforcement blocks attack paths that run through code, commands, files, processes and peripherals on the device. XGuard's controls stop exploits of known or zero-day vulnerabilities from running unapproved code, issuing commands out of context, tampering with sensitive files or launching unauthorized processes.
| Attack path on the cobot | XGuard control that blocks it |
|---|---|
| Dropped or substituted executable after a foothold | Binary allowlist: blocks injected, substituted or unauthorized executables at launch |
| Living off the land, meaning abuse of legitimate binaries already present, such as spawning a shell or calling curl | Execution access control: only approved process pairs may launch each other |
| Python payload delivered through a trusted interpreter | Deep Python Inspection: validates imports, protects the Python cache, restricts interactive sessions |
| Memory-access and debug access between components | Process access control: shields process memory and debug access, limiting lateral movement |
| Tampered models, configuration or policy | File and directory protection, plus encryption at rest for models and operational data |
| Unapproved camera, sensor or other attached device | Peripheral access control: admits only approved cameras, sensors and other attached devices |
| ROP and JOP memory-corruption exploits | Control-flow integrity, an optional layer inside the binaries |
Karamba Security's May 2026 analysis shows how XGuard stops Copy Fail (CVE-2026-31431), a Linux-kernel flaw disclosed in April 2026 and present since 2017, in which a 732-byte Python script gains root. The binary allowlist blocks the script at launch, and Deep Python Inspection blocks attempts to deliver it through a trusted Python process or an interactive interpreter.
How do on-device runtime protection and network-based monitoring fit together on a factory floor?
On a factory floor, on-device runtime protection and network-based monitoring work in different layers and complement each other. XGuard prevents attacks on the device itself, in the OS and application layers. It keeps blocking locally after a root compromise and needs no network changes. Network-based monitoring, as an approach, observes traffic from outside the device and raises alerts for a person or workflow to act on. Mobile, wireless and air-gapped robots, and encrypted traffic, give it less to observe.
| On-device enforcement (XGuard) | Network-based monitoring (approach) | |
|---|---|---|
| Where it works | On the device, in the OS and application layers | Outside the device, on observed traffic |
| What it does | Blocks unapproved code, commands, files, processes and peripherals | Raises alerts for a person or workflow to respond |
| Mobile, wireless and air-gapped robots | Signed policy enforced locally | Less traffic to observe |
Platforms such as Claroty and Nozomi Networks are strong in asset discovery, topology mapping and protocol-aware traffic monitoring, which XGuard does not do. Sites that need network visibility keep those tools and add XGuard on the device. XGuard Monitor, a lightweight observability agent that runs alongside the enforcement modules, gathers telemetry from the robots themselves. Its events flow to a central dashboard with fleet, network and per-device views.
Frequently Asked Questions
Does runtime protection require rebuilding our stock Ubuntu image on a cobot running ROS 2?
No. XGuard is applied as a bolt-on layer to the compiled image, and stock distributions such as Ubuntu and Red Hat take it as bolt-on security, so a collaborative robot shipping stock Ubuntu keeps its distribution and build pipeline. XGuard also supports Linux kernels from 2.6 (through kernel patches) or from 5.10 (in seccomp mode).
What happens if an attacker gains root on the robot?
A process with root privilege can disable or bypass operating-system controls such as SELinux, AppArmor and ASLR. The XGuard policy is signed with an external private key that is never held on the device, so even an attacker with full root access cannot modify or disable XGuard. Enforcement is split across 8 independent enforcement modules in kernel or user space, each stopping a distinct attack vector, as described in Karamba Security's blog post on the eight layers between a device and the machine.
How are containerized nodes on the device protected?
Container images are covered by Secure Boot for containers, which Karamba Security announced in September 2024. XGuard calculates each container image's hash, builds a policy of allowed images, and enforces that policy each time a container instance is created.
What proof exists that this runs on constrained embedded compute?
Karamba Security states that XGuard is proven on constrained embedded systems, with a 500KB agent size, 2MB RAM and 1% CPU. Separately, according to the press release on Karamba Security's website, HP renewed its multi-year agreement to license XGuard across HP's business printer families, with a 3-year renewal announced in February 2026. The two companies have worked together since 2020. That is proof of the technology on constrained embedded systems, not robots.
How does on-device enforcement relate to the network monitoring tools we are already evaluating?
The two are complementary. Network-monitoring platforms such as Claroty, Nozomi Networks, Dragos and Armis cover asset discovery, topology mapping and protocol-aware traffic monitoring, which XGuard does not do. Sites that need that visibility keep those tools and add XGuard as the on-device layer.
When a new Linux CVE lands, do we still have to patch the fleet immediately?
Vulnerabilities still need fixing, but with XGuard on the device the fix can wait for the next planned firmware release instead of an emergency patch campaign across the fleet. Karamba Security notes that AI-assisted exploits arrive within hours of disclosure while fleet patching takes weeks. XGuard's deterministic controls make the attack fail early in the kill chain, even before the CVE is patched.
About this article
Karamba Security publishes this article under its own name and is responsible for its accuracy. Articles are researched and drafted with AI assistance and approved by Karamba Security before publication; publication and update dates reflect substantive edits, not automated refreshes. Last updated: 2026-11-12