Off-highway machines are built to last for decades, but the software they run changes continuously. Treating updates as rare, exceptional events no longer works when vulnerabilities are discovered weekly, often in software already deployed, and security must be maintained throughout the machine’s life.
This is where the traditional “project mode” approach breaks down. A big software push before SOP, followed by long periods of silence, cannot support long-term security, compliance, or controlled change under the Cyber Resilience Act and standards like ISO 24882.
What DevOps means for off-highway embedded (not just cloud teams)
DevOps in off-highway has nothing to do with web apps deploying ten times a day. It is about creating a reliable, repeatable path from source code to machines in the field.
In practice, this means a consistent, automated pipeline that takes BSPs, OS layers and applications, turns them into tested artefacts, and makes them ready for secure deployment.
Key practices, without the buzzwords:
- reproducible builds for BSPs, operating systems and applications, typically using Yocto and containerised build environments
- automated tests that actually reflect reality: smoke tests on real hardware, hardware-in-the-loop for safety-relevant functions, and regression tests that catch unintended side effects
- release “trains” instead of one-off drops: smaller, more frequent updates that reduce risk and make change predictable
- fleet management system to track which machine runs which software, is updated or at risks
This is how large OEMs have scaled. A platform approach is a well-known example: one common software platform and pipeline, reused across multiple machine families, instead of bespoke software silos per product.
The value is not speed for its own sake. It is control.
CVE management as a repeatable process, not a one-off scan
Vulnerability management only works if it is treated as a loop, not an event.
A simple way to think about it is:
See
Every build generates an SBOM and runs an automated CVE scan across the kernel, userspace, libraries and open-source dependencies.
Decide
Not every CVE is equal. Triage answers practical questions:
Is the component actually used?
Is the vulnerable code reachable from this ECU?
What is the safety or operational impact if it is exploited?
Act
Patch where needed, rebuild, rerun tests, and prepare an OTA update or service campaign.
Prove
Store the evidence: scan results, risk decisions, test logs and release notes. This is what auditors will ask for under CRA and ISO 24882.
Tools can help here. For example, CVE scanning integrated into Yocto pipelines removes a lot of manual effort. But the important part is the process. The tool supports the method, not the other way around.
Connecting the dots to CRA and ISO 24882
CRA talks about “handling vulnerabilities” and maintaining “state of the art” security. In real terms, that means you can demonstrate three things:
- how vulnerabilities are detected
- how quickly they are assessed and addressed
- how fixes are deployed to machines already in the field
ISO 24882 and related standards like ISO 21434 add expectations around traceability and ownership. You need a clear line from requirement to implementation, test and deployment, and a named owner responsible for cybersecurity and vulnerability management.
A DevOps pipeline combined with a structured CVE process becomes the operational engine behind compliance. This is where compliance stops being a cost and starts becoming a competitive advantage, as Julien outlined earlier in this magazine.
Minimal viable setup for an off-highway OEM
This does not need to start big.
A practical entry point looks like this:
- pick one priority platform, such as a main display or connectivity gateway
- set up a CI pipeline that builds the BSP and applications, generates an SBOM, runs an automated CVE scan, and executes a small regression test suite on real hardware
- define clear roles: who triages CVEs, who approves patches, who manages OTA rollout
Run this as a pilot for six to twelve months. Once it is stable, extend the same pattern to other ECUs and machine families. Consistency matters more than perfection.
Conclusion
Ultimately, long-term compliance and security in the off-highway sector depend on consistency rather than perfection. By embedding these five core DevOps habits into your daily operations, you transform compliance from a costly burden into a true competitive advantage:
automate CVE scans for every release, not once a year
- keep SBOMs up to date, per software version and per ECU
- standardise pipelines so all Linux-based ECUs follow the same pattern
- test like the field: real hardware, real connectivity conditions
- store your evidence so scans, test logs and release notes are always audit-ready
DevOps lifecycle in off-highway
