Secure Updates
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.
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.
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.
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.
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
Automotive cybersecurity engineering
Engineers working on vehicle cybersecurity concepts, requirements, embedded implementation, and verification across OEM and supplier programmes.
More from this authorRegulations
MoRTH’s draft V2V framework puts factory-installed C-V2X On-Board Units on a phased path for Indian vehicle categories L, M, and N. AIS-230 also brings cybersecurity and communication-security requirements that Indian OEM and Tier-1 programmes must treat as engineering work—not only radio compliance.
· AutoSec Engineering Team · 4 min read
Read articleVSOC
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 articlePenetration Testing
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 articleIf this applies to a programme you are working on, we are happy to talk it through.
