Make the approval evidence survive the next software release

UN R155 and R156 are type-approval regulations—not generic penetration-test checklists. Audit the CSMS, SUMS, and each vehicle type as a connected evidence system spanning suppliers, risk treatment, RXSWIN, release decisions, fleet monitoring, and safe update execution.

Establish the approval scope Inspect the evidence model

Pin the market, category, regulation series, and approval object

“UN compliant” is not a scope. The regulations operate through Contracting Parties to the 1958 Agreement and regional type- approval law. Begin with the market and authority, then record the exact series and transition provisions applied to the vehicle. See the UNECE R155 and R156 source pages.

R155 regulatory scope

The 2025 documentation text covers L, M, N and O vehicles fitted with at least one ECU. Regional adoption and vehicle-category dates still control whether and how that text applies.

R156 regulatory scope

The original text covers M, N, O, R, S and T categories that permit software updates. Record the series accepted by the authority and whether later amendments or regional rules modify the baseline.

Management-system assessment

CSMS and SUMS certificates concern the manufacturer's organizational processes. Their maximum validity is three years, subject to notification, review, and possible withdrawal.

Vehicle-type application

Approval evidence must show that the certified processes were applied to the specific vehicle type and its relevant software, interfaces, suppliers, configurations, and changes.

EU R155 milestones

The General Safety Regulation uses Annex II code B for relevant M, N, and O categories: refusal of new EU type approvals from 6 July 2022 and prohibition of registration, placing on the market, or entry into service of non-compliant new vehicles from 7 July 2024. Category and exemption detail still matters.

Source: Regulation 2019/2144.

EU R156 milestones

Delegated Regulation 2022/2236 uses a more specific transition: certain new types executing approval-relevant post-registration updates from 6 July 2022, broader new-type and new-vehicle dates from 7 July 2024, and later dates for defined complete, completed, small-series, and special-purpose cases.

Source: Delegated Regulation 2022/2236.

Do not freeze the series

The published texts, interpretation documents, and amendments continue to evolve. Store the authority, market, regulation series, supplement, effective date, vehicle category, and approval date on every requirement and decision—not only in a policy PDF.

Regulation, interpretation, standards, and implementation are different layers

Treating every document as equally binding produces both false findings and missing evidence. The audit register should state why each control exists and who can approve an alternative.

Binding in the applicable approval regime

The accepted UN Regulation text plus regional law, authority decisions, approval conditions, conformity-of-production obligations, and market-surveillance action define the enforceable baseline for the vehicle and manufacturer in scope.

UNECE interpretation guidance

R155 and R156 interpretation documents illustrate possible evidence and support consistent assessment. They describe themselves as guidance and do not add obligations. Record when an authority or technical service expects a particular interpretation.

Voluntary engineering standards

ISO/SAE 21434 and ISO 24089 can structure lifecycle cybersecurity and update-engineering work products. They are valuable mappings, but standard conformance is not a substitute for CSMS, SUMS, or vehicle-type approval.

Yarify implementation recommendations

The evidence graph, automated checks, finding taxonomy, API payload, sampling strategy, and delivery plan on this page are engineering recommendations. They must be tailored to the authority, technical service, organization, vehicle, and safety case.

Reference the R155 and R156 interpretation documents, plus the official ISO/SAE 21434 and ISO 24089 scopes.

Build one evidence graph across two management systems

Store authoritative work products in their source systems, then index immutable versions and relationships for audit. A copied folder tree cannot explain which risk, vehicle configuration, release, supplier change, or approval decision a document supports.

Engineering sources

Vehicle architecture and item definitions
Risk assessments and treatment decisions
Supplier work products and contracts
Requirements, changes, tests, and releases
Fleet telemetry and vulnerability intake

Approval evidence graph

Requirement and series registry
CSMS and SUMS process controls
Vehicle-type and variant mapping
RXSWIN and software baselines
Findings, decisions, and authority exchanges

Controlled outputs

System-assessment evidence pack
Vehicle-type approval dossier
Update-impact decision record
Annual monitoring report support
Conformity and remediation dashboard

A traceable audit finding

Illustrative model

