Scenario status. This is an engineering threat scenario, not a reported manufacturing incident. UN R155, UN R156 and secure-development guidance support the lifecycle controls; they do not prove that this specific attack path has occurred.

The factory creates product identity

Modern vehicle production does more than assemble hardware. Manufacturing stations may flash software, write configuration, inject keys or certificates, initialise immobiliser functions and establish identifiers that will be relied upon throughout the vehicle lifecycle.

UN Regulation No. 155 requires manufacturers to manage cybersecurity risks and support monitoring and response across the vehicle lifecycle. UN Regulation No. 156 requires controlled software-update processes, software identification, compatibility checks and integrity of updates.

Those objectives can be undermined if the manufacturing environment that creates the initial software state is not trustworthy. Secure boot can prove that a binary is correctly signed while still failing to answer whether the correct approved binary was signed and provisioned to the correct ECU.

What this diagram shows

This is an engineering risk scenario: a compromised provisioning or flashing path could establish an incorrect software or identity baseline before the vehicle enters service.

Trust and authority pathHow a Software-Defined Vehicle Could Inherit Compromise Before Delivery
Trust pressure / decision point Governed state or evidence domain
Authority and evidence flow
Evidence domainApproved buildEngineering approves the artefact
→
Evidence domainSigning / releaseCryptographic authority authorises release
→
Trust pressureFlashing stationPlant OT deploys at scale
→
Evidence domainECU / vehicleVehicle inherits software and identity
Decision gate

Can each vehicle software state be traced to an approved build, authorised signature and identified manufacturing station?

YESThe decision can rely on bounded, auditable trust.
NOThe residual authority or evidence gap remains material.
How to read this: the dark node marks the point where trust can be lost or authority can expand. Arrows represent control, evidence or dependency relationships, not necessarily direct network links.

Release provenance must cross the IT/OT boundary

NIST SSDF calls for protection of software from tampering and collection of provenance data. In an automotive plant, provenance should continue from source and build through signing, distribution, flashing station, ECU and final product record.

That means separating build authority, signing authority and plant deployment authority where feasible, using station identities rather than shared credentials, recording hashes and versions at flashing, and reconciling the deployed state with the approved release.

The objective is not to make production fragile. It is to ensure that a compromised workstation or supplier path cannot silently turn a legitimate manufacturing process into a fleet-scale software distribution mechanism.

Manufacturing is part of the product-security chain because it creates the software and cryptographic state the vehicle will trust in service.
The decision
Treat flashing and provisioning as product-security release controls with end-to-end provenance.
Operational checks
  • Record software hash/version per ECU and vehicle.
  • Use individual station identities and least privilege.
  • Separate signing keys from routine plant workstations.
  • Reconcile plant deployment records with approved releases.
  • Define revoke/reflash response for compromised provisioning infrastructure.
Related episodeListen to the podcast version→LinkedInJoin the discussion↗
Continue reading

Related analysis

Product Security · Supply ChainA VEX Statement Is a Claim That Needs EvidenceRead →Automotive · Product SecurityAftermarket Security Devices Can Become Part of the Vehicle Attack SurfaceRead →OT & ICS · Supply ChainWhen Legitimate Engineering Workflows Can Carry Malicious Control LogicRead →
AG
Written by

Antonio González, PhD

Cybersecurity practitioner focused on product security, OT/ICS and cyber-physical systems. Cybersecurity Under Pressure translates incident evidence into engineering and business decisions.

About →LinkedIn ↗
Source record

Sources & further reading

3 cited sourcesHow we source →
← All analysisCompanion episode →