Multi-stage type approval & UN R155: A look at cybersecurity between different players in the special vehicle sector

When a classic passenger car series vehicle rolls off the production line of an OEM, the responsibilities and processes surrounding proper cybersecurity are now relatively clearly defined. The situation is different for multi-stage commercial vehicles, where various players are involved. For example, a vehicle manufacturer supplies a base vehicle (often called a chassis), a body manufacturer adds “functionality” to it, and often many other suppliers are involved with both players.

The first question in such a scenario is: Who is actually the “traditional” vehicle manufacturer as addressed by UN R155?

In view of UN R155, this simple question raises the broader issue of who actually bears overall responsibility for the cybersecurity of the entire vehicle (throughout its product lifecycle) and how.

This leads to the follow-up question: What are the specific implications for development work and the type approval process?

Despite all the passion for the perfect consideration of cybersecurity in all development work, ultimately, the entire scope of UN R155 is primarily about (local) type approval. In other words, the authorization for a vehicle to be allowed on the road. This is an organizational issue that needs to be clarified.

The starting point: What UN R155 really requires

UN R155 has been mandatory for all new vehicle types since July 2024. The regulation has a clear objective: vehicles must be systematically protected against cyberattacks throughout their entire lifecycle. This begins in development, continues in production, and does not end with delivery, but extends into the operating phase and also includes software updates (UN R156).

Essentially, UN R155 requires vehicle manufacturers to establish and demonstrate a cybersecurity management system, or CSMS for short.

This CSMS is not a one-time certification, but a living management system that operates continuously. It must document how the company identifies threats, assesses risks, implements protective measures, and responds to security incidents. The technical basis for this is usually the application of ISO/SAE 21434, an internationally applied industry standard that describes in detail how cybersecurity is to be implemented in the automotive sector.

What does this mean in concrete terms?

A vehicle manufacturer must be able to demonstrate that it has systematically addressed all potential attack vectors: from the infotainment system to wireless interfaces such as Bluetooth and Wi-Fi, over-the-air updates, USB ports, and the diagnostic interface. Each of these interfaces could theoretically serve as a gateway for an attack. The CSMS is designed to ensure that these risks are not only considered once, but are kept in mind throughout the entire lifetime of the vehicle.

Multi-stage type approval: When multiple manufacturers work on a vehicle

In the case of passenger cars, the situation is usually easier to manage. Although countless suppliers are involved, the rule is that an OEM develops and produces the complete vehicle, has it approved, and brings it to market.

However, the reality is often different in the commercial vehicle sector. Here, it is common for vehicles to be produced in several stages.

In the first stage, the vehicle manufacturer – for example, Daimler Truck, Isuzu, MAN, Scania (among others) – supplies the base vehicle or chassis. This already has all the essential vehicle functions: engine, transmission, braking system, electronic control units, safety systems such as ABS and ESP, and the basic electronic architecture.

This base vehicle already has type approval from the OEM, under which the chassis manufacturer is responsible for meeting all relevant cybersecurity requirements – including possible interfaces to other use cases, such as an additional body.

In the second stage, a body manufacturer, often referred to internationally as a bodybuilder, comes into play.

They add the specific functionality that the customer needs to the base vehicle: a tipper body for construction vehicles, a waste compactor for refuse collection vehicles, a crane body for commercial vehicles, or a complete firefighting equipment package. These bodies are often highly complex and now have their own control systems, hydraulics, pneumatics, and, increasingly, electronic components.

And it is precisely at this interface between the base vehicle and the superstructure that new challenges for cybersecurity arise. This is why the need for multistage type approval comes into play.

The crucial question is: Where does responsibility lie?

The central question that now arises with multi-stage type approvals is: When does the body manufacturer have to provide its own cybersecurity evidence, and when is the type approval of the base vehicle sufficient?

The answer depends on how deeply the body is integrated with the electronic architecture of the base vehicle. This is not just a question of physical connection, but also of how the body communicates with the vehicle’s control systems.

Case 1: The isolated body

Let’s first consider the simplest case: for example, a tipper truck used to transport bulk goods on construction sites. The tipper body is essentially a mechanical system with a hydraulic pump controlled by a simple switch. Power is supplied via the vehicle’s standard 24-volt connection. There is no connection to the CAN bus or other digital communication systems of the base vehicle. Technically speaking, the body has no influence on the vehicle’s driving behavior or the chassis itself.