{
  "findingId": "R156-VT-0142",
  "requirement": "UN-R156@applied-series:7.2.2.3",
  "approvalObject": "vehicle-type:EU-e9*2024/1257*0042",
  "configuration": "platform-X / release-24.9 / market-EU",
  "assertion": "target vehicles are compatible with the update",
  "evidence": [
    { "ref": "plm://compatibility/8841", "version": "sha256:…" },
    { "ref": "test://campaign/OTAU-319", "version": "sha256:…" }
  ],
  "result": "gap",
  "reason": "supplier ECU variant B absent from compatibility test set",
  "owner": "software-update-assurance",
  "dueAt": "2026-09-18",
  "retest": null,
  "authorityDisclosure": "restricted-summary"
}

This is a recommended internal record, not a UNECE schema. Keep restricted supplier evidence behind access controls while making its identity, version, reviewer, conclusion, and disclosure status visible to the approval chain.

R155 is a lifecycle control loop, not a launch gate

The CSMS spans development, production, and post-production. Vehicle-type evidence must remain linked to what is built and what is observed in the field. See the current R155 documentation text.

Govern and assign accountability

Show organizational dependencies, decision rights, competence, escalation, independence, and repeatable processes—not only a policy signed before assessment.

Identify and assess risk

Maintain an exhaustive vehicle-type risk assessment covering interactions with other systems and relevant Annex 5 threats, plus newly discovered threats outside the annex.

Treat and verify

Trace risks to proportionate mitigations, requirements, implementation, test conditions, results, anomalies, acceptance decisions, and evidence that controls are effective before approval.

Control suppliers and dependencies

Define required work products, confidentiality paths, change and vulnerability notification, support periods, monitoring inputs, remediation clocks, and evidence access across the supply chain.

Monitor and respond

Connect vulnerability sources, vehicle and backend signals, triage, detection, incident analysis, response, mitigation, recovery, and disclosure while respecting privacy and access law.

Report and improve

Prepare at least annual monitoring outcomes for the authority or technical service, including new attacks, mitigation effectiveness, and additional action, then feed lessons back into risks and controls.

Test the joins, not only the artifacts

Sample from a field vulnerability back to affected vehicles, supplier evidence, the original risk decision, implemented control, validation, response, and any software update. Then run the path forward from an architecture change to approval impact and post-production monitoring.

Supplier risk accepted without an accountable vehicle-level decision
Threat model and production configuration no longer agree
Mitigation tested, but not on the variant submitted for approval
Fleet detection exists with no response owner or evidence retention
Incident remediation bypasses software-update approval assessment
Annual report cannot reproduce the population, period, or source data

R156 turns every update into a controlled approval decision

The SUMS must know the approved baseline, the proposed change, affected characteristics, compatible target population, and safe execution outcome. The release pipeline can automate evidence; it should not conceal the decision. See UN R156.

Configuration and RXSWIN

Maintain initial and updated hardware and software versions, integrity data, dependencies, and auditable RXSWIN relationships. Verify that the installed versions are consistent with the identifier.

Approval-impact classification

Assess whether the update affects approved systems, characteristics, parameters, or safe continued operation, or adds or alters a function. Record approval sought and the resulting disposition.

Target and compatibility

Resolve eligible vehicles against the last known hardware and software configuration. Prove compatibility before deployment and preserve the population query, exclusions, and snapshot.

Verification and validation

Link the package, purpose, affected functions, cybersecurity and safety analysis, verification, validation, signing, integrity, release approval, and known limitations to one immutable release record.

Safe execution and recovery

For OTA, enforce power and vehicle-state prerequisites, required skilled action, disabled functions, authenticity and integrity checks, interruption handling, and restoration or a safe state after failure.

User and fleet evidence

Communicate purpose, criticality, expected time, unavailable functionality, prerequisites, result, and relevant manual changes. Reconcile delivery, installation, activation, failure, rollback, and unresolved vehicles.

An OTA dashboard is not a SUMS

Campaign tooling may prove distribution and installation, but the regulated chain begins earlier: version and dependency control, RXSWIN mapping, approval-impact analysis, target compatibility, secure package preparation, verification and validation, and release authorization. It continues through user information, failure recovery, reconciliation, and retained records accessible for approval, production conformity, market surveillance, recalls, and roadworthiness activities.

Audit with evidence tests that can fail clearly

A mature audit does more than confirm documents exist. Define the assertion, population, sample, authoritative source, freshness, expected result, exception owner, and retest method for each test.

Audit areaAssertionEvidence testFailure signal

