Automotive-grade security for autonomous robots
We are a team of engineers with a decade each in automotive cybersecurity, on machines built in volume and kept safe in the field for years afterwards. Autonomous robots have the same attack surface and the same consequences. We bring the playbook, without the ten years it took to write it.
What transfers
Automotive spent a decade working this out the hard way, one production programme at a time. A robot is a vehicle with a different body and a shorter history — so the honest answer is that four fifths of the work is already solved, and the remaining fifth is where the real engineering sits.
Threat analysis and risk assessment the way ISO 21434 does it: damage scenarios first, controls last. Same method, different machine.
Who decides, who reviews, and what evidence exists when someone asks. We have built these from nothing and kept them running.
Signed, atomic, anti-rollback updates over the air to machines you cannot physically reach, with the records to prove which unit runs what.
Fuses, key hierarchies, verified boot and signing infrastructure behave the same on a Jetson as on an ECU. This part is a straight port.
Here it diverges. Automotive buses are fixed and knowable; ROS 2 discovery is open and dynamic by default. The detection idea carries over, the implementation does not.
Cars do not hand a remote operator the controls. Robots do. This is the part nobody has a decade of practice in, including us.
Coverage
Most robotics teams secure the cloud and the app, then ship a compute module that boots anything on the SD card and a middleware that trusts every node on the subnet. We work across the whole machine, because that is where the gap always is.
Fuses, secure boot, key storage, debug ports left open on production units.
Verified root filesystem, kernel hardening, mandatory access control, and what the vendor BSP quietly left enabled.
ROS 2 and DDS: node authentication, encrypted topics, access control, and what happens when discovery is open to the whole subnet.
Sensor and map integrity, model provenance, and how the planner behaves when its inputs are wrong rather than missing.
Remote access paths, session authentication, the intervention channel, and the failure mode when the link drops mid-manoeuvre.
Per-robot identity, certificate lifecycle, update distribution, and who in the organisation can move a machine and from where.
Services
Most engagements start with a fixed-price assessment and stop there if that is all you need. Nothing here requires you to adopt our tooling or lock a platform to us.
Threat analysis and risk assessment for the whole machine, run the way ISO 21434 does it. Firmware and image review, ROS 2 and DDS configuration review, remote access and teleoperation paths, fleet identity and key handling. You get a written report with a prioritised plan and effort estimates — and, if you need it, the same findings mapped to the Machinery Regulation, the CRA or IEC 62443.
from €12,000
Secure boot and chain of trust to the application layer. Verified root filesystem and atomic update with anti-rollback. ROS 2 security enclaves, DDS authentication and access control. Per-robot identity, provisioning on the production line, certificate lifecycle. Hardened teleoperation with a defined behaviour when the link fails. Your engineers are trained as we go.
from €60,000
CVE monitoring across your BSP and ROS 2 distribution, backported patches, a maintained SBOM that matches the shipped image, key and certificate rotation, incident support, and a technical file that stays current. The support period outlives the project team — this is the part that has to survive it.
from €3,500 / month
Working stack
ROS 2 security, RAUC, SWUpdate and the Yocto security layers are mature, free and well maintained. There is no reason to replace them and no reason to lock you into anything of ours. The work is in how they are configured, connected and keyed — which is where machines actually fail.
Why robots are harder
In most products a breach costs data. In a robot it costs a person. Cars taught us that, and robots make it worse: they operate beside people without a cabin, a driver or a homologated route.
A performance level or SIL argument that assumes only random failure is incomplete once the control path is reachable over a network. The two assessments have to be run against each other, not filed separately.
On a server you fail closed. A robot that halts mid-path can block a fire exit or drop a load. Every mitigation has to be checked against what the machine does while it is applied.
The supervisory channel is, by design, a remote way to make a machine move. It deserves more protection than anything else in the system and usually has less.
We work with autonomous mobile robots in warehouses and hospitals, automated guided vehicles on factory floors, agricultural and construction machines, inspection and delivery drones, and teleoperated equipment of any kind.
The team
RELRO Security is a team of embedded security engineers based in Sofia. Every one of us has spent more than a decade inside automotive cybersecurity at tier-1 suppliers, on programmes that reached series production for European and Japanese manufacturers.
Between us we have covered every layer of a connected machine: silicon and boot, the operating system, the networks it speaks on, the way it is updated, and the infrastructure behind it. Not one specialism each — the whole thing, repeatedly, under deadline.
None of it was a prototype. These were machines that left the factory in volume, ran for years in places nobody could reach, and had to be updated safely long after the original team had moved on. That is the experience we bring to robots.
Start here
A short technical call first — no slides. You talk to the engineers who would do the work. If an assessment makes sense, it starts within three weeks.