Regulation explainerAutomotive & Assembly

UNECE R155 and R156 compliance for cybersecurity and OTA software updates

UN R155 and R156 make cybersecurity and software updates part of vehicle type approval. A manufacturer needs an audited management system for each (CSMS and SUMS), then must show for every vehicle type that risks were assessed, mitigations tested, updates protected and recorded, and the fleet monitored after sale. Here are the two assessments, the evidence chain behind them and where AI tools help.

Reviewed 8 min read

On this page
  1. The instruments behind automotive cybersecurity type approval
  2. Management-system audit versus vehicle-type approval
  3. ISO/SAE 21434 and ISO 24089 as the engineering route
  4. The traceability chain an assessor will try to walk
  5. Turning the obligations into engineering and operating work
  6. Where AI tools help in a CSMS and where they stop
  7. One infotainment update moving through three markets
  8. Questions and answers
  9. Sources

The instruments behind automotive cybersecurity type approval

Two UN Regulations set the requirements, regional law sets the dates, and two ISO standards describe how engineering teams usually meet them.

UN R155: cybersecurity and cybersecurity management system

Contracting parties applying it under the UNECE 1958 Agreement[^2]

Applies whenA manufacturer seeks approval of a vehicle type in a market that applies the regulation.

  • Hold a valid CSMS certificate of compliance before a vehicle type can be approved2.
  • Assess risks for the vehicle type, treat them with proportionate mitigations and test those mitigations.
  • Detect and respond to attacks across the fleet, including after first registration, and report monitoring results to the approval authority at least once a year2.
  • Show how risks from contracted suppliers and service providers are managed inside the CSMS.

UN R156: software update and software update management system

UNECE contracting parties that apply R156[^3]

Applies whenVehicles of the type can receive software updates, over the air or in a workshop, that may affect type-approved systems.

  • Run an audited SUMS that records every update, the configurations before and after, and the vehicles targeted3.
  • Keep an auditable register of RXSWINs and protect them against unauthorized change.
  • Protect the authenticity and integrity of updates and ensure a failed update can roll back or reach a safe state3.
  • Inform users before an update about its purpose, duration and any functions unavailable during it, and afterwards about the result.

Regulation (EU) 2019/2144 (General Safety Regulation)

European Union

Applies whenProtection against cyberattacks became a condition for new EU vehicle types from 6 July 2022 and for registering all new vehicles from 7 July 20244.

  • Meet the cyberattack-protection requirement through UN R155 for the relevant vehicle categories.

Commission Delegated Regulation (EU) 2022/2236 (software updates)

European Union

Applies whenThe manufacturer performs updates after registration that affect type-approved characteristics; it applies to new whole-vehicle types from 6 July 2022 and to registration of new complete vehicles from 7 July 20265.

  • Comply with UN R156 where updates touch type-approved systems, checking the separate dates for completed and multi-stage vehicles.

Management-system audit versus vehicle-type approval

Teams often treat compliance as one event. It is two assessments with different questions, owners and lifetimes.

QuestionCSMS or SUMS assessmentVehicle type approval
What is examinedThe organization's processes, responsibilities and governanceOne vehicle type and the evidence that the processes were applied to it
Typical evidenceProcess descriptions, role definitions, supplier interfaces, monitoring and incident proceduresRisk assessment for the type, mitigation and test reports, RXSWIN register, update records
ResultA certificate of compliance for the management systemType approval for the vehicle type, which depends on a valid certificate
How long it lastsUp to three years, then reassessment or extensionRemains in force while the type is produced, subject to monitoring and amendments
Where suppliers appearHow the manufacturer manages dependencies on suppliers and service providersEvidence for supplied ECUs, software and backend services used by the type

Both regulations cap certificate validity at three years before reassessment23. Tier 1 suppliers are not approved themselves; their work products become part of the manufacturer's evidence.

ISO/SAE 21434 and ISO 24089 as the engineering route

The regulations say what must be true, not how to engineer it. Most programs use ISO/SAE 21434, the road-vehicle cybersecurity engineering standard6, to structure threat analysis and risk assessment (TARA), cybersecurity goals, requirements and verification. Its work products map closely to what a technical service asks to see under R155.

ISO 24089 covers software update engineering at organization and project level, including the infrastructure and the assembly of update packages after initial development7. It gives a SUMS its working detail: how update campaigns are planned, how compatibility with each vehicle configuration is checked and how records are kept.

Neither standard is legally mandatory under the UN Regulations, but following them is the most common way to produce evidence an assessor recognizes.

The traceability chain an assessor will try to walk

treatmentverified byapproved buildOTA campaigneventsreassess01Threat scenario02Cybersecurity requirement03Verification evidence04Released software05Vehicles in the field06Monitoring and response
  1. Threat scenario

    An entry in the TARA for the vehicle type, with its risk rating and treatment decision.

  2. Cybersecurity requirement

    The goal or requirement the treatment decision produced, allocated to an ECU, gateway or backend.

  3. Verification evidence

    Test cases, penetration test findings and their closure, linked to the requirement.

  4. Released software

    The build that implements the requirement, signed and identified in the RXSWIN register.

  5. Vehicles in the field

    Which vehicles run which version, known from campaign records and vehicle reports.

  6. Monitoring and response

    Security events and vulnerability reports that can reopen the threat scenario.

Conceptual evidence chain for one threat scenario. It shows the links a CSMS and SUMS should make queryable, not any specific tool or deployment.