Supplier changeCybersecurity-relevant dependency changes enter vehicle risk and approval decisions.Select released supplier changes; trace notice, impact, risk, validation, release, and authority disposition.Release precedes assessed notice

Vehicle riskRelevant threats and interactions have proportionate, verified mitigations.Sample high and accepted risks; reproduce architecture, treatment, requirement, implementation, test, and acceptance.Broken or stale trace

Fleet monitoringSignals cover claimed attacks and drive timely analysis and response.Inject or replay representative conditions; inspect detection, triage, affected population, escalation, and retained evidence.Claimed control cannot be observed

Update impactEach release has a reproducible type-approval impact decision.Sample releases from source control and deployed fleet; reconcile affected functions, parameters, approvals, approver, and outcome.Release missing from SUMS record

CompatibilityOnly compatible vehicle configurations enter a campaign.Re-run target logic against a pinned configuration snapshot and negative variants; compare campaign membership.Unsupported variant eligible

OTA failureInterrupted or failed updates leave the vehicle recoverable or safe.Exercise power loss, connectivity loss, signature failure, storage exhaustion, and partial installation on representative configurations.Unsafe or ambiguous terminal state

Preserve negative evidence

Keep rejected targets, failed signatures, blocked preconditions, interrupted installs, rolled-back configurations, unresolved vehicles, and waived findings. Success-only telemetry cannot demonstrate control effectiveness.

Separate defect from risk

A missing artifact, control failure, cybersecurity risk, safety impact, non-conformity, and approval consequence are related but distinct. Let accountable roles assess each layer explicitly.

Restrict without obscuring

Use need-to-know access, redacted exports, controlled viewing, and evidence attestations for sensitive supplier or vulnerability material. Still expose version, owner, review status, and conclusion to the audit chain.

Define system boundaries before connecting adjacent controls

Automotive cybersecurity touches product security, factory OT, connected services, privacy, and enterprise incident response. Reuse evidence deliberately without claiming one regime satisfies another.

Production and factory OT

Connect conformity-of-production and manufacturing changes to passive OT asset, exposure, segmentation, remote-access, and incident evidence. Keep the plant-security boundary explicit.

Explore the OT audit →

Vulnerability and component evidence

Reuse SBOM, vulnerability intake, triage, remediation, and disclosure infrastructure while applying the automotive type- approval boundary and vehicle-specific risk decision.

Map the product-security workflow →

Connected-vehicle telemetry and privacy

Fleet monitoring may process vehicle, user, location, and security-event data across vendors and regions. Bind collection, routing, access, retention, and incident evidence to a separately governed privacy and data-sovereignty architecture.

Design controlled data routing →

Prove one vehicle type and one real update end to end

Start with an approval-relevant slice that crosses organizational and technical boundaries. The pilot should leave reusable mappings, tests, evidence contracts, and remediation ownership—not a presentation-only maturity score.

Establish legal and approval scope
Confirm markets, authorities, vehicle categories, regulation series, dates, approval objects, manufacturer roles, multistage boundaries, and technical-service expectations.
Select the evidence thread
Choose one representative vehicle type, cybersecurity risk, supplier dependency, production configuration, field signal, and software update with access to accountable owners.
Map requirements and systems
Trace R155 and R156 clauses to processes, work products, source systems, identifiers, versions, owners, reviewers, retention, disclosures, and existing ISO mappings.
Test the control joins
Walk samples in both directions; replay target selection and approval impact; exercise negative update states; compare documented process with production evidence.
Remediate and retest
Rank findings by evidence gap, control failure, cybersecurity and safety risk, approval exposure, reach, and recurrence. Assign decisions and capture objective retest results.
Operationalize the pack
Generate controlled system and vehicle-type views, update decision records, monitoring-report inputs, management metrics, authority exports, and a rollout plan for further types.

Scope register

Market, authority, category, series, dates, approval objects, actors, and explicit exclusions

Traceability map

Requirements to processes, vehicle risks, suppliers, configurations, releases, tests, and decisions

Evidence tests

Reproducible queries, samples, negative cases, results, findings, remediation, and retest

Release plan

Prioritized gaps, owners, dependencies, authority touchpoints, rollout waves, and operating metrics

Questions an approval evidence audit should settle

Are UN R155 and R156 mandatory for every connected vehicle worldwide?

