The last article said you need a DevOps engineer, in-house or freelance. Before you take that to your CEO, you need to know what it costs.
You must be able to tell him how long he should pay this person before seeing any result. In this article, we will dive into this.
We previously listed five topics a fleet platform gives you: speed, control, visibility, security and compliance.
What the five steps cost
| Step | What you can do once it’s done | Effort | Who carries it |
|---|---|---|---|
| Speed | Rebuild any version on demand, install it with one command | A month | An engineer you already have, part time |
| Control | Reach every site remotely, change the robot app there by editing Git, ship a versioned OS image, roll either back | 3 to 6 months | Full time |
| Visibility | See a robot degrading before the customer phones | 3 months | Full time |
| Security | Only builds you approved run; revoke one key remotely | 6 months | Full time |
| Compliance | Answer what ran where, and when from your office | 3 months | Full time |
Step 1 is small enough to start without approving a budget. You just need pipelines turn green. For that, you need to understand how to build the software and train employees to use the CI/CD workflow.
Step 2 is the hardest. It takes time because it requires a large amount of optimizations (kernel, system, application) that are unique to your hardware.
Step 3 also takes time because you are required to find out which metrics you need and how to get them reliably.
Step 4 requires patching existing system and put in place new habits for the team on how to deploy and teach about security (e.g supply-chain attacks).
Step 5 would normally be the longest but it will be much easier if you already implemented step 1 to 4.
Once built, the whole will be required to be maintained. Count some hours every week:
- Watching CVE feeds for the packages and base images you ship, and judging which ones actually matter in your case
- Rebuilding a patched image and rolling it out, which takes the same days of waiting as any other release
- Keeping software updated: the kernel and OS on edge servers and robots, the ROS distribution, the Kubernetes node, the CI runners
- Rotating what expires: tunnel keys, signing keys and registry credentials
- Bringing each new site online and slotting it into the rollout order
One the flow is prepared, you depend on external factors: a CVE landing, new laws requiring you to ship a patch.
Step one: speed
You want to be able to build your software from a clean checkout, which forces every undocumented step to be clear. You end up with any version rebuildable on demand and installable with one command. Deploys don’t take long and developers seeing green pipelines are happy instead of frustrated.
Step two: control
The application side moves from running playbooks to pulling from Git, ensuring all machines on a site run the same version.
Teams are still working this out in the open. A recent ROS Discourse thread asking how to update a fleet without bricking one lands on the same answer: an A/B bootloader that keeps the old image as the default until the new one verifies.
Why does it take so long? Because I recommend Yocto and the learning curve is a bit slow. At least you will do it once and do it right.
Step three: visibility
You will need to know which metrics are needed for your customer facing dashboard, your engineering one and set alerts.
Step four: security
Set up a system in place to monitor CVEs in your OS and application layer, constantly monitoring and acting upon them. You also need to protect yourself from supply-chain attacks, requiring to setup an offline repos such as Artifactory. What it buys is that only builds you approved run from approved software.
Step five: compliance
Compliance is a consequence of the other four. With step two’s inventory and step four’s signatures, proving what is running on a machine is easy.
Note, we all have 2 deadlines. The EU’s Cyber Resilience Act starts its reporting obligations in September 2026 and applies fully from December 2027, including that a product be capable of receiving security updates. The Machinery Regulation applies from January 2027 and requires safety functions to survive deliberate tampering. The others are standards a customer’s security team will ask you to meet.
| What you get asked for | Where the work actually sits |
|---|---|
| CRA: ship security updates, report vulnerabilities | steps 2, 3 and 5 |
| Machinery Regulation: safety functions resist tampering | step 4 |
| IEC 62443: authenticated updates, and a patch policy you actually follow | steps 4 and 5 |
| ISO 10218:2025 (industrial robots): guard against unauthorised access and manipulation | step 4 |
This is already happening. KUKA’s robot operating system is certified to IEC 62443-4-2 Security Level 2 and reports meeting both the CRA and EN ISO 10218-1:2025.
Nothing in that table is satisfied by step five on its own. The evidence comes from the earlier steps, and step five is where you package it. Article one covers the CRA in more detail.
How do I get started? Start with one engineer of your team, part time
Use the engineer you already have, part time, and keep it that way for as long as it holds.
Designing the whole platform before building helps you testing it later on. Research on internal platforms finds they raise productivity for some teams and lower deployment stability for others (DORA, 2024).
Hiring a platform team first costs months before anyone writes a line. Specialist infrastructure roles routinely take more than four months to fill (KORE1, 2026). The team then re-derives the same decisions, with nothing running.
Buying a vendor product locks your connectivity and the operating system before you know you what you need.
Start small, learn, identify problems, solve them and iterate.
I’m David Bensoussan. I build deployment and update infrastructure for hardware and robot fleets. If you’re working out how to ship software to machines you can’t reach, book 30 minutes and we can work out your fleet’s update path.