Embedded cybersecurity for ECUs under R155 — no CSMS, no type approval.

1. What R155 actually mandates

The first thing we tell a Tier-1 cybersecurity team is that UNECE R155 is not a technical standard you implement — it is a regulation you are measured against, and it works on two levels at once. At the organisation level it requires a certified Cyber Security Management System (CSMS): a process framework, audited by an approval authority or its technical service, that demonstrates the manufacturer can identify, assess and manage cyber risks across the whole vehicle lifecycle. At the vehicle-type level it requires demonstrated cybersecurity engineering for that specific type — evidence that the risks for this vehicle have actually been assessed and treated.

The order is not negotiable. Without a valid CSMS certificate of compliance, no type approval is granted — the type-approval application cannot even proceed. We have watched programmes treat the CSMS as a documentation exercise to be cleaned up near start of production, then discover that the certificate gates the homologation milestone they had already committed to a customer. The CSMS is the entry ticket; the per-type evidence is what you show once you are through the door.

For a supplier this has a sharp consequence. You will rarely hold the type approval yourself — the vehicle manufacturer does — but you will be the source of a large fraction of the evidence the manufacturer’s CSMS depends on. R155 explicitly expects the manufacturer to manage cybersecurity risks arising from suppliers. In practice that obligation is pushed down to you through contracts and interface agreements, and the quality of your evidence becomes the manufacturer’s audit exposure.

2. R155 and ISO/SAE 21434 — the “what” and the “how”

R155 tells you what outcomes are required but is deliberately thin on method. ISO/SAE 21434:2021 — Road vehicles — Cybersecurity engineering — is the recognised how. The regulation and its interpretation documents point to it as the way to demonstrate that a CSMS and the per-type work are adequate, and in our experience an approval authority that sees a clean 21434 work-product trail asks far fewer follow-up questions.

The mapping is reasonably direct once you stop reading them as competitors. R155’s organisational CSMS requirements correspond to 21434’s management clauses — organisational cybersecurity management (Clause 5) and project-dependent cybersecurity management (Clause 6) — while the supplier relationship sits in distributed cybersecurity activities (Clause 7). R155’s demand for risk identification and assessment is satisfied by 21434’s threat analysis and risk assessment (Clause 15, TARA). The concept, product-development, validation, production, operations-and-maintenance and end-of-support clauses (9 through 14) give you the per-type engineering evidence. And R155’s lifecycle and monitoring expectations land on 21434’s continual cybersecurity activities (Clause 8) — cybersecurity monitoring, vulnerability analysis and management, and incident response.

We treat 21434 as the spine and R155 as the acceptance criterion. Build the 21434 work products honestly and the R155 file largely assembles itself; build to R155’s checklist alone and you tend to produce evidence that is present but not traceable — which is exactly what an assessor probes.

3. The CSMS as the prerequisite

A credible CSMS is not a binder. It is a living set of processes, roles, and an evidence catalogue that an auditor can walk end to end. Concretely we look for: defined cybersecurity roles with real authority (a cybersecurity manager who can actually stop a release); a risk-management process that connects TARA to decisions; a defined cybersecurity-case structure; configuration and change management that keeps the security baseline current; and a documented vulnerability-management and incident-response process that runs after start of production, not just during development.

The piece most often pushed down to Tier-1s is the supplier interface. 21434 captures it in the Cybersecurity Interface Agreement, the single work product of Clause 7 (distributed cybersecurity activities) — the cybersecurity counterpart to the Development Interface Agreement that functional-safety teams know from ISO 26262. R155’s expectation that the manufacturer manages supplier risk is operationalised through it. A good agreement nails down who owns each work product, who performs the TARA and at what scope, how cybersecurity requirements flow to you, what evidence you return, and — critically — how vulnerabilities found post-SOP are reported in both directions and within what timescale. In our assessments, roughly 60% of first-time supplier evidence packages fail not on the engineering but on this seam: undefined ownership of a shared assumption, or a TARA whose boundary does not meet the manufacturer’s at the connector.

