VSOC
Designing a VSOC That Understands Vehicles
An enterprise SOC watching vehicle telemetry without vehicle context produces alerts nobody can act on. The gap is domain knowledge, not tooling.
· AutoSec Engineering Team · 2 min read
Read articleSecure Updates
UNECE R156 and ISO 24089: Building an Update Process You Can Evidence
Most engineering organisations already update vehicle software safely. Far fewer can reconstruct, months later, exactly what was delivered to which vehicle and why it was considered safe.
· AutoSec Engineering Team · 1 min read
UN Regulation No. 156 requires a Software Update Management System, and ISO 24089 describes engineering practice for software update engineering. They address related but different questions. R156 asks whether the organisation manages updates in a controlled way. ISO 24089 helps answer how the technical work is done.
The evidence problem
Teams usually pass the practical test: updates are delivered, and vehicles work afterwards. The difficulty appears when someone asks for the record. Which software version was on which vehicle configuration before the campaign? What compatibility and safety assessment was performed? Who authorised release? How was completion confirmed for vehicles that were offline during the campaign?
If reconstructing that requires archaeology across several tools and a few people's memories, the management system is not yet real, whatever the process documentation says.
Integrity is necessary but not sufficient
Signing update packages and verifying signatures on the target is essential. It is also the part most programmes get right. The weaker areas tend to be elsewhere.
- Rollback and recovery behaviour when an update fails part-way
- Configuration dependencies between ECUs updated in the same campaign
- Key management across the delivery chain and its lifecycle
- Authorisation and audit of who can trigger a campaign
Impact assessment as an engineering activity
Assessing whether an update affects type approval, safety, or vehicle behaviour is an engineering judgement that needs a defined method and a record. Treating it as a checkbox in a release meeting produces decisions nobody can later explain.
Suppliers hold part of the chain
Update packages, keys, and compatibility information often originate with suppliers. Responsibility for each step should be explicit in the interface agreement, including who verifies what and which records are handed over. Gaps here are typically discovered during a campaign rather than before one.
Written by
AutoSec Engineering Team
Automotive cybersecurity engineering
Engineers working on vehicle cybersecurity concepts, requirements, embedded implementation, and verification across OEM and supplier programmes.
More from this authorRelated reading
Penetration Testing
Where CAN Bus Security Testing Actually Finds Problems
CAN has no built-in authentication, which is well known. The interesting findings are rarely about the bus itself — they are about what sits on it and how it was configured.
· AutoSec Security Research · 2 min read
Read articleCybersecurity Engineering
Making TARA Useful: From Damage Scenarios to Engineering Decisions
A threat analysis that nobody uses is expensive documentation. The difference between a useful TARA and a compliance artefact is usually method discipline, not effort.
· AutoSec Engineering Team · 2 min read
Read article
Discuss this with a specialist
If this applies to a programme you are working on, we are happy to talk it through.