How to establish a CSMS in accordance with UN R155? A short, practical guide

Amid the upcoming July 2024 deadline, OEMs and their suppliers worldwide are facing a variety of challenges arising from the prerequisites and requirements of UN Regulation No. 155. The aim is to be able to continue selling vehicles to the relevant target markets affected by the regulation in the future. The most important task here is the introduction of a CSMS, which is the main topic discussed in this article.

Currently, more and more regulations and standards that have a direct impact on the automotive industry are emerging at the international and national level. UN R155 is the most important regulation to ensure cybersecurity in automotive development. You can read more about the UN Regulation No 155 and its areas of application in our article about UN Regulation No 155.

To achieve the objective of effectively ensuring cybersecurity, current legislation in this area directly intervenes in the approval process of a vehicle.

The OEM is responsible for the type approval process. As a manufacturer, in order to sell vehicles in a target market it must have them approved in cooperation with a technical service, which performs the type approval testing), and the approval authority, which issues the type approval. By default, this type approval procedure is carried out with the help of a sample vehicle and the associated technical documentation.

In this context, an additional requirement in order to obtain the approvals has already been put in place since July 2022 for completely new vehicle types and starting in July 2024 for all newly licensed vehicles (with the exception of small series): Providing a Certificate of Compliance (CoC) as proof of a successfully implemented and officially audited cybersecurity management system.

Accordingly, questions and information needs are increasing around the subject of what exactly needs to be done for a Cybersecurity Management System (CSMS for short).

What is a CSMS along the UN R155?

Along the UN R155, a CSMS is nothing more and nothing less than a complete process landscape in organizations to holistically incorporate cybersecurity into development efforts.

This is referred to as professional cybersecurity management, which includes:

• Risk identification (i.e., assessment, categorization and management of risks)
• continuous monitoring
• the entire cooperation in the value chain with the suppliers involved
• and this applies to the entire product lifecycle of a vehicle, i.e. from development to post-production.

In addition to the actual CoC as proof of the CSMS, further requirements are necessary in the type approval procedure, such as very concrete proof of the practical application of the CSMS during development – here, corresponding technical documents, proofs and evidence of the concrete application are of particular importance.

While organizationally these requirements are primarily the responsibility of the OEM, the OEM is also responsible for its downstream supply chain.

In practice, this means that the application of UN Regulation No. 155 and the CSMS at the supplier level increasingly raises questions as to what exactly they have to do. This is particularly the case when manufacturers already specifically pass on their corresponding requirements to their suppliers.

Please also find more information about this in our informative webcast: How do UN Regulation No 155 / CSMS affect the supply chain? [Info Webcast] (Video)

What are the implications of the CSMS for suppliers?

Although on a regulatory level only the OEM is obliged to comply, there is currently a clear market trend where CSMS requirements are passed on almost 1:1 from the OEM to the suppliers: Suppliers regularly see it as their duty, e.g. to be able to realize business at all, to implement management systems and related cybersecurity requirements more or less on the same level as the OEM.

Let’s take a quick look to better understand what this means.

Differentiation: The overall part for the organization + the specific part for the project

“Hey, we want to turn our entire organization upside down and completely reorganize it structurally, simply to be able to ensure cybersecurity even better.” Such statements are likely to be rare in practice.

Understandable, after all, every company is first and foremost concerned with creating its added value. Driving forward one’s own developments and ensuring its sales.

Especially in the cybersecurity practice, there is confusion about who is responsible. In addition, there are insufficient resources and, all too often, there is a lack of funds and leadership support to tackle such an undertaking on a company-wide basis “out of the blue”.

Accordingly, cybersecurity related challenges and tasks almost always arise from a specific development project. Nevertheless, it is clear that the organization, structures, procedures and processes must be addressed with a CSMS even if the initiation comes from the project.

Side note 1: ISO/SAE 21434 and its corresponding certification?

By now it is well known: The application of the ISO/SAE 21434:2021 standard is considered as the state of the art to demonstrate compliance with UN Regulation No. 155.

However, it is also important to know (as of Q2/2023) that according to the ISO/SAE 21434:2021 standard there is still no official formal, defined procedure for certification, auditing or assessment in order to obtain evidence issued by the very official regulatory body at the organizational or project level.

Although ISO/PAS 5112 is now officially published, the Automotive SPICE for Cybersecurity Handbook can be obtained from the Quality Management Center of the German Association of the Automotive Industry, and ISO/SAE 21434 certifications are already offered institutionally. Nevertheless, these must be distinguished from formal official evidence in the sense of a regulatory framework.