In this scenario, cybersecurity responsibility remains entirely with the chassis manufacturer.

The body does not interact with the vehicle’s electronic systems and therefore does not pose any additional cyber risk. The original UN R155 type approval for the base vehicle is therefore not affected, and the body manufacturer does not have to provide its own CSMS evidence. Of course, the body manufacturer must still meet security requirements (such as the Machinery Directive for isolated embedded software), but from a regulatory vehicle cybersecurity perspective, nothing changes.

Case 2: The gray areas of networking

Things get a little more complicated when the body communicates with the vehicle, but only in a limited way. Let’s assume that a refrigerated vehicle has its own temperature monitoring system that sends information about the cooling performance to the vehicle display. This communication takes place via the vehicle’s CAN bus, but does not actively interfere with safety/security-critical systems.

Here we are in a gray area.

On the one hand, there is a digital connection to the vehicle electronics, but on the other hand, there is no intervention in control or safety systems. In such cases, a case-by-case assessment is necessary. The technical services responsible for type approval must work with the OEM and body manufacturer to assess whether this connection creates new cyber risks.

In such scenarios, a supplementary assessment is often required to confirm that the additional communication does not open up any security gaps.

Case 3: Deep integration

The most complex situation arises when the body actively interferes with the vehicle control system. A typical example is a modern garbage truck. Such vehicles have sophisticated compaction equipment with their own electronic control units, known as body ECUs. For safety reasons, these control units must communicate with several vehicle systems: During the compaction process, the vehicle must remain stationary – the body ECU therefore communicates with the brake system and ensures that the parking brake is activated. At the same time, the electronic stability program (ESP) must be informed of the process, as the weight shift during compaction could change the driving behavior. In some cases, the engine control unit must also be addressed in order to supply the hydraulic pump with sufficient energy. Another example of the refuse collection vehicle body interfering with the powertrain: if there are people standing on the rear running board, this information is transmitted to the chassis – in some cases via CAN access.

This deep integration means that the body ECU has direct access to security-critical vehicle systems. This makes it a potential point of attack itself. An attacker who gains access to a body ECU could theoretically also access the brake system or engine control unit.

In such a case, the type approval of the base vehicle is no longer sufficient. The body manufacturer must either demonstrate its own CSMS or be integrated into the OEM’s CSMS.

Excursus for the body builder in the case described: What exactly needs to be done? The body builder must first check whether the interface they use is already included in the chassis manufacturer’s type approval and whether it has been taken into account there as part of the cybersecurity assessment. In addition, a chassis manufacturer usually provides an integration manual. This describes how the interfaces are to be used, including from a cybersecurity perspective. Often, communication via these interfaces is only permitted in accordance with specified, standard-compliant specifications. If the bodybuilder deviates from these, the responsibility for the resulting cybersecurity risks lies entirely with them.

Important to know about two-stage type approval: What is the bodybuilder responsible for?

In the case of two-stage type approval, the body manufacturer is then responsible not only for the body it manufactures, but for the entire vehicle. Although it can refer to the type approval of the chassis manufacturer, this does not release it from its obligation to check this comprehensively – including the technical interfaces and cybersecurity assumptions described therein.

The body manufacturer must therefore ensure that its additions, systems, and integrations are fully compatible with the requirements approved in the first step and do not introduce any new risks for the vehicle as a whole.

This necessity is all too often overlooked.

The technical perspective: What does integration really mean?

To understand when cybersecurity evidence is required, it is worth taking a look at the technical level. Modern vehicles have a complex electronic architecture, often referred to as E/E architecture. This architecture consists of various bus systems and networks that connect different areas of the vehicle.

The CAN bus is the most widely used communication protocol in vehicles. It connects the various control units with each other and enables them to exchange information. A distinction is often made between different CAN domains: the powertrain CAN, the HMI-CAN, and the diagnostic CAN. More modern vehicles increasingly rely on Ethernet-based networks, which enable higher data rates.

When a body manufacturer connects its system to the vehicle, the question arises: Which domain is used to establish the connection? A connection to the comfort HMI, which is used to control window regulators or seat adjustment, for example, carries significantly lower risks than a connection to the powertrain CAN, which is used for communication between the engine and brakes.

