Connected and Autonomous Vehicle Security Guide: UN R155, ISO/SAE 21434 and Fleet Credentials

A connected vehicle is a distributed system on wheels, and most of its real attack surface sits in the back end, the update pipeline and the credentials that tie them together. Telematics units, cellular modems, companion apps, OEM clouds, dealer and fleet portals, over-the-air (OTA) update servers and V2X radios all hold keys that, if mishandled, reach many vehicles at once. Regulation has caught up: UN Regulation No 155 requires a certified cyber security management system (CSMS) for type approval, UN Regulation No 156 does the same for software updates, and the US now restricts connectivity and automated driving software with a China or Russia nexus. This guide is for product security, fleet, back-end and supplier security teams. It covers regulation, ISO/SAE 21434, architecture, fleet credentials, V2X PKI, OTA, monitoring and common failures. Regulatory sections are summaries, not legal advice.

Key takeaways

• R155 and R156 are type approval conditions, not guidance. In markets applying them, a vehicle type cannot be approved without a valid CSMS certificate, and vehicles with updatable software need a software update management system (SUMS) certificate, each valid for up to three years.
• ISO/SAE 21434 is the engineering method behind the CSMS. It defines cyber security risk management for road vehicle E/E systems from concept to decommissioning and replaced SAE J3061.
• The back end is in scope. R155 Annex 5 lists back-end servers, update procedures and human actions as threat groups, and NHTSA best practice T.20 requires encryption and authentication between servers and vehicles.
• One vehicle's credential must never open another vehicle. NHTSA practice T.5 says so directly, and T.8 asks manufacturers to minimise global symmetric keys. Fleet API keys and telematics tokens deserve the same rule.
• Supply chain rules now reach software provenance. The US connected vehicles rule (15 CFR part 791, subpart D) prohibits covered software from model year 2027 and covered hardware from model year 2030, with declarations of conformity filed per model year.

The regulatory baseline: UN R155, R156 and the US connected vehicles rule

Contracting parties to the UN 1958 Agreement, including the EU, UK, Japan and Korea, use UN Regulations as type approval requirements. The EU applied R155 and R156 to new vehicle types from July 2022 and to all new vehicles registered from July 2024; the R155 text reflects this with a transitional fallback for type approvals granted before 1 July 2024 (paragraph 7.3.1). The US relies instead on NHTSA guidance and the Commerce rule below.

What R155 actually asks for

• Post-production monitoring (7.2.2.4): monitoring must be continual and include vehicles after first registration, while respecting privacy and consent.
• Suppliers (7.2.2.5 and 7.3.2): the manufacturer must show how it manages dependencies on suppliers, service providers and sub-organisations, so evidence flow-down is part of approval, not procurement hygiene.
• Vehicle type (7.3.5 to 7.3.8): a secured environment for aftermarket software and services, testing before approval, detection and forensic capability, and cryptographic modules in line with consensus standards.
• Certificate lifecycle (6.7 to 6.10): valid for up to three years, checkable at any time, withdrawn if requirements are no longer met.

The US connected vehicles rule, status as of October 2026

The Bureau of Industry and Security final rule (90 FR 5360, January 2025) added subpart D to 15 CFR part 791 and remains in the eCFR as current at the time of writing. VCS covers systems that let a vehicle communicate off-board above 450 MHz. Since 17 March 2026, connected vehicle manufacturers may not knowingly import or sell vehicles with covered software without authorisation. Declarations of conformity are due at least 60 days before the first import or sale for each model year, and material changes must be reported within 60 days of discovery. General Authorization No 1 (limited road use and off-road testing) and No 2 (temporary import for export) carry 10-year recordkeeping. The provenance evidence it needs is the same a CSMS should already hold. Check BIS for amendments and new authorisations before relying on any detail here.

ISO/SAE 21434 in practice: TARA, goals and the operations phase

ISO/SAE 21434 prescribes how to decide controls, and how to keep deciding after the vehicle ships, rather than the controls themselves.

1. Item definition: define the item and its environment, including back-end services, apps and diagnostic tools.
2. Threat analysis and risk assessment (TARA): identify assets and their cyber security properties, threat scenarios, impact (safety, financial, operational, privacy), attack paths and attack feasibility, then determine risk and treatment.
3. Cyber security goals and concept: turn treated risks into goals and requirements allocated to components and suppliers.
4. Development and verification: implement, then verify with testing including penetration testing. NHTSA G.13 and G.14 add that testers should be independent of the development team.
5. Production: protect key injection, debug locking and end-of-line programming, which handle the most sensitive secrets.
6. Operations and decommissioning: monitor, triage vulnerabilities, deliver updates for the support period, then revoke vehicle and back-end credentials at end of life.

