UN R155 Meets Motorcycles (Category L): What Two-Wheeler OEMs Must Deliver Now

Manufacturers of two- and three-wheeled vehicles and quadricycles are paying close attention: cybersecurity compliance under UN R155 is becoming legally binding. While national implementation legislation varies, one thing is already settled — an entirely new market segment, structurally unlike the classical passenger car OEM environment, is now entering the regulated cybersecurity scope.

Two-wheeler OEMs — manufacturers of motorcycles, mopeds, trikes, and quadricycles — now face the same regulatory requirements under UN R155 that passenger car OEMs have been subject to since 2022:

• a demonstrably functioning Cyber Security Management System (CSMS),
• a risk assessment covering the entire vehicle lifecycle,
• supplier verification with operational substance.

UN R155 vs. Motorcycle: What Does This Mean?

The starting point in this market segment is different. Structurally simpler than in the passenger car space.

Where a modern passenger car carries several dozen networked ECUs, a motorcycle typically makes do with five to six: engine control unit, ABS/IMU, instrument cluster, and optionally a connectivity module and keyless entry system.

The attack surface scope is, at first glance, considerably more manageable.

What nevertheless places the entire segment under significant pressure is a combination of fragmented supply chains, smaller engineering teams, heterogeneous ECU architectures without an AUTOSAR baseline, and production sites — particularly across Asia — operating under different compliance frameworks.

The regulatory logic, however, remains the same: the OEM bears responsibility toward the type approval authority, regardless of who developed the component.

Decision-makers and security leads would do well to understand early on what UN R155 actually demands, where the typical gaps in the two-wheeler supply chain lie, and which security controls OEMs must operationally enforce — before the type approval dossier lands on the technical service’s desk.

The UN R155 Regulatory Timeline for Motorcycles & Co.: Hard Deadlines, Little Lead Time

UN R155 in its current version applies to all vehicle categories L, M, N, and O — for motorcycles and two-wheelers, this means: if the vehicle is equipped with at least one ECU, the regulation applies.

In practice, this captures virtually every modern motorcycle with ECU-based engine management, ABS, IMU functionality, or digital connectivity modules.

The Already-Fixed Compliance Deadlines Under UN R155 for Motorcycles

As a concrete example, consider the EU-specific implementation for Category L, which is effected through Delegated Regulation (EU) 2025/1455 and integrates technical requirements and test procedures against cyberattacks into the L-category type approval framework.

• As of December 11, 2027 — Phase “New Vehicle Types”: CSMS evidence plus vehicle-type-specific cybersecurity documentation is required; type approvals without a CSMS Certificate of Compliance (CoC) are no longer possible.
• As of June 11, 2029 — Phase “Existing Vehicle Types”: Full UN R155 conformity must be ensured for all types in the field; the particular challenge here is the long service life of motorcycles.
• Ongoing from approval — Phase “Post-Production Operation”: At minimum annual reporting to the approval authority and technical service is required; monitoring, incident response, and change notification are mandatory.

What Does This Mean in Practice?

The practical consequence: development programs targeting a start of production (SOP) in 2027/2028 must begin CSMS build-up and supplier onboarding no later than 2026. Experience shows that audit preparation and supplier assessment programs typically require 18 to 24 months of lead time.

What is arguably even more critical, however, is when cybersecurity first enters the development process.

Anyone who locks down E/E architecture and ECU selection without incorporating cybersecurity requirements at that stage risks finding that necessary mitigations simply cannot be implemented later — because the hardware won’t support them.

The governing principle is clear: UN R155 demands security-by-design, not retroactive hardening.

Anyone who, as 2026 progresses, has not yet started both — security-conscious architecture decisions and CSMS build-up — will face the type approval audit without a closeable findings list.

Or more precisely: the risk of a market prohibition becomes very real.

What UN R155 Actually Requires — and What Falls on the Two-Wheeler OEM

Common knowledge for some, uncharted territory for an entire industry — so here’s the introduction: UN R155 distinguishes two evidence layers, both of which must be demonstrated.

• At the organizational level, the approval authority verifies that a CSMS exists covering all phases — development, production, post-production — and is auditable. The CSMS audit is a prerequisite for everything that follows: no valid CSMS certificate, no type approval.
• At the vehicle type level, the type approval application requires a complete documentation package: description of the electrical/electronic architecture and external interfaces, a risk assessment that addresses the threat scenarios from Annex 5, mitigation mapping, effectiveness test evidence, and supply chain evidence.

The documentation logic has a frequently underestimated dimension: the complete dossier must remain available for at least ten years after end of production. For motorcycles in the volume segment — where a model may be produced over several years — this creates retention obligations that can easily extend to 15 years or more.

This is not an archiving question. It is a governance problem. Without robust document control and retention processes, CSMS compliance becomes structurally fragile — regardless of how sound the technical mitigations are.

The Scope of Connected Systems on Modern Motorcycles