4. From TARA to cybersecurity goals to requirements

The engineering chain that an assessor will trace starts at the TARA (Clause 15). We define the item and its boundary, enumerate assets and their cybersecurity properties (confidentiality, integrity, availability, authenticity), identify damage scenarios and rate their impact across the safety, financial, operational and privacy categories, then derive threat scenarios and attack paths. Attack feasibility is rated — we use the attack-potential-based approach — and combined with impact to yield a risk value per threat scenario. For each significant risk we decide a treatment: reduce, share, retain, or avoid.

Risks treated by reduction become cybersecurity goals — the top-level security objectives for the item, the cyber analogue of safety goals. Goals are then refined into cybersecurity requirements and allocated down the architecture: system level, then hardware and software. A goal such as “the ECU shall reject unauthenticated firmware” allocates to secure-boot requirements in HW/SW; “safety-relevant bus messages shall be protected against spoofing and replay” allocates to SecOC requirements. The discipline that matters — and that gets audited — is bidirectional traceability: every requirement traces up to a goal and a TARA risk, and down to a design element, a test, and a verification result. A requirement with no parent risk is scope creep; a risk with no child requirement is an open finding.

5. Architectural mitigations that actually appear in the evidence

Across ECU programmes the same set of mechanisms recurs in the evidence file, because they map cleanly to the most common threat scenarios. None of them is optional folklore — each closes a specific attack path the TARA will have surfaced.

• Secure boot — a hardware root of trust verifies a signature or MAC over each boot stage before execution, closing the “attacker replaces firmware” path. We check the chain is genuinely rooted in immutable hardware, not a software check that the same compromise can bypass.
• SecOC (AUTOSAR Secure Onboard Communication) — authenticity and freshness on safety- and security-relevant bus messages via a truncated MAC plus a freshness value, defeating spoofing and replay on CAN/CAN-FD. The freshness-value management and key distribution are where it usually goes wrong.
• Secure diagnostics — UDS SecurityAccess (service 0x27) gating privileged services, and increasingly Authentication (service 0x29) with certificate-based, asymmetric challenge-response replacing weak fixed seed-key schemes. The protected services — routine control, write-by-identifier, programming-session entry — must actually be behind the gate, not merely advertised as protected.
• HSM / SHE key management — keys live in a hardware security module or SHE, never in flash readable by application software; key provisioning, storage, rotation and the cryptographic operations are anchored in hardware. A “secure” design whose root key is recoverable from a flash dump is a finding, not a control.
• Secure / authenticated flashing — the reprogramming path verifies the authenticity and integrity of every update before it is accepted, so the diagnostic and update channels cannot be turned into an installation vector.
• Anti-rollback — monotonic version counters prevent downgrading to an older, vulnerable but still validly signed image. This is the control most often missing entirely, and it quietly undoes secure boot the day a known-vulnerable old version can be re-flashed.

What we report on is not the presence of these names on a slide but whether each is correctly bound to its threat scenario, correctly keyed, and verified by test — see software engineering for how these are implemented against the requirement set.

6. Verification and penetration testing

Requirements without verification are claims. Each cybersecurity requirement needs a verification method — review, analysis, or test — and the result becomes part of the evidence. Above the unit and integration tests sits cybersecurity validation and penetration testing, where we stop assuming the design behaves and try to break it.

At the methodology level — and we keep this strictly defensive — pen-testing an ECU means attempting the attacks the TARA predicted: UDS SecurityAccess (0x27) seed-key brute-forcing and replay against the diagnostic stack; fuzzing of CAN/UDS/network interfaces to surface unhandled states; probing secure boot and the flash path for downgrade and unsigned-image acceptance; checking SecOC freshness handling for replay windows; and, where the hardware threat model justifies it, fault-injection and side-channel evaluation against the key store and boot chain. We describe what is attempted and why, not weaponised step-by-step recipes. The deliverable that matters to an assessor is reproducible evidence: tooling, configuration, and a finding that someone else can re-run and confirm. Our full approach is in our ECU penetration-testing methodology and the ECU penetration testing service.