But even this distinction falls short. Modern vehicle architectures are increasingly networked, and the separation between different domains is becoming increasingly permeable. A central gateway connects the various networks with each other, enabling holistic vehicle control. But this also means that an attack on a supposedly non-critical component could reach critical systems via the gateway.

It is precisely this complexity that makes assessment so challenging.

It is not enough to consider only the direct connection. A complete risk analysis, as prescribed by ISO/SAE 21434, must take all possible attack paths into account. This analysis is called TARA – Threat Analysis and Risk Assessment. It identifies potential threats, assesses their probability of occurrence and potential impact, and defines appropriate protective measures. With intelligent interlocking and intertwining of cyber risk analyses and assessments (across security teams and organizational boundaries), a solid basis for decision-making can be developed.

Practical implementation: Two paths to compliance

Having established that a body manufacturer, as defined above, bears the obligation to provide cybersecurity evidence, two fundamental pathways to compliance are thinkable.

Option 1: Integration into the OEM’s CSMS

The first option is integration into the vehicle manufacturer’s existing CSMS. Under this model, the OEM remains the party responsible for the cybersecurity of the entire vehicle. The bodybuilder is treated as part of the supply chain and must meet certain requirements defined by the OEM.

This approach has several advantages: The body manufacturer does not have to set up its own comprehensive CSMS, which saves a considerable amount of effort. The interfaces are clearly defined and responsibilities are regulated. The OEM takes over the overall coordination and ensures that all components together form a secure system.

However, this model requires close cooperation. The OEM must be prepared to integrate the body manufacturer into its processes. This means joint risk analyses, coordinated development processes, and often contractual agreements on responsibilities and liability. In addition, the body manufacturer must be able to meet the OEM’s requirements, which requires its own expertise in secure development.

In practice, this theoretical idea is often unrealistic for a variety of reasons. On the one hand, both bodybuilders and chassis manufacturers typically operate as distinct business entities with limited transparency regarding technical knowledge and internal processes. On the other hand, there is often no direct contractual relationship between body and chassis manufacturers, which means that such an in-depth disclosure of technical knowledge and processes is considered unfeasible.

Option 2: Establishing an independent CSMS

The second option is for the body manufacturer to set up its own CSMS. This option is particularly necessary if the OEM is unwilling or unable to integrate the body into its CSMS, or if the body manufacturer works with different OEMs and needs a manufacturer-independent solution.

A proprietary CSMS means that the body manufacturer must meet all UN R155 requirements itself.

This includes setting up processes for threat analysis, secure development, vulnerability testing, security incident management, and monitoring during the operational phase. It requires specialized personnel, appropriate tools, and often external support from cybersecurity experts.

The advantage lies in independence. The body manufacturer can design its solutions flexibly and is not dependent on the specifications of individual OEMs. At the same time, having its own CSMS enables the body manufacturer to build up expertise that can become a competitive advantage in the long term.

This is where the application of ISO/SAE 21434 comes into play, particularly with its clauses on cybersecurity at the organizational level (Clause 5) and on distributed cybersecurity activities in development (Clause 7). The Cybersecurity Interface Agreement (CIA) plays a central role here, defining which security requirements apply, who must pass on which information about potential threats, and how to proceed (jointly) in the event of security incidents.

The supply chain: Suppliers are also required to comply

The complexity outlined above does not end with the interaction between OEMs and body manufacturers. Suppliers who supply components for bodies must also take cybersecurity into account. For example, if a body manufacturer purchases a control unit from a supplier, the supplier must be able to prove that the component has been developed in accordance with ISO/SAE 21434.

This means that the supplier must document which threat analyses have been carried out, which security requirements the component meets, which tests have been performed, and which known vulnerabilities exist. This information is essential for risk analysis at the vehicle level.

This poses a challenge for many smaller suppliers. They must invest in expertise and processes in order to meet the requirements. At the same time, cybersecurity documentation is becoming a critical success factor: even a well-developed component cannot be used if the necessary cybersecurity evidence is missing. This is particularly difficult for suppliers and vehicle manufacturers who have previously relied on technically simple but proven control units. Many of these systems date back to a time when cybersecurity was hardly considered in the automotive environment and cannot be easily upgraded with modern security mechanisms such as HSMs. However, an immediate technology change is often hardly feasible, as it would require not only considerable investment but also profound changes in the system and software architecture.