Modern motorcycles and two-wheelers — particularly electric motorcycles and premium-segment models — increasingly feature Bluetooth Low Energy smartphone pairing, OTA update capability for ECU software, ride telemetry and cloud connectivity, keyless entry and digital key systems, as well as V2X prototypes and ADAS functionality.

Each of these interfaces is a potential attack vector and therefore subject to CSMS evidence requirements.

There is an additional physical attack vector that cannot be underestimated in this segment: the compact form factor of a motorcycle makes ECUs significantly more physically accessible than in a passenger car. Where sheet metal, engine bay, and body panels create natural barriers on a car, control units on a motorcycle are often close to the surface — requiring considerably less effort for direct hardware access, debug interface attacks, or manipulation when the vehicle is parked. This is not a theoretical risk: keyless entry systems and OBD interfaces are simply more exposed on a motorcycle than on a passenger car.

Relevant for type delineation: the EU-specific definition of a ‘type of vehicle with regard to its cybersecurity’ differentiates vehicles based on the manufacturer’s type designation and the essential aspects of the E/E architecture and external interfaces.

This boundary controls how platforms and variants may be grouped into cyber types — and thereby determines engineering effort, re-testing triggers, and change management scope.

A Closer Look: Four Structural Gaps in the Two-Wheeler Supply Chain

The OEM’s verification obligation extends far beyond signing security agreements. We are not talking about patient paperwork to satisfy UN R155 — we are talking about substantive adaptation of processes, organizational structures, and engineering practices. Type approval authorities will scrutinize in CSMS audits whether the OEM has demonstrably ensured that its partners are actually implementing the required controls.

In practice, four recurring gaps emerge:

• Paper vs. Reality: A supplier claims to incorporate cybersecurity — but it is not yet part of the development processes. No security concept exists, no documented security manual, no verifiable methodology. Findings of this nature constitute a genuine type approval risk in CSMS certification.
• Missing Traceability: Security controls such as key provisioning, firmware flash processes, and debug interface deactivation may exist, but are not derived from a risk assessment and are not linked to test results. Verification therefore lacks a substantiated basis — and evidence submission to approval authorities is correspondingly incomplete.
• Lack of Automotive Experience: Two-wheeler suppliers are structurally different from passenger car suppliers. Automotive processes are far less established in this segment — ISO 26262 only incorporated motorcycles in its second edition in 2018, and ISO/SAE 21434 does not reference them at all. Automotive SPICE plays a subordinate role at manufacturers focused exclusively on motorcycles. The result: suppliers that may have solid development processes in place but lack experience with automotive-specific cybersecurity requirements and evidence formats.
• Incomplete Vulnerability Visibility Due to Heterogeneous Development Environments: Differing development tools and environments across sites result in non-standardized SBOM generation and blind spots in vulnerability coverage — with direct consequences for OTA patch validation.

The underlying problem is structural: many Tier-1 and Tier-2 suppliers in the two-wheeler segment have not been audited against ISO/SAE 21434 and have historically not established automotive cybersecurity processes.

At the same time, production volumes in the motorcycle market — with the exception of a handful of global volume manufacturers — are significantly lower than in the passenger car space, which limits OEM leverage with suppliers accordingly.

Production sites across Southeast Asia and the Indian subcontinent — Vietnam, Malaysia, Indonesia, the Philippines, India — operate under materially different compliance frameworks. Technical services do maintain a presence in these regions, which makes on-site assessments feasible in principle; the coordination effort required for consistent, cross-site verification remains substantial nonetheless.

Where OEMs Should Engage Early: Enforcing Security Controls in the Production Context

Realistically, UN R155 compliance work tends to begin somewhere within the cybersecurity function, still closely tied to headquarters and central corporate functions. But what about production — which may also be outsourced?

Based on ISO/SAE 21434 and the ENISA framework, five control layers emerge for the production context that OEMs must demand from suppliers in technically specified, measurable, and verifiable terms. These should be mapped out and worked through early.

• Secure Production Environment: Access controls for production-relevant systems (HSM access, key provisioning infrastructure), network segmentation between production IT and office IT, logging and monitoring of access to security-critical production systems.
• Secure Key Provisioning & Device Identity: Evidence of an HSM-based key injection process (not a manufacturing step in the strict sense, but a critical production-adjacent security process), unique device identities per vehicle ECU, documentation of the key lifecycle (generation, programming, archiving, deletion process).
• Software Integrity in the Production Process: Code-signing requirements for all firmware images prior to the flash process, SBOM as a mandatory deliverable per vehicle variant and software version, verification of firmware integrity during production via hash comparison and signature validation.
• Debug Interface Management: Evidence of deactivation or cryptographic locking of JTAG, UART, and USB debug interfaces prior to shipment; documented process for authorized exceptions in field service and recall scenarios.
• Supply Chain Transparency & Vulnerability Management: SBOM availability at Tier-2/Tier-3 level at minimum on request; vulnerability disclosure process with a maximum 72-hour notification window for critical incidents; contractually secured incident response process.

Understanding the Three Layers of UN R155 Verification Obligations

The regulatory logic is unambiguous on one point: the OEM is responsible — not its supplier.