7. R156 / SUMS and RXSWIN

If the ECU receives software updates — over the air or via service tooling — a second regulation applies. UNECE R156 requires a certified Software Update Management System (SUMS), the update-lifecycle counterpart to R155’s CSMS. It governs how updates are developed, validated, secured, and delivered, including update integrity and rollback handling, and how the vehicle behaves if an update fails.

The mechanism that ties this back to homologation is the RXSWIN — the Regulation X Software Identification Number. Each RXSWIN identifies the type-approval-relevant software for a given regulation, and it is bound to the type approval. The rule we hold teams to is simple: every update that changes type-approval-relevant software must be reflected in its RXSWIN, so the software actually running in the field still corresponds to the approved type. An over-the-air campaign that silently changes regulated behaviour without updating — or without re-checking — the RXSWIN puts the vehicle out of conformity with its own approval. On the supplier side, this means your release and configuration management must keep a clean, queryable link from a delivered binary to the RXSWIN it belongs to, and your secure-flashing and anti-rollback mechanisms (Section 5) are precisely what make the SUMS integrity and rollback claims true rather than aspirational.

8. The evidence file

When the technical service and the approval authority review, they do not read your code — they read the file, and they read it for coherence. What they expect to find, and what we assemble, is a connected chain: the CSMS certificate and process evidence; the item definition and scope; the TARA with its assets, damage and threat scenarios, feasibility and risk ratings, and treatment decisions; the cybersecurity goals and the requirements allocated from them; the architecture and the mapping of each mitigation to the requirement it satisfies; the verification and validation results including the penetration-test report; and the post-development plan for monitoring, vulnerability management and incident response.

The recurring failure is not a missing document — it is a broken link. A mitigation present in the architecture that no requirement asks for; a high-risk threat scenario whose treatment cannot be traced to a goal; a test report that does not reference the requirement it verifies. Preparing for the review, in our practice, is mostly a traceability audit: we walk the file the way an assessor will, from each TARA risk forward to its verified treatment and backward from each control to its justification, and we close the seams before the technical service finds them. A file that survives this internal walk usually survives the external one.

9. Keeping the CSMS credible between audits

The certificate is a snapshot; the obligation is continuous. R155 expects monitoring and management of cyber risk across the lifecycle, and 21434’s continual cybersecurity activities (Clause 8) make this concrete — and this is the part that quietly decays once the programme ships and the team moves on. A CSMS that was credible at audit can be hollow eighteen months later if nobody is doing the work.

The work is specific. You maintain a mapping from your deployed components — the libraries, the bootloader, the crypto stack, the comms stack, the silicon — to the vulnerabilities disclosed against them, by ingesting CVE and threat-intelligence feeds and filtering them to your bill of materials. When a relevant vulnerability lands, it must trigger a defined path: re-assess the affected TARA, decide whether the risk has changed, and feed a decision — patch, mitigate, accept, or update — back into the same goal-and-requirement structure, with the update flowing through the SUMS and reflected in the RXSWIN if it touches regulated software. That trigger — new vulnerability to re-assessed TARA to a tracked decision — is the heartbeat of a living CSMS, and its absence is what an audit two years on actually exposes. We build and operate that monitoring loop as part of our cybersecurity practice, and align it with the safety and process work in functional safety and training & consulting so the security case stays as alive as the product it protects.

---

Want a 30-min walkthrough on your project?

No NDA needed. Tell us the standard, the item or asset, the assessor, and your deadline. Within 48 hours you’ll get a one-page diagnostic mapped to the points above — yours to keep, whether or not you hire us.

Book a cyber walkthrough →

---

Author: Adrian Valea, Founder & Managing Director, SafetyTrust Software Technology GmbH. ASPICE Provisional Assessor (intacs / VDA), Functional Safety Engineer (TÜV Rheinland), Automotive Cybersecurity (TÜV NORD). Published 2026-06-03.