Keep a per-ECU and per-vehicle hardware and software inventory with update history (NHTSA G.10 and G.11). Without it you cannot say which vehicles run an affected component. See the SBOM Guide and the Automotive Cybersecurity Guide.

The connected vehicle attack surface

R155 Annex 5 Part A groups threats by where they enter, which is a useful structure for scoping. The mitigation references below are R155 Annex 5 Part B (in-vehicle) and Part C (off-vehicle) identifiers.

Autonomous vehicle specifics

For automated driving, the safety case depends on perception being trustworthy. NHTSA G.6 explicitly asks manufacturers to consider sensor manipulation such as GPS spoofing, lidar and radar jamming and camera blinding. The defensive pattern is to treat each sensor as an untrusted input, cross-check sensors against each other and against maps and vehicle dynamics, and define a minimal risk condition the system enters when confidence drops (G.16 and G.17). Protect remote assistance and teleoperation links for autonomous fleets like privileged access, with mutual authentication, session recording and per-operator accountability. See the OT Security Guide for the cyber-physical safety framing.

Fleet credentials, telematics API keys and vehicle identity

Every vehicle, telematics unit, back-end microservice, fleet integration and dealer tool authenticates with something: an X.509 certificate, a device key in a secure element, an OAuth client secret or an API key. Telematics providers also expose fleet APIs that read location and send lock, unlock or immobilise commands.

• Inventory first: list every consumer of remote command and location APIs, with owner and scopes; command scopes should be rare. See the API Key Management Guide.
• Keep secrets out of source: the Toyota T-Connect key exposure shows the pattern: a subcontractor published part of the T-Connect site source to public GitHub in December 2017 with a customer data server access key inside, and it stayed there until September 2022, affecting 296,019 customers' email addresses and customer numbers. Supplier secret scanning would have caught it. See the Secrets Management Guide.
• Assume engineering clouds hold telemetry: in the Tesla Kubernetes cryptojacking case, an unauthenticated Kubernetes console exposed AWS credentials in a pod that could reach an S3 bucket holding vehicle telemetry. Test fleets and engineering environments need production-grade identity controls.
• Bind device identity to hardware: generate keys inside the secure element where possible. See the Device and IoT Identity Guide and Identity for IoT Fleets Guide.

V2X PKI: IEEE 1609.2 and the SCMS

V2X safety messages are broadcast to anyone in range, so they cannot rely on sessions or encryption for trust. IEEE 1609.2 defines secure message formats and processing for WAVE application and management messages; the 2022 edition has been superseded by IEEE 1609.2-2025. The Security Credential Management System (SCMS), designed by the Crash Avoidance Metrics Partners under a USDOT agreement, is the PKI that issues the certificates those messages are signed with.

In the published design, pseudonym certificates are valid for one week with at least 20 valid at once, delivered in batches, and butterfly key expansion lets a device submit one seed per key type instead of thousands of public keys. Operators should protect enrolment key injection, monitor misbehaviour reports and revoke V2X certificates at decommissioning. See the Machine Identity, PKI and Certificate Lifecycle Guide.

Secure OTA updates under R156

R156 separates organisational duties (the SUMS) from vehicle type duties. Map the update pipeline to both.

• Identification: software versions and relevant hardware uniquely identified with integrity validation data (7.1.1.2); RXSWIN before and after each update accessible and verifiable (7.1.1.3, 7.1.1.4); an auditable RXSWIN register (7.1.2.3).
• Targeting and compatibility: identify target vehicles and confirm compatibility with their configuration before release (7.1.1.6, 7.1.1.7), and assess whether the update affects type approved systems (7.1.1.8 to 7.1.1.10).
• Protection: protect updates against manipulation before initiation and protect the update system itself (7.1.3.1, 7.1.3.2); on the vehicle, protect authenticity and integrity against compromise and invalid updates (7.2.1.1). NHTSA T.22 and T.23 add digital signing and prevention of rollback and downgrade.
• Safe execution: recovery to the previous version or a safe state after a failed or interrupted update (7.2.2.1.1), enough power to finish including recovery (7.2.2.1.2), and no driving where execution while driving is unsafe (7.2.2.3).
• User information: inform users before the update (purpose, changes, duration, unavailable functions) and after it (success or failure) (7.2.2.2, 7.2.2.4).

Design the signing chain so one compromised release server cannot sign for every ECU family. The MSI signing keys leak shows how hard firmware signing keys are to revoke once they are in devices. See the Firmware and Boot Security Guide and the Software Supply Chain Security Guide.

Choosing approaches: decision guidance