This creates a complex verification obligation spanning three layers. The documentary layer alone is not sufficient as UN R155 evidence. (No paper tiger — as noted above.)

These layers and their associated measures are to be expected in any CSMS audit:

• Documentary: Includes security questionnaires, self-declarations, and certificate evidence. This is generally the minimum baseline and is not sufficient as standalone UN R155 evidence.
• Technical-Analytical: This is where depth is required: vulnerability scanning, firmware analysis, penetration test results, and similar artifacts. The OEM is obligated to demand, retain, and regularly update these artifacts. This also puts tooling in focus — for example, with respect to keeping the cyber risk assessment/TARA current.
• On-Site / Remote Audit: Supplier security assessments against a defined framework (ISO/SAE 21434 in combination with ISO PAS 5112, or a proprietary standard) will only increase in frequency. The OEM must secure audit rights contractually, with a risk-adequate frequency — at minimum annually for critical suppliers.

A risk classification of the supply chain into High/Medium/Low tiers is recommended, based on: access to safety-critical systems, the connectivity level of the supplied component, and market share within the OEM’s own portfolio.

High-risk suppliers should either be audited annually or have an assessment conducted per product. Medium-risk suppliers: every two years. Low-risk suppliers: via self-assessment with sample-based verification.

Structural Characteristics of UN R155 Compliance in the Two-Wheeler and Motorcycle Segment

The general principle holds: the requirements from UN R155 are transferable from the passenger car domain. However, they must be adapted to the structural conditions of this segment.

The differences become clear in a direct comparison.

Consider a typical passenger car OEM, insofar as generalizations apply:

• Cybersecurity team: dedicated departments with 50 to several hundred specialists
• Tier-1 landscape: Bosch, Continental, ZF — typically all with their own CSMS
• Electronics complexity: several dozen highly networked ECUs per vehicle
• ECU architecture: established, standardized platforms (AUTOSAR)
• Software update/OTA infrastructure: largely in place
• Cost pressure: high, but margin (still?) present

On the two-wheeler OEM side, the starting position looks different:

• Cybersecurity team: often just 2 to 10 people; frequently embedded within the electrical/electronics function
• Tier-1 landscape: typically regional or smaller suppliers, often without an audit against ISO/SAE 21434 or equivalent
• Electronics complexity: typically 5–6 ECUs with significantly lower system interconnectivity
• ECU architecture: heterogeneous; partly proprietary stacks without AUTOSAR (which is not necessarily a disadvantage)
• OTA infrastructure: in development; primarily relevant for electric motorcycles
• Cost pressure: typically very high in the volume segment; significantly constrained investment capacity for security

This simplified comparison already makes the point: two-wheeler OEMs cannot adopt passenger car playbooks one-to-one.

In practice, a ‘dual-lane’ organization is the pragmatic target model:

• a stable, auditable CSMS as the management system on one side,
• and per vehicle type, an engineering lead with clear risk criteria and structured evidence packages on the other.

Automotive SPICE for Cybersecurity (VDA QMC) provides a highly concrete work product view for the supplier dimension — particularly regarding interface agreements with RASIC clarification and exchange of work products in the context of vulnerabilities.

The Product Lifecycle for Motorcycles: What Comes After Type Approval

UN R155 does not end at type approval.

The regulation requires at minimum annual reports to the approval authority and technical service covering monitoring outcomes, new attack vectors, and the continued effectiveness of mitigations.

In the event of insufficient reporting or response, the authority may revoke the CSMS compliance certificate — which can ultimately lead to the withdrawal of type approvals.

Changes to the vehicle type that affect cyber performance or documentation must be notified to the authority.

Conformity of production (CoP) is typically reviewed by the authority on a three-year cycle.

With UN R155, cybersecurity is no longer merely a checkpoint at initial approval — it becomes an ongoing manufacturer obligation. What matters is the continuous demonstration of an effective CSMS, even if the type approval itself is not automatically re-issued every three years.

This places cybersecurity for motorcycles and two-wheelers procedurally closer to Safety Management / Continuous Compliance than to classical homologation management.

UN R155 Compliance for Two-Wheelers: What Matters Now for Two-Wheeler OEMs

To summarize: UN R155 for Category L is not a formality.

As a substantive regulatory requirement, it compels two-wheeler OEMs to address supply chain cybersecurity systematically. Mechanisms that hold up to operational scrutiny are non-negotiable.

The decisive success factors are:

• technically specified requirements for suppliers rather than generic security clauses,
• verification mechanisms with operational substance beyond questionnaires,
• SBOM requirements as baseline hygiene — enforceable even for smaller suppliers,
• early integration of production partners into CSMS processes,
• and a risk-based audit cadence.

The core question is not whether the OEM bears this responsibility. That is settled regulatory fact.

The question is: with what mechanisms does it ensure that its entire supply chain actually reaches the required security standard and maintains it demonstrably.

There is a considerable amount to understand, build, and operationally sustain.

Well into 2026, the view from the field is this: for two-wheeler OEMs still in the planning phase, the available time buffer is already tight.