The role of technical services: New testing methodology required

Technical services responsible for type approval also face new challenges in this context. In the case of multi-stage type approvals, they are the ones who have to assess whether the cybersecurity of the base vehicle is compromised by the body integration. This requires not only a deep understanding of both vehicle electronics and body manufacturing processes, but also of the business models common in the industry. (This also takes into account the fact that there is often no direct contractual relationship between the chassis and body manufacturers.

Testing procedures are typically conducted in multiple phases. Initially, an assessment is performed to determine whether any electronic interface exists between the body and base vehicle architecture. If such connectivity is identified, a detailed evaluation must establish whether the interface constitutes a potential attack vector and whether the integration specifications provided by the OEM have been properly implemented. Technical services personnel verify that all applicable TARA documentation from both the OEM and body manufacturer has been appropriately considered and that protective measures align with identified risks.

In some cases, practical validation testing becomes necessary. These tests empirically verify that implemented security controls function as designed. For example, testing may be conducted to confirm that communication between the body ECU and the vehicle network is properly authenticated, ensuring that unauthorized message injection is effectively prevented.

What does this mean in practice?

The requirements of UN R155 in the context of multi-stage type approvals may seem overwhelming at first. However, with the right approach, they can be implemented systematically.

For chassis manufacturers, this means redefining their role. They must not only secure their own vehicles, but also clearly document the interfaces for body manufacturers. This includes a precise description of which systems may be addressed, which security requirements apply, and which information must be exchanged. (This is particularly important in the event of a security-related incident.) Many OEMs now create cybersecurity manuals for body manufacturers that compile this information.

For body manufacturers, the initial step involves conducting a comprehensive self-assessment. How deeply does our body system interfere with the vehicle’s electronics? What data is exchanged? What control units do we use? What does the chassis manufacturer’s existing type approval cover? Based on this analysis, a determination can be made regarding whether an independent CSMS is required or whether integration into the OEM’s existing CSMS framework is feasible.

Regardless of the path chosen, body manufacturers must invest in expertise. This can be done by hiring specialist staff, providing training, or working with specialist consulting firms. It is important that cybersecurity is not seen as an add-on, but rather as an integral component of product quality and regulatory compliance.

For suppliers, clear documentation will be a decisive factor. Components must be developed in accordance with all applicable cybersecurity requirements, and corresponding evidence must be readily available. This applies not only to software, but also to hardware. Even secure software can be compromised if the underlying hardware offers opportunities for attack.

Looking ahead: Understanding cybersecurity as an opportunity

UN R155 and its associated requirements are often perceived as a burden, primarily from a resource perspective. However, especially in crisis situations, it is important to understand investments in cybersecurity holistically, also from a cost perspective.

For bodybuilders who invest in cybersecurity at an early stage, new business areas can open up. Those who can demonstrate that their systems meet the highest security requirements can differentiate themselves as premium providers. Conversely, organizations that ignore these requirements for too long will increasingly be excluded from the market because their products may fail to achieve type approval.

At the same time, building up the necessary cybersecurity expertise offers many organizations the opportunity to fundamentally develop their internal processes: away from a traditionally mechanics-centered approach to modern, software-oriented development processes. This also creates opportunities to establish and expand an integrated quality management system that encompasses hardware, software, and system development — which in turn forms the basis for a sustainable CSMS in the long term.

Collaboration between OEMs, body manufacturers, and suppliers will have to become more intensive. While this may initially appear burdensome, over the long term it will lead to better products and clearer responsibilities. The era when vehicles were considered purely mechanical assemblies and electronic systems were treated as an afterthought are finally over.

Cybersecurity is not a finite deliverable, but a continuous process. New threats are emerging, attack methods are evolving, and regulatory requirements will also continue to develop.

Those who lay the groundwork today — in the form of processes, expertise, and partnerships —will be well equipped for the future. This is particularly true because it can be assumed that interpretations of regulations, best practices, and procedures will inevitably become standardized within the industry — and these will presumably place more rather than less emphasis on cybersecurity. Accordingly, UN Regulation No. 156 governing Software Update Management System should also be approached in the same way for body manufacturers.