Turning the obligations into engineering and operating work

  1. Fix the vehicle-type boundary

    List every ECU, external interface and backend service the type depends on, including supplier-operated services such as telematics. Assessments often stall on interfaces nobody owned.

    Output
    System and interface inventory
    Owner
    Vehicle cybersecurity manager

  2. Run and maintain the TARA

    Identify assets, threat scenarios and attack paths, rate each risk and record a treatment. Check coverage against the threat and mitigation catalogue annexed to R155.

    Output
    TARA with treatment decisions
    Owner
    Security architects with function owners

  3. Define what counts as type-approval relevant

    Decide which software in which ECUs determines type-approved behavior, assign RXSWINs to it and agree the rules for when an update changes an RXSWIN or needs the authority informed.

    Output
    RXSWIN definition and change rules
    Owner
    Homologation with software leads

  4. Engineer the update path

    Sign packages, verify them on the vehicle, check preconditions such as battery state, and design rollback or a safe state for failure. Test the user messages as carefully as the installer.

    Output
    Update pipeline design and test report
    Owner
    OTA platform team

  5. Stand up fleet monitoring

    Collect security-relevant events from vehicles and backends, triage them in a vehicle security operations center (VSOC) and feed findings into incident response and the TARA.

    Output
    VSOC runbook and reporting pack
    Owner
    Security operations

  6. Flow requirements down to suppliers

    Write cybersecurity interface agreements stating which work products each supplier delivers, how vulnerabilities are reported and how long support lasts.

    Output
    Cybersecurity interface agreements
    Owner
    Purchasing with security engineering

Where AI tools help in a CSMS and where they stop

ColdAI's automotive work includes OTA update infrastructure and vehicle intrusion detection1. In both, AI fits the high-volume, pattern-heavy tasks; anything that sets a risk level or releases software stays a signed human decision.

  • If

    Security architects spend days enumerating threat scenarios from architecture models.

    Then

    Use a language model to draft candidate threats and attack paths from the model and the R155 annex, then have engineers accept, edit or reject each one.

    Drafting is faster, but the risk rating and treatment are judgment calls an assessor expects a named engineer to own.

  • If

    The VSOC receives far more vehicle and backend events than analysts can read.

    Then

    Cluster and enrich events automatically and route only correlated cases to analysts, logging every automated suppression.

    Suppression rules are part of the monitoring process the CSMS describes, so they must be reviewable.

  • If

    You want intrusion detection on in-vehicle networks such as CAN.

    Then

    Start with rule-based detection of known-bad patterns and add anomaly models only after measuring false alarms on representative drive data.

    Models running on an ECU are themselves software that needs updating, securing and recording under the SUMS.

One infotainment update moving through three markets

Questions and answers

Do R155 and R156 apply to vehicle platforms designed before the regulations existed?

In the EU, yes for vehicles still being registered: protection against cyberattacks became a condition for all new vehicles, not only new types, under the General Safety Regulation. Legacy architectures predate current threat models, so manufacturers often argue mitigations at the gateway and backend or retire variants. Check each market's transition dates with your homologation team.

Does aftermarket or third-party software on the vehicle fall under these rules?

R155 expects the manufacturer to protect any dedicated environment on the vehicle that hosts aftermarket software, services or applications, and to assess risks from external connections. R156 covers updates the manufacturer performs. Software installed by independent parties outside the manufacturer's process is not part of the SUMS, but the CSMS must consider how it could be used to attack the vehicle.

How do China's vehicle cybersecurity standards relate to R155 and R156?

China has its own mandatory national standards: GB 44495-2024 on vehicle cybersecurity and GB 44496-2024 on software updates, both effective from 1 January 2026 and developed separately from, though influenced by, the WP.29 regulations8. Expect technical differences, so a CSMS built for UNECE markets needs a gap check before it is used for China.

Does every OTA update need a new type approval?

No. Updates that do not affect type-approved systems are recorded in the SUMS but do not change the approval. Updates that do affect them are assessed under the manufacturer's agreed rules, may change an RXSWIN and may require the approval authority to be informed or the approval extended. Agreeing those rules early is what keeps routine updates routine.

Sources

  1. Automotive & Assembly: use cases and delivery process — ColdAI
  2. UN Regulation No 155: uniform provisions concerning the approval of vehicles with regards to cybersecurity and cybersecurity management system — EUR-Lex · checked 10 October 2026
  3. UN Regulation No 156: uniform provisions concerning the approval of vehicles with regards to software update and software updates management system — EUR-Lex · checked 10 October 2026
  4. Regulation (EU) 2019/2144 on type-approval requirements for motor vehicles as regards their general safety — EUR-Lex · checked 10 October 2026
  5. Commission Delegated Regulation (EU) 2022/2236 amending Regulation (EU) 2018/858 as regards software updates — EUR-Lex · checked 10 October 2026
  6. ISO/SAE 21434:2021 Road vehicles — Cybersecurity engineering — International Organization for Standardization · checked 10 October 2026
  7. ISO 24089:2023 Road vehicles — Software update engineering — International Organization for Standardization · checked 10 October 2026
  8. New mandatory standards for vehicle cybersecurity, software updates and automated driving data storage to take effect in 2026 — SESEC (Seconded European Standardization Expert in China) · checked 10 October 2026

More in Automotive & Assembly

Back to Automotive & Assembly

Next step

Send us your CSMS evidence map before the next assessment

Share the vehicle types in scope, your current TARA and RXSWIN approach and the markets you sell into. We will point out the weakest links in the evidence chain and where tooling, including AI, would genuinely save effort.

Review my R155/R156 evidence