Such certifications can of course have a reasonable character, especially if OEMs themselves become active here and elicit the requirements for their cooperations in the way that becomes necessary for the joint work.

Therefore, using resources for in-depth assessments and specific Gap Analysis (see also ISO/SAE 21434 Gap Analysis) in order to pave the way for audits and certifications with the right preparatory work is worthwhile.

Side note 2: Well, we do IT security, don’t we? Intersections between Automotive Cybersecurity Management Systems (CSMS) and Information Security Management System (ISMS)

The main distinction here is, first of all, the objective. While the CSMS aims to ensure cybersecurity as a factor for the safety and protection of vehicles, drivers, and the environment at the end of the day, the ISMS is primarily concerned with protecting information and data security.

Stakeholders, departments, and teams involved are of course partly the same, and there are certainly also some (and in the future probably more) overlaps in questions of areas of expertise, responsibilities, and methodological approaches – nevertheless, the methods here are to be seen as independent of each other, insofar as they intervene in organizational structures and processes from different perspectives.

Put simply, ISO 27001 and the ISMS refer to information security within the organization (also relevant to TISAX here), while the CSMS forms the system for dealing with cybersecurity risks and threats in a structured, holistic manner in relation to the lifecycle of the product, i.e. the vehicle.

Enough of the background story, here is a first attempt to get things more tangible.

CSMS in a quick start guide: 5 tips to get started

The demands imposed on an organization-wide management system are far greater that they can be covered entirely in a quick run-through.

Nevertheless, the following five aspects are intended to outline key fields of action in order to give those responsible an impression as to what is important, among other things.

1. Consider the product itself

Rarely is something developed from scratch. There is a product design, decisions have been made, there is hardware/software, implementations have already been realized. But are the requirements that are inevitably imposed by cybersecurity properly considered from the very beginning? A simple example is cryptographic operations that comply with the timing requirements for proper operation of the vehicle – can this already be guaranteed? In such cases, the entire scope of an already realized development might have to be reconsidered from a cybersecurity point of view.

Accordingly, the principle of Security by Design is of great importance, which you can read more about in our blog article: Security by Design in Automotive Development

2. Beyond development and product: Cybersecurity in manufacturing

Manufacturing facilities, production sites, manufacturing responsibilities – one of the essential phases in the entire lifecycle from a cybersecurity perspective is production. In particular, manufacturing processes and organizational structures are subject to specific frameworks that must be designed extensively to ensure cybersecurity in vehicle production. This implies not only that the assembly line is access restricted but also enforces the manufacturing infrastructure to be able to securely exchange, handle and flash security objects while not compromising the efficiency of the manufacturing process.

Related to this here is our video course about IEC 62443 standard and TISAX

3. The interactions between customer (e.g. OEM or Tier-1) and supplier (Tier-1 or Tier-2)

What are the interfaces between OEM and supplier, how is the cooperation in distributed development? Agreements on this are already standardized in ISO 26262 and structured specifications for service interfaces regarding cybersecurity issues must also be adhered to. ISO/SAE 21434 defines this with the Cybersecurity Interface Agreement. But even beyond that, there are very specific requirements for the coordination and interaction of back-end infrastructures between OEMs and suppliers, for example to ensure the secure and proper transfer of security objects between the two entities.

4. The timelines: Before, during, and afterwards

The timeline is one of the most critical factors around CSMS, both in terms of the extensive lead times for holistic implementation of organization-wide CSMS structures and processes, and in terms of the complex interplay between requirements for auditing or the long lead times for related materials and documents. This must be made clear to those responsible at an early stage before it becomes problematic later regarding the actual SOP.

5. Use piloting

It often becomes apparent at an early stage that there is a significant deviation from the current handling in the ACTUAL state compared to the theoretical requirements. In this case, it is important to create awareness among those involved in the process, but also to take direct countermeasures through process adjustments. Properly piloted, with regular reviews and effective lessons learned, existing processes can be brought to a higher level of cybersecurity maturity even at this early stage. Even if the big picture seems very extensive, the importance of piloting combined with continuous adaptation is an effective lever for achieving holistic compliance.

In addition to the concrete evaluation of a consulting mandate or the use of the educational content of the CYRES Academy, our awareness offer created specifically for decision makers can make an important contribution. Learn more about the Fundamental Principles of Automotive Cybersecurity for Executives and Managers.

Sign up for our CYRES Consulting Automotive Cybersecurity Newsletter

Stay informed! Receive regular insights into current topics related to cybersecurity in the automotive industry directly to your inbox.

Sign up here for the newsletter, free of charge and with no obligations.

I accept saving my data by CYRES Consulting to contact me. More information in our Privacy Policy.

Leave this field empty if you're human: