Automotive software teams should first learn what UN Regulation 155 requires of the vehicle manufacturer, because suppliers feel those duties through contracts. Prioritize risk assessment inputs, vulnerability monitoring, supplier evidence, testing records and a path for security updates. Everything else follows from those five.
Who does the regulation actually bind?
UN Regulation 155 (R155) is addressed to vehicle manufacturers. It requires a valid Certificate of Compliance for a Cyber Security Management System, which is valid for a maximum of three years unless withdrawn, before a vehicle type can be approved. Suppliers are not certified under it, but the text pulls them in: the manufacturer must show how its system manages dependencies on contracted suppliers and service providers (7.2.2.5) and must identify and manage supplier-related risks for each vehicle type (7.3.2).
If you ship an ECU, middleware or a cloud service to an OEM, expect those clauses to arrive as questionnaire items, contract clauses and audit requests.
Priority 1: feed the risk assessment
The manufacturer must perform an exhaustive risk assessment covering the individual elements of a vehicle type and their interactions (7.3.3), and keep it current (7.2.2.2 f). Your job is to supply accurate component facts: what your software does, what interfaces it exposes, what third-party code it contains and what threats you considered. Keep a short architecture note and a dependency inventory per release.
Priority 2: monitoring and fast response
R155 expects processes to monitor, detect and respond to cyberattacks, threats and vulnerabilities (7.2.2.2 g), and says issues needing a response must be mitigated within a reasonable timeframe (7.2.2.3). Monitoring must be continual and include vehicles after first registration (7.2.2.4). The manufacturer also reports monitoring outcomes to the approval authority at least once a year (7.4.1).
For a software supplier, that means you must know quickly when a flaw lands in a component you ship. Match your dependency list against new advisories, and agree a notification path with each OEM customer.
Priority 3: testing evidence
The manufacturer must perform appropriate and sufficient testing before type approval to verify security measures (7.3.6). Keep test plans, results, defects found and fixes, tied to release numbers. A tester should be able to open one folder per release and see what ran.
Priority 4: supplier evidence you can hand over
Constructed example. An OEM asks a tier-one supplier for proof that a gateway module's open-source components are tracked. The supplier sends a machine-readable inventory for the shipped build, a list of known vulnerabilities found and their status, and the date of the last scan. The OEM files it under 7.3.2. The exchange takes an hour because the supplier produced the artifacts as part of its build, not in response to the request.
Priority 5: a path for security updates
R155 has a companion, R156, on software update management. This post relies only on R155 text, so read R156 directly for its requirements. The practical point for engineers: if you find a vulnerability and cannot deliver a fix in the field, your risk assessment and your customer's both have a hole.
What to do
- Ask each OEM customer which R155 clauses they expect you to support, in writing.
- Generate a dependency inventory with every release build and archive it.
- Subscribe your inventory to vulnerability advisories and set an internal response clock by severity.
- Keep per-release test evidence in one place.
- Write a one-page supplier security summary: architecture, interfaces, update method, contact for vulnerability reports.
- Review the process with a person from quality management, since many OEM audits start there.
- Read ISO/SAE 21434 for the engineering lifecycle detail, as R155 does not replace it.
Safeguard can produce dependency inventories and vulnerability findings from your repositories and tie them to pull request gates. It does not make a product compliant, and certification belongs to the manufacturer and approval authority.
Quick check
Do suppliers need their own R155 certificate?
No. The Certificate of Compliance is issued to the vehicle manufacturer for its management system. Suppliers support it through contractual evidence.
Does R155 say how fast I must patch?
It says threats and vulnerabilities requiring a response must be mitigated within a reasonable timeframe (7.2.2.3). It gives no fixed number of days.
Sources
Last reviewed: 18 October 2026.