• Symmetric vs public key for diagnostics: symmetric seed-key schemes are cheap on small ECUs but tend towards shared secrets. NHTSA T.8 prefers public key approaches. Where an ECU cannot do asymmetric crypto, derive per-ECU symmetric keys from a back-end master held in an HSM, never a model-wide constant.
• Static API keys vs OAuth for fleet integrations: API keys are simple for small fleet customers; OAuth client credentials with scopes and short-lived tokens suit integrators and anything that can send commands. Allow API keys only for read scopes, if at all.
• Vehicle security operations centre (VSOC) build vs outsource: large OEMs typically run their own VSOC because R155 7.2.2.4 monitoring must understand vehicle-specific telemetry. Smaller manufacturers often outsource but still own triage and the evidence for annual reporting under 7.4.1.
• Small fleets and operators: you hold credentials, not type approvals. Prioritise telematics MFA, scoped integration credentials and driver and vehicle offboarding.

Detection, monitoring and metrics

R155 7.3.7 and NHTSA T.12 and T.13 require detection and logs that can reconstruct an attack, reviewed across vehicles. Useful sources:

• Vehicle side: intrusion detection on in-vehicle networks (unexpected diagnostic sessions, message rate anomalies on gateways), failed signature checks, secure boot failures and debug port activity.
• Back end: remote command volume per integration, location queries per API client, authentication failures, new OAuth clients, certificate issuance and revocation events, and update campaign approvals.
• Supply chain: vulnerability feeds matched to the ECU inventory, and Auto-ISAC sharing (NHTSA G.25).

Framework mapping

Common failure patterns

• Back-end keys in supplier code: credentials committed to a contractor's public repository, as in the Toyota T-Connect exposure, where a key sat on GitHub for almost five years. Supplier secret scanning is rarely in the CSMS supplier process.
• Fleet-wide secrets: one symmetric diagnostic or unlock key per model line, so extraction from one vehicle works on all of them, contrary to NHTSA T.5.
• Over-scoped integration credentials: one ownerless fleet API key that reads location and sends unlock commands, shared across partners.
• Update pipeline as a single point of trust: one signing key able to push to every ECU family.
• Paper CSMS: documented processes but no working post-production monitoring behind the 7.4.1 annual report.

Implementation roadmap

1. Baseline (first 90 days): build the vehicle and back-end inventory, give every credential type above an owner, and run secret scanning across internal and supplier repositories.
2. Close fleet-wide exposure: rotate leaked or shared back-end keys, split read and command scopes, and enforce MFA on fleet and dealer portals, piloting with one integration partner first.
3. Harden the update path: HSM-held signing keys, split campaign approval and anti-rollback; test recovery on a pilot ring of engineering vehicles before staged rollout, keeping the previous signed image as the rollback path.
4. Stand up monitoring: feed vehicle IDS, back-end authentication and command logs into a VSOC and exercise a cross-fleet incident (NHTSA G.34).
5. Formalise evidence: map processes to R155 7.2.2.2 and R156 7.1, collect supplier evidence, prepare BIS declarations where relevant, and audit well before certificate renewal.

Practitioner checklist

• Every vehicle, TCU and gateway has a unique credential; no extracted key works on a second vehicle.
• Diagnostic and reprogramming access uses per-vehicle or PKI-based authentication, and debug interfaces are locked in production.
• Fleet and telematics integrations use scoped, short-lived credentials, with command scopes reviewed quarterly.
• Secret scanning covers internal and supplier repositories, and supplier contracts require rotation on exposure.
• OTA packages are signed with HSM-held keys, anti-rollback is enforced and recovery to a safe state is tested.
• An auditable RXSWIN and software register maps every installed version to vehicles.
• VSOC monitoring covers vehicle IDS, back-end authentication, remote commands and certificate events.
• V2X enrolment, pseudonym issuance and revocation are part of production and decommissioning processes.
• CSMS and SUMS evidence is mapped to R155 and R156 clauses and audited before renewal.
• US declarations of conformity and material change reporting are owned and scheduled where the BIS rule applies.

Standards and references

• UNECE (EUR-Lex copy): UN Regulation No 155, Cyber security and cyber security management system
• UNECE (EUR-Lex copy): UN Regulation No 156, Software update and software update management system
• ISO: ISO/SAE 21434:2021 Road vehicles, Cybersecurity engineering
• NHTSA: Cybersecurity Best Practices for the Safety of Modern Vehicles
• US Department of Commerce, BIS: Securing the ICTS Supply Chain, Connected Vehicles (final rule)
• eCFR: 15 CFR 791.300, Connected vehicles purpose and scope
• IEEE: 1609.2, Security Services for Application and Management Messages
• Brecht et al.: A Security Credential Management System for V2X Communications

Related NHI Mgmt Group resources: Automotive Cybersecurity Guide · IoT Security Guide · Device and IoT Identity Guide · EV Charging Security Guide · Machine Identity, PKI and Certificate Lifecycle Guide. This guide summarises UN R155, UN R156 and the US connected vehicles rule and is not legal advice.