A connected vehicle is a distributed computer with safety-relevant interfaces, long service life and software supplied by many organisations. European type-approval rules make cybersecurity and update governance a vehicle lifecycle concern, not just an infotainment hardening task. Here is how to connect the regulatory frame to architecture, software delivery and fleet response.
UN Regulation No. 155 (R155) addresses vehicle cybersecurity and a manufacturer’s Cyber Security Management System (CSMS). UN Regulation No. 156 (R156) addresses software updates and the Software Update Management System (SUMS). In the EU, vehicle cybersecurity forms part of the type-approval framework under Regulation (EU) 2019/2144. The European Commission states that the relevant rules applied to new vehicle types from 2022 and all new vehicles from 7 July 2024, with scope extensions for some categories continuing later. Check the current consolidated law and vehicle category for a real approval decision.
The engineering takeaway is lifecycle coverage. UNECE materials describe risk identification, assessment and treatment, security testing, continual field monitoring, vulnerability response and supplier dependencies. For updates, the system needs trustworthy identification of software versions and integrity data, controlled deployment and a record of what changed. A certificate or process document alone cannot protect a fleet if the actual build and update path are untraceable.
Trust boundary sketch for threat modelling. Actual vehicle architecture and separation vary by manufacturer and model.
Start with assets and safety impact, then draw data and control paths. Which interface can write to a network segment? Can a mobile account initiate a privileged command? Which backend roles can target a campaign? Can supplier software cross a gateway boundary? A threat model should connect attacker capability to a vehicle function, plausible consequence, mitigating control and verification evidence. Do not treat every connected feature as equally safety-critical.
R155 is broader than a vulnerability scanner. It expects the manufacturer’s CSMS to manage risk across development, production and post-production, including supplier relationships, current risk assessment, testing, monitoring and response. A software team can make those processes concrete through linked engineering records:
The exact approval evidence belongs to the manufacturer and applicable authority process. For a software organisation, practical evidence includes risk assessments tied to released variants, test reports, supplier interface controls, vulnerability decisions, campaign outcomes and documented rationale when an issue cannot be fixed immediately. Connect the evidence to build identifiers and vehicle configurations rather than collecting disconnected PDFs at audit time.
An update campaign starts with a reason to change and a precise set of compatible vehicles. The service must identify the target software and hardware configuration, publish an authenticated manifest, verify artifact integrity and authenticity, check prerequisites, and orchestrate a safe rollout. Installation needs power and vehicle-state rules, dependency ordering, failure reporting and a recovery strategy appropriate to the ECU. A successful HTTP transfer is not proof of a successful, safe update.
A fleet vulnerability response needs to answer: which vehicle variants contain the component, which supplier builds are affected, what exposure exists, whether exploitation is observed, and what mitigation is safe. Maintain an inventory linking VIN or an appropriately protected vehicle identifier to hardware configuration, software bill of materials, ECU firmware and update campaign. Restrict access to this mapping and retain only the telemetry needed for security and operations.
Separate detection from action. A backend anomaly should first be validated against known software versions and network conditions. A remote command that changes a vehicle state needs stronger authorization and safety controls than a request for diagnostic status. Build a response ladder: enrich evidence, limit an exposed interface, block a campaign, issue a patch, notify owners or dealers, and escalate to a physical service action where necessary.
| Threat path | Engineering control | Operational evidence | Failure to avoid |
|---|---|---|---|
| Compromised mobile or cloud account | Phishing-resistant privileged access, scoped tokens, step-up for safety-relevant actions. | Authorization decision, account event, command trace and revocation test. | Treating successful login as proof every command is safe. |
| Malicious or vulnerable supplier component | Contracted security interface, component inventory, provenance, testing and vulnerability notification path. | Supplier version mapping, assessment, issue ownership and mitigation record. | Assuming a supplier certificate replaces integration risk analysis. |
| Forged or mis-targeted update | Signed manifest and payload, secure boot chain, compatibility checks and scoped campaign approval. | Signer identity, target set, digest, install state and test evidence. | Using transport encryption as a substitute for artifact authenticity. |
| Telemetry exposes driver data | Purpose limitation, minimised events, access control, retention and privacy review. | Field inventory, access logs and deletion schedule. | Collecting all vehicle logs indefinitely “just in case.” |
| Exploit found after sale | Continuous intake, fleet impact query, mitigation options and staged campaign. | Time to assess, affected population, response decisions and effectiveness check. | Closing a ticket without proving field risk changed. |
Vehicle signals may reveal location, routines, driver behavior or other personal information. Security monitoring needs a defined purpose and data minimisation: collect security-relevant events, not continuous raw context by default; separate identifiers from diagnostic payloads where feasible; set retention and access boundaries; and ensure incident access is logged. At the same time, aggressive deletion must not remove evidence needed for a safety investigation or a legally required record. Resolve those competing needs through documented retention classes and controlled legal review.
I would connect the secure software supply chain to fleet operations: source and supplier attestations feed a release catalogue; signed builds bind firmware, hardware compatibility and test results; campaign orchestration checks eligibility and rollout policy; vehicle reports return signed version and health events; and a vulnerability service maps a new advisory to affected fleet variants. A dashboard would show campaign progress, failure cohorts, exposure and response ownership without turning driver-level data into an unrestricted analytics feed.
Then exercise realistic incidents: compromised campaign credentials, a signing-key rotation, a faulty update in a small cohort, a supplier disclosure, loss of connectivity during installation and a request to remove a vulnerable component from service. Record expected safe states and verify them on bench hardware before any road deployment.
Connected vehicle security is a lifecycle and systems problem. R155 and R156 provide an approval and management framework; the engineering work is to connect risk, supplier assurance, secure build, authenticated updates, privacy-aware monitoring and fleet response to traceable vehicle configurations. A good program can answer not only “is this component patched?” but “which vehicles are affected, what is safe to do next, and how will we know the mitigation worked?”
Editorial note: This article is an engineering overview, not a type-approval checklist or legal opinion. Regulatory applicability and required evidence vary by vehicle category, approval date and jurisdiction.