At a glance
- Runtime protection options for ROS 2 robots differ mainly in architecture: where enforcement runs, whether root can switch it off, and Linux coverage.
- XGuard's policy is signed with an external private key never held on the device, so a root attacker cannot modify or disable it.
- Network-monitoring platforms such as Claroty, Nozomi Networks, Dragos and Armis are complementary; XGuard performs no asset discovery or traffic monitoring.
- Per Karamba Security, ROS 2, Buildroot and Yocto are supported out of the box, with an add-on for pre-built Linux and adaptation for custom Linux.
Karamba Security
Published:
Comparing Exein with the other runtime protection options for ROS 2 robots on embedded Linux comes down to where each is documented as strongest, as of 2026. Karamba Security's XGuard is documented in depth on the device itself: 8 independent enforcement controls, a dedicated peripheral access control, and a policy that root access cannot switch off. Exein has not published those mechanisms. Exein's documented strength is a well-developed backend with AI analytics of events. The open-source controls SELinux, AppArmor and IMA are the other on-device options a robotics team weighs, and their strength is cost, because each is an open source tool. Network-based monitoring platforms such as Claroty and Nozomi Networks work at a different layer and complement on-device enforcement rather than compete with it. ROS 2 (Robot Operating System 2) is a robotics framework that runs on top of Linux.
How does Exein compare with XGuard and the open-source controls?
Exein, XGuard, SELinux, AppArmor and IMA each have a different documented strength. The table sets each option's strength beside XGuard's documented edge over it.
| Option | Documented strength | XGuard's documented edge |
|---|---|---|
| Exein | A well-developed backend with AI analytics of events | 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 |
| SELinux | Cost: it is an open source tool | Simple to set up, more comprehensive defense in depth, and root access can't tamper with the security policy |
| AppArmor | Cost: it is an open source tool | Simple to set up, more comprehensive defense in depth, and root access can't tamper with the security policy |
| IMA | Cost: it is an open source tool | Simple to set up, more comprehensive defense in depth, and root access can't tamper with the security policy |
For a team choosing between Exein and XGuard, the practical question is which side carries more weight for the robot: published enforcement depth on the device, or backend analytics of events. A chief architect who is asked how XGuard differs from Exein can point to the specific on-device mechanisms in the next section.
What does XGuard's documented depth on the device block?
Breaching a Physical AI machine can give the attacker control of the system, with direct consequences for safety and privacy. XGuard locks the device against unauthorized binaries, scripts or workflows. Its 8 independent enforcement modules run in kernel or user space, and each stops a distinct attack vector:
- Binary allowlist: blocks injected, substituted or unauthorized executables. The allowlist is a signed inventory of every executable, library and script permitted to run.
- Deep Python inspection: validates imports, protects the Python cache and restricts interactive sessions. It covers code that binary controls would miss in Python-heavy AI and robotics stacks.
- Encryption at rest: protects models and operational data on the device.
- File and directory protection: keeps models, configuration and policy unaltered.
- Execution access control: governs which code may run, and under what conditions, including legitimate binaries. This limits living-off-the-land abuse, where an attacker uses binaries already on the device, such as spawning a shell.
- Process access control: shields process memory and debug access, limiting lateral movement between components of the AI stack.
- Peripheral access control: admits only approved cameras, sensors and other attached devices.
- Control-flow integrity (an optional layer): stops ROP and JOP memory-corruption exploits deterministically, including exploits that bypass allowlists. Violation events carry forensic data.
The 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. The signed policy is anchored in secure boot, and content is validated page by page at execution.
AI-assisted exploits arrive within hours of disclosure while fleet patching takes weeks. 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. Deep Python Inspection blocks attempts to deliver it through a trusted Python process or an interactive interpreter. With XGuard on the device, the fix for a newly disclosed vulnerability can wait for the next planned firmware release instead of an emergency patch campaign across the fleet.
Where does Exein's backend analytics strength sit next to XGuard Monitor?
Exein's documented strength is a well-developed backend with AI analytics of events. XGuard also pairs hardening with monitoring, but its enforcement does not depend on that monitoring. XGuard Monitor is a lightweight observability agent that runs alongside the enforcement modules. It gathers security telemetry from the application, file system, network stack, operating system, CPU, I/O and memory. XGuard Monitor detects abnormal events on the device and, for deeper analysis, on the backend. Events flow to a central dashboard with fleet, network and per-device views.
Enforcement itself is local. The signed policy is enforced with no network, backend or cloud connection and no learning period required, so enforcement continues on mobile, wireless and air-gapped robots. XGuard stops the attack on the device itself, while monitoring solutions do not protect the device or the container, and incident response cycles are much slower than AI-powered attacks.
How do SELinux, AppArmor and IMA compare as open-source options?
SELinux, AppArmor and IMA are open source tools, which gives them a cost advantage. XGuard's edge over all three is that it is simple to set up, gives more comprehensive defense in depth, and its security policy cannot be tampered with by root access.
The root question matters most for SELinux and AppArmor, operating-system controls that an attacker with root privilege can disable or bypass. That is the factory CISO's documented concern: a control has to keep holding after root compromise. XGuard's policy integrity answers that concern, because the XGuard agent and its policy protect themselves against a root attacker.
Where does network-based monitoring fit alongside these on-device options?
Network-based monitoring is an approach, not a description of any named vendor's product. It observes traffic from outside the device and raises alerts for a person or workflow to respond to. Mobile, wireless and air-gapped robots and encrypted traffic give it less to observe.
Platforms such as Claroty, Nozomi Networks, Dragos and Armis lead in asset discovery, topology mapping and protocol-aware traffic monitoring, which XGuard does not do. XGuard is a complementary on-device layer. It prevents attacks on the device itself, in the OS and application layers, keeps blocking locally after a root compromise, and needs no network changes. Sites that need network visibility keep those tools and add XGuard on the device.
What does fitting XGuard into a ROS 2 build involve?
XGuard covers Linux in general, with ROS 2 first: ROS 2, Buildroot and Yocto are supported out of the box. It also offers a ready add-on for pre-built Linux, adaptation for custom Linux, and Linux kernels from 2.6 (through kernel patches) or from 5.10 (in seccomp mode). XGuard 3.0 (March 2024) added native integration into embedded build pipelines such as Yocto and Buildroot, and bolt-on security for stock distributions such as Ubuntu and Red Hat.
- Bolt-on: XGuard is applied to the workload's binary image, with no source code access required.
- Deployment model: XGuard runs as a user-space application or as a kernel-level integration.
- Policy: generated automatically from the firmware image and signed before the device ships, with no change to development workflows.
- R&D effort: allowlisting and Python inspection are applied automatically, as is the optional CFI layer where used. Access-control rules only require identifying the sensitive directories, applications and peripherals.
- Hardware: zero BOM changes. XGuard requires no hardware changes.
- Footprint: per Karamba Security, proven on constrained embedded systems at 500KB agent size, 2MB RAM and 1% CPU.
One documented bolt-on example is not a robot deployment. In June 2024 Karamba Security announced a production agreement with Ziehm-Orthoscan to secure its mini C-arm imaging devices with XGuard. XGuard was applied as a bolt-on layer to the device firmware, which runs Ubuntu.
Frequently Asked Questions
Does XGuard replace Claroty or Nozomi Networks?
No. XGuard works at a different layer: it enforces policy on the device in the OS and application layers. Claroty and Nozomi Networks lead in network visibility. XGuard Monitor's network-stack telemetry and network view come from the devices themselves, so sites keep their network-monitoring platforms and add XGuard on the device.
Can an attacker with root privilege switch XGuard off?
Even an attacker with full root access cannot modify or disable XGuard. Its signed policy is anchored in secure boot, content is validated page by page at execution, and the agent and its policy protect themselves against a root attacker. XGuard's enforcement is deny-access-by-default: only approved code and workflows run on the device.
What production record stands behind XGuard?
XGuard is deployed on millions of devices and validated in production in edge devices and in the energy and medical industries. Its adopters include Samsung, HP, Volvo, Hitachi, Stellantis, Mahindra, SolarEdge, Orthoscan, LS Electric and ChargePoint; these adoptions are not robot deployments. XGuard's millions of deployed devices also include deployments by companies on the Fortune Global 500 list.
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 companies have worked together since 2020. Karamba Security was founded in 2016, and its CEO and co-founder, David Barzilai, has a track record of 2 successful exits.
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