No. They are UN Regulations under the 1958 Agreement. Applicability depends on the Contracting Party, the regulation and series it applies, vehicle category, approval route, and market dates. In the EU, R155 is incorporated through Regulation 2019/2144 and R156 through the type-approval framework as amended by Delegated Regulation 2022/2236. Confirm the exact category, approval authority, series, and transition before defining an audit scope.

What is the difference between a CSMS audit and vehicle-type approval?

The CSMS assessment asks whether the manufacturer has effective cybersecurity processes across development, production, and post-production. Vehicle-type approval asks whether those processes were applied to the specific type: supplier risks, critical elements, risk assessment, mitigations, testing, monitoring and forensic capability all need traceable evidence. A valid CSMS certificate is necessary evidence, not proof that every vehicle type or change is compliant.

Is ISO/SAE 21434 certification the same as UN R155 approval?

No. ISO/SAE 21434 is a voluntary cybersecurity-engineering standard and can organize persuasive work products. UN R155 is a type-approval regulation applied by the relevant authority under its legal regime. Standard conformance or certification does not itself issue a CSMS certificate or vehicle-type approval, and an audit should preserve the mapping between each work product and the actual regulatory requirement.

Is a vehicle penetration test enough for UN R155?

No. Testing is one part of the evidence. R155 also requires governance, lifecycle processes, an exhaustive vehicle-type risk assessment, supplier and dependency management, proportionate mitigations, monitoring and response capability, support for attack analysis, and reporting. A penetration test without scope, configuration, threat coverage, remediation, retest, and linkage to the approved type is weak evidence.

Are suppliers directly responsible for the manufacturer's approval?

The manufacturer seeking approval must demonstrate that supplier-related risks are identified and managed and that dependencies on suppliers, service providers, and subsidiaries are controlled. Contracts can require work products, notification, vulnerability handling, update support, and audit rights, but they do not transfer the applicant's approval accountability. Evidence needs to remain usable even when sensitive supplier detail cannot be disclosed broadly.

What is RXSWIN, and is it the same as a VIN or ECU firmware version?

No. RXSWIN is the regulation-defined software identification number used to represent type-approval-relevant software. The SUMS must maintain auditable relationships between RXSWIN, the relevant software versions and integrity data, approved characteristics, and the vehicles or configurations concerned. A VIN identifies a vehicle and an ECU version identifies one component; neither alone provides that approval mapping.

Does UN R156 apply only to over-the-air updates?

No. Its management-system and record requirements concern software updates generally. Additional vehicle requirements apply when updates are executed over the air, including authenticity and integrity protection, sufficient power, safe vehicle state, user information, execution conditions, and recovery after failure. Workshop, diagnostic-tool, factory, and OTA paths should all be represented in the update evidence model.

Does every software release require a new type approval?

Not automatically. The manufacturer needs a controlled assessment of whether the update affects type-approved characteristics, adds or alters functions, changes approved parameters, affects safe continued operation, or otherwise requires approval or an extension. The decision, inputs, approver, applicable regulation series, and resulting action must be auditable; a ticket label such as 'non-regulatory' is not sufficient evidence.

How long do CSMS and SUMS certificates remain valid?

The regulations specify a maximum three-year validity unless a certificate is withdrawn. Changes that affect the certificate's relevance must be notified, and renewal is not a one-time document refresh: the authority or technical service can review whether processes remain effective. Under the original R156 text, expiry of the SUMS certificate does not by itself invalidate existing vehicle-type approvals, which is different from having permission to ignore the management system.

What should an R155/R156 evidence platform record?

Record the requirement and series, approval object, vehicle and software configuration, accountable owner, source work product and immutable version, supplier relationship, review and test results, exceptions, authority communications, finding state, remediation and retest, and the exact evidence exported. For updates, also retain target selection, compatibility, RXSWIN before and after, approval-impact decision, package integrity, execution prerequisites, outcomes, failures, recovery, and user communications. This is a recommended implementation model, not an official UNECE schema.

Primary sources and status

Reviewed 4 September 2026. Applicable UN Regulation texts, regional incorporation, approval decisions, and market rules form the binding baseline for the vehicle and actor in scope. UNECE interpretation documents are guidance. ISO/SAE 21434 and ISO 24089 are voluntary engineering standards unless made binding by another instrument or contract. Yarify's evidence model, audit tests, automation controls, and pilot plan are implementation recommendations—not legal advice, certification, technical-service assessment, or type approval. Always confirm the current status document, applied series, and authority position.