Automotive Cybersecurity
Standards and Regulations

Knowledge Hub

As the automotive industry shifts toward connected cars and smart mobility, an added element of vulnerability arises, namely, the threat of cyber-attacks. As such, regulators and governments have worked to ensure that cybersecurity becomes an integral focus along every level of the automotive supply chain. 

This Upstream knowledge-hub serves as a home for information and educational resources regarding automotive cybersecurity standards and regulations, includes answers to frequently asked questions on the WP.29 CSMS regulation and ISO/SAE 21434 standard, and offers tools to help OEMs and others in the automotive industry shift toward effective compliance.



UNECE WP.29 R155 CSMS Gap Analysis

Cybersecurity Risk and Mitigation Assessment Tool

With this tool, you can better understand your organization’s weak spots based on the risk assessment and correlating mitigation demands in the UNECE WP.29 regulation R155 for CSMS (Cyber Security Management System). Upstream’s gap analysis assessment will enable you to see where you stand in regard to regulatory compliance and offer a quick overview of areas that may need more attention.


UNECE WP.29 CSMS R155 Threat Mapping

Threats, Vulnerabilities, and Mitigations Mapping Tool

The UNECE WP.29 regulation R155 for CSMS (Cyber Security Management System) includes a list of 69 different cyber threats and vulnerabilities (divided into 7 sub-categories such as vehicle, back-end server, and communication threats) as well as more 23 cybersecurity mitigations required to protect against these threats. This mapping tool helps make that list easier to navigate, understand, and thus implement.


ISO/SAE 21434

ISO/SAE 21434 Risk Assessment

Threat Analysis and Risk Assessment Tool

With this tool, automotive stakeholders can perform threat analysis and risk assessment (TARA) as demanded by the WP.29 and as described in ISO/SAE 21434 standard, in Sections 8.3-8.9. The tool allows one to analyze the threats to one’s assets, calculate the total cybersecurity risk based on the formulas and matrices provided by the standard, and generate a PDF report to document the process and analysis.


Start the Process


Questions about the UNECE WP.29 Regulations
Why are automotive cybersecurity regulations needed?

As the connected vehicle ecosystem expands, global automotive OEMs, Tier 1 and 2 suppliers, and other smart mobility players continue to develop various connected vehicles, components, chips, and solutions. Consequently, as vehicle connectivity grows and a demand for embedded solutions rises, the risk of cyberattacks against connected vehicles increases. According to a March 2020 GSA and McKinsey report1, currently, cars have up to 150 ECUs and about 100 million lines of code, and by 20302, many expect them to have roughly 300 million lines of software code. This amount of code creates extensive opportunity for cyberattacks, not only on the car itself but also on all components of its ecosystem. Each new connected service and capability introduces additional points of entry for hackers and opportunities for potential cyber, fraud, and data-breach incidents, threatening both companies, drivers, and road users.

To curtail the expected rise of cyberattacks against connected vehicles, which could cost the automotive industry up to $24 billion in losses by 2023, governmental bodies and independent regulators have made an effort to demand an increase in ingrained cybersecurity measures from OEMs, component suppliers, and software suppliers.

Additionally, regulations allow for faster and more effective vehicle development and are often developed due to common industry interests. In the case of automotive cybersecurity regulations, the demand for increased security is clear throughout the industry, governments, and road users alike. Independent efforts to secure connected vehicles takes a considerably large amount of time and money. However, when cybersecurity efforts are compounded in the form of regulations, they lead to more timely, effective, and more reliable vehicles. One such automotive cybersecurity endeavor is the WP.29 regulation developed through the UNECE, the United Nations Economic Commission for Europe.



What is the UN’s role in automotive cybersecurity regulations?

Automotive regulations are not a new topic at the United Nations; since the early 1950’s the UN has been involved in regulating the safety and security standards of vehicles, including regulations on seat belts, steering wheels, and even headlights. However, because of the newness of the topic, it took until 2018 for the UN to start developing regulatory requirements regarding automotive cybersecurity.

The United Nations Economic Commission for Europe is under the jurisdiction of the United Nations Economic and Social Council and was established to promote economic cooperation and integration among its 56 member states. Within the UNECE lies the Inland Transport Committee (ITC), the UN platform to help efficiently address global and regional needs in inland transport. One of the subsidiary bodies of the ITC is the WP.29, which was established on June 6, 1952, as the Working Party on the Construction of Vehicles and renamed in 2000 as the World Forum for Harmonization of Vehicle Regulations (WP.29).

According the UNECE overview, “the objective of the WP.29 is to initiate and pursue actions aimed at the worldwide harmonization or development of technical regulations for vehicles”3, and to develop regulations that are intended to improve vehicle safety, protect the environment, promote energy efficiency, and increase anti-theft performance. This Working Party was open to governmental experts from any United Nations member state, any regional economic integration organization set up by member countries of the United Nations, and to experts of governmental organizations of those member states. The regulations developed by the WP.29 are all based on three UN agreements adopted in 1958, 1997, and 1998. Within the scope of the WP.29’s activities is the effort to define safety and environmental performance requirements for cars, vans, trucks, coaches, buses, powered two wheelers, agricultural vehicles and non-road mobile machineries (which include cranes, railcars, locomotives, inland waterway vessels, and more).

In response to the growing prevalence of connected vehicles, at a session in February 2018, the ITC recognized the importance of WP.29 activities related to automated, autonomous and connected vehicles. As such, they requested that the WP.29 consider establishing a dedicated subsidiary working party specifically focused on connected vehicles. In June 2018, following this request, the WP.29 decided to convert the Working Party on Brakes and Running Gear (GRRF) into the new Working Party on Automated/Autonomous and Connected Vehicles (GRVA).


Which countries are part of the 54 contracting parties to the regulations?

Albania, Armenia, Australia, Austria, Azerbaijan, Belarus, Belgium, Bosnia and Herzegovina, Bulgaria, Croatia, Czechia, Denmark, Egypt, Estonia, European Union, Finland, France, Georgia, Germany, Greece, Hungary, Italy, Japan, Kazakhstan, Latvia, Lithuania, Luxembourg, Malaysia, Montenegro, Netherlands, New Zealand, Nigeria, North Macedonia, Norway, Pakistan, Poland, Portugal, Republic of Korea, Republic of Moldova, Romania, Russian Federation, San Marino, Serbia, Slovakia, Slovenia, South Africa, Spain, Sweden, Switzerland, Thailand, Tunisia, Turkey, Ukraine, United Kingdom of Great Britain and Northern Ireland.

What is the current status of the WP.29 CSMS and SUMS regulations?

As of June 25, 2020, two new UN regulations have been adopted. The first regulation focuses on uniform provisions concerning the approval of vehicles with regard to cybersecurity and cybersecurity management systems (CSMS). The second regulation is on vehicle software update processes and software update management systems (SUMS). This first CSMS regulation will be the focus of the subsequent FAQs.

As explained in a UNECE press release from June 25, 2020, “The two new UN Regulations, adopted yesterday by UNECE’s World Forum for Harmonization of Vehicle Regulations, require that measures be implemented across 4 distinct disciplines: Managing vehicle cyber risks; Securing vehicles by design to mitigate risks along the value chain; Detecting and responding to security incidents across vehicle fleet; Providing safe and secure software updates and ensuring vehicle safety is not compromised, introducing a legal basis for so-called “Over-the-Air” (O.T.A.) updates to on-board vehicle software.

The regulations are expected to be finalized and published in early 2021 and apply to the 54 member states, (which do not include US or Canada). Once the regulations are adopted by these member countries, OEMs in those countries will be required to implement specific cybersecurity and software-update practices and capabilities for Vehicle Type approvals. OEMs that do not comply with the regulations may face trade barriers and other complications; those that do acquire the necessary certification have the ability to brand their companies as secure and build mutual trust with customers. Ultimately, the regulations effectively make cybersecurity an inviolable element of future connected vehicles.

When will countries start implementing the regulations?

According to an UNECE press release from June 25, 2020:

Japan has indicated that it plans to apply these regulations upon entry into force. 

The Republic of Korea has adopted a stepwise approach, introducing the provisions of the regulation on Cybersecurity in a national guideline in the first half of 2020, and proceeding with the implementation of the regulation in a second step.

In the European Union, the new regulation on cybersecurity will be mandatory for all new vehicle types from July 2022 and will become mandatory for all new vehicles produced from July 2024.


What is within the scope of the WP.29 CSMS regulation?

The uniqueness of the WP.29 CSMS regulation is both in its practical approach to automotive cybersecurity, with concrete examples of threats, and specified mitigations, but also in its holistic approach to automotive cybersecurity, with a process and governance perspective, a product perspective, as well as an IT perspective.

The WP.29 regulation explains very specifically what needs to be done, however, it intentionally does not include an explicit definition of how the regulatory requirements can be met nor does it mandate detailed technical measures. Instead, through the use of relevant standards (such as the ISO/SAE 21434) and implementing appropriate mitigations, OEMs should be able to showcase how the principles of the regulation are being met. The emphasis on the word ‘processes’ in the regulation is a clear bid to provide guidance for cybersecurity structures without mandating low-level technical specifications. The regulation was intentionally drafted in a technology neutral way, giving some flexibility to OEMs to decide how to ensure the cybersecurity of their vehicles. Because of the dynamic nature of the automotive cyber environment, rigid technical measures could be counterproductive.

The regulation does:

  • Set an organizational framework and minimum requirements that impacts all automotive players along the value chain.
  • Put the onus of the cybersecurity certification process on the OEM.
  • Demand that best practices are incorporated into the design of vehicles
  • Demand vehicle manufacturers provide a reasoned argument as to the cybersecurity of their vehicles
  • Require ongoing cybersecurity for vehicles throughout all stages of the vehicle’s lifecycle including post-production
  • Offer a non-conclusive list of cyber threats and corresponding mitigations


The regulation does not:

  • Demand specific vehicle designs or technologies
  • Guarantee that vehicles cannot be hacked (the regulation merely ensures that cyber risk is minimised)
  • Offer processes to secure systems that interact with a vehicle but are outside of the OEM’s control (such as telecom networks or aftermarket devices)
  • Provide any detailed guidance on operational practices
  • List all possible risks and mitigations
Which vehicles does the WP.29 regulation apply to?

The first of the ECE/TRANS/WP.29/GRVA regulations, titled “UN Regulation on uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system” dictates that the regulation applies to vehicles within the M and N (vehicles with at least 4 wheels) categories, the O category (if fitted with at least one electronic control unit), and vehicles in categories L6 and L7 that are equipped with autonomous driving functions beyond level 3. The regulation also clearly indicates that the responsibility to prove that effective cybersecurity methods and processes were used, lies with the OEM; the OEM is responsible for ensuring cybersecurity processes are in place throughout the entire supply chain. 

According to the McKinsey and GSA report4, when looking at the current passenger car market in the ten largest countries regulated under UNECE WP.29, the new regulations will likely affect over 20 million vehicles worldwide, not including commercial vehicles, or any other type of motor vehicle regulated under UNECE WP.29.


How is the WP.29 regulation structured?

The first six sections of the WP.29 regulation highlight the scope of the regulation (Section 1), defines the terms used in the regulation (Section 2), and elaborates on the application, markings, processes, and certifications related to formal regulatory approval (Sections 3-6). One clear indication of the definitive and practical nature of the regulation is seen within the very specific demands within Sections 3-6 and corresponding Annexes 1-4, which even include the exact size and shape of the approval markings. The regulation also includes details on how to approach vehicle modifications (Section 8), demands regarding production conformity and updates regarding continuity (Sections 9-11), and the method by which OEMs need to communicate their approval process with the UN Secretariat (Section 12).

The primary requirements of the regulation are largely discussed in Section 7, titled “Specifications”, where the regulation offers a split approach to automotive cybersecurity requirements, with a correlating certification and approval process for each approach.

The first focuses on Cyber Security Management Systems (CSMS) and includes cybersecurity requirements for an OEM’s organizational structure, processes, and governance. CSMS certification demands evidence from the OEM, including test reports and threat modeling, in order to prove that due diligence was done in ensuring cybersecurity throughout the lifecycle of the vehicle.

The second is a more specific Vehicle Type approval, which involves actually testing the vehicle and certifying that the design of vehicle architecture, the risk assessment procedures, and implementation of cybersecurity controls were executed correctly. In this approval process, an authority tests an individual type of vehicle to check if the cybersecurity measures were actually implemented.

In accordance with its aim to be practical and non-theoretical, in Annex 5, the regulation clearly stipulates that for both CSMS and Vehicle Type approvals, the OEM must take cyber threats, vulnerabilities, and related mitigations into consideration when implementing risk assessments and threat analysis. Many (but not all) of these risks and correlating mitigations are listed in three parts (A, B, and C) in Annex 5.

What are the main principles of CSMS approvals?

When approached at face-value, the CSMS requirements are quite clear: as its title/name indicates, the CSMS approval focuses specifically on the “management systems” involved in automotive cybersecurity, meaning, ensuring the processes in place to manage the cybersecurity efforts within an OEM are effective. In the CSMS approval requirements, the WP.29 attempts to take what was once a relatively arbitrary process (or, in some cases, no process at all), and add beneficial guidelines. Undoubtedly, a thorough, defined, and refined process of cybersecurity management lends itself to more effective cybersecurity.

The main principles involved in CSMS approval demand:

  • Lifecycle Implementation: Vehicle manufacturers must methodically implement cybersecurity measures at each stage of the vehicle life cycle: during the development, production, and post-production phases.
  • Risk Assessment and Management: Security must be adequately considered in all OEM processes including the identification of risk (which includes considering the risks highlighted in Annex 5), assessment and treatment of risk, the effectiveness of cybersecurity measures, and the treatment of data gathered about cyber-attacks.
  • Cyber Threat and Attack Process: OEMs must have a full process where they can effectively monitor, detect, and respond to cyber attacks, cyber threats, and security vulnerabilities.
  • Timeliness: The processes used to manage cybersecurity must allow for timely responses and mitigations to cyber-threats and vulnerabilities.
  • Data and Telematics Usage: Risk assessment and management must be done in a continual manner, and that the OEM has the capability to analyze and detect cyber threats, vulnerabilities and cyber-attacks from vehicle data and vehicle telematics logs.
  • Supply Chain Management: The OEM must manage all the risks associated with contracted Tier 1 and Tier 2 suppliers, service providers, and/or sub-organizations.
What are the main principles of Vehicle Type approvals?

In contrast to CSMS approval, Vehicle Type approval hones in on specific vehicles rather than an overarching process and management system, where each vehicle design from each manufacturer is counted as one individual vehicle type. Vehicle Type requirements detail the various steps an OEM must take for type approval and then, in Sections 8-10, the regulation explains that Vehicle Type approval must be maintained throughout the potential modification of vehicles and the extension of a vehicle if it impacts the vehicle’s technical performance with respect to cybersecurity. It is important to note that in order for an OEM to receive Vehicle Type approval, it must first complete the CSMS approval.

The main principles involved in Vehicle Type approval demand:

  • Application of CSMS: The OEM must prove that proper CSMS was applied to the specific vehicle type.
  • Tier 1 and 2 Supplier Management: It is the OEMs responsibility to identify and manage any risks related to its Tier 1, 2, or other suppliers.
  • TARA: An in-depth TARA (Threat Analysis and Risk Assessment) process must take place for every vehicle type, and include an assessment of the interactions the vehicle will have with external systems. Many of these threats are listed in the regulations Annex 5. Additionally, it is not enough for an OEM to assess the threat, rather it must also find appropriate and proportionate mitigations (which are also highlighted in Annex 5).
  • Threat Reporting: The OEM must provide periodic reports covering detected attacks and new threats.
  • Aftermarket Responsibility: The OEM must build measures to secure the vehicle with regards to aftermarket software, services, applications, or data.
  • Data and Telematics Usage: The OEM must be able to have the ability to analyze the specific vehicle data related to attempted or successful cyber-attacks.
How does the WP.29 regulation approach cyber threats, vulnerabilities, and mitigations?

Though appended at the end of the regulation, Annex 5 is not to be overlooked as it includes the regulation’s most specific stipulations, namely, a list and mapping of cyber threats and their corresponding mitigations. These threats and vulnerabilities must be considered when it comes to the regulation’s demand for effective risk assessment and management.

To help OEMs and automotive suppliers understand and assess the risks associated with connected vehicles, the regulation lists 69 different attack routes due to 7 different cyber threats and vulnerabilities. To aid in the management of said risks, the regulation also offers 23 cybersecurity mitigations with the potential to secure a vehicle, its components, and back-end servers against these threats. It is important to note that while the list of threats, vulnerabilities, and mitigations is extensive, the regulation is quick to point out that it is not exhaustive.

The regulation includes detailed descriptions and examples for threats, and even goes as far as to offer specific examples of potential attack methods. The threats listed are divided into the following 7 categories: back-end servers, vehicle communication channels, vehicle update procedures, unintended human actions, external connectivity and connections, vehicle data/code, and other vulnerabilities.

What are the 7 high-level threat categories mentioned in the regulation?

Threats related to back-end servers
The regulation focuses on 3 specific elements of the back-end server vulnerability: when the back-end server is used as a means to attack a vehicle or extract data, when services from the back-end server are disrupted and affect the operation of a vehicle, and when vehicle related information held on a back-end server is compromised or lost.

The 9 specific attack examples listed in the regulation include insider attacks and unauthorized access, server malfunction, information breaches, and more.

Threats related to vehicle communication channels
The regulation includes 8 detailed descriptions of threats related to the vehicle communication channels: potential spoofing of messages or data, unauthorized manipulation to vehicle code and data, unreliable messages are trusted, sensitive information is easily accessible, potential Denial-Of-Service attacks, privileged access for unprivileged user, viruses embedded in communication media, and messages containing malicious content.

The 20 specific attack examples listed in the regulation include Sybil attacks, tampered code injection, man-in-the-middle attacks, replay attacks, malicious CAN messages, and more.

Threats related to vehicle update procedures
The regulations lists 2 possible threats related to vehicle update procedures: The misuse or compromise of update procedures and the potential to deny legitimate updates.

The 5 specific attack examples listed in the regulation include a compromise of OTA software update procedures, a compromise of cryptographic keys of the software, DOS attacks against critical updates, and more.

Threats related to unintended human actions
Interestingly, the regulation clearly outlines the danger of unintentional attacks, initiated when legitimate actors take actions that could unwittingly facilitate a cyber-attack.

The 2 specific attack examples listed in the regulation are when an innocent victim like the owner, operator or maintenance engineer is tricked into unintentionally loading malware or enabling an attack, or when defined security procedures are not followed.

Threats related to a vehicle’s external connectivity and connections
The regulations lists 3 possible threats related to a vehicle’s external connectivity and connections: manipulation of vehicle telematics, remote operation systems, and systems using short range wireless communications, the utilization of 3rd party applications in an attack, and the utilization of devices connected to external interfaces as a means to attack.

The 7 specific attack examples listed in the regulation include the manipulation of vehicle telematics, dongles in vehicle’s OBD port used to facilitate an attack, and more.

Threats related to a vehicle’s data and/or code
The regulations lists 7 possible threats related to a vehicle’s data and code: the extraction, manipulation, and erasure of data/code, the introduction of malware, the introduction of new software or an overwrite of existing software, the disruption of systems or operations, and the manipulation of vehicle parameters.

The 14 specific attack examples listed in the regulation include product piracy, identity fraud, DOS attack by flooding a CAN bus, falsifying the configuration parameters of vehicle’s key functions, and more.

Threats related to other vulnerabilities
The regulations lists 6 other possible threats: compromised or insufficiently applied cryptographic technologies, compromised parts or supplies, vulnerable software or hardware, vulnerable network design, unintended data transfers, and the physical manipulation of systems.

The 12 specific attack examples listed in the regulation include using short encryption keys and a long period of validity to break encryption, hardware or software that is engineered to enable an attack, software bugs, and more.

Which threat mitigations does the regulation address?

The regulation divides its suggested mitigations related to the aforementioned 7 categories of threats into two main categories: mitigations for threats related to the vehicle itself, and threats related to arenas outside of the vehicle, like the back-end servers.

Mitigations for threats against vehicles include the threats related to vehicle communication channels, vehicle update processes, unintended human actions, external connectivity and connections of the vehicle, data loss and breaches, the physical manipulation of systems, and other vulnerabilities. Mitigations for threats outside of the vehicle includes threats related to back-end servers and unintended human actions.

When analyzing the potential threats, vulnerabilities, and their mitigations, it is clear to see a heavy emphasis on those related to the back-office (back-end servers and other elements related to it), communication channels, and data. By mentioning such a high number of these back-office and communication threats, the regulation seems to indicate where the highest cyber risk is found. This elevated risk is not merely because of the number of threats associated with the vulnerabilities, but because of the direct and dangerous impact that these threats can have on the road user. Ultimately, as with the ISO/SAE 21434 standard, the WP.29 regulation was developed to keep consumers and drivers safer and more secure.

How can I see a clear mapping of all the threats, vulnerabilities and mitigations?

The UNECE WP.29 automotive cybersecurity regulation includes a list (in Annex 5) of 69 different cyber threats and vulnerabilities (divided into 7 sub-categories such as vehicle, back-end server, and communication threats) as well as 23 cybersecurity mitigations required to protect against these threats.

Upstream offers a interactive visual representation mapping tool that helps make that list easier to navigate, understand, and thus implement. The tool allows you to navigate through the different threats and vulnerabilities, learn how they are connected, and see an overview of the scope of the threats, vulnerabilities, and mitigations mentioned in the regulation. To learn more and request access to the tool, CLICK HERE.

What are the implications for OEMs and Tier 1 and 2 Suppliers?

The WP.29 regulation clearly indicates that the onus of supply chain cybersecurity management lies upon the OEM, where it is the responsibility of the vehicle manufacturer to ensure that all vehicle components and parts both hardware and software are secure. While the regulation does not indicate the method by which an OEM must verify the cybersecurity of the Tier 1 and 2 components, it does clearly demand (in Section 5.1.1) that the OEM must “collect and verify the information required under this Regulation through the supply chain so as to demonstrate that supplier-related risks are identified and are managed.”

In addition to the direct threats an OEM may face and thus mitigate, the list in Annex 5 also offers threats that must be mitigated at a Tier 1 or Tier 2 component level. Some of those threats include malicious internal (CAN) messages, the manipulation of functions designed to remotely operate systems, such as remote key, immobilizer, and charging pile, corrupted applications, hardware or software, engineered to enable an attack or fails to meet design criteria to stop an attack, and more.

One of the many potential mitigations to these threats offers insight into the interconnected role between OEMs and Tier 1s. The regulation suggests that as a mitigation to the threat of corrupted applications, software shall be security assessed, authenticated and integrity protected. Software components are provided to the OEM by other supply chain partners, and thus the OEM must demand that those suppliers ensure the integrity of their components. While a Tier 1 or 2 is not required to receive its own compliance certificate, those that do not provide evidence to the OEM that they implemented all necessary cybersecurity measures, will most likely be cut off by the OEM and lose business.

Additionally, the regulation clearly demands cybersecurity measures throughout the entire lifecycle of the vehicle, which includes the development, production, and post-production phases. While the OEM can ensure cybersecurity measures are in place during the production phase, it must rely on its suppliers and then service providers to provide cybersecurity measures during the development (of all the components, chips, parts, etc) of the vehicle as well as the post-production services such as OTA updates, smart services related to the connected car (remote unlock door or engine start), access control for software, and more.

What is the certification process for CSMS and Vehicle Type approval?

WP.29 regulation intentionally avoids dictating specific technical measures for compliance, as such, the ISO/SAE 21434 standard could be used as a basis for evidencing and evaluating the fulfilment of the CSMS and Vehicle Type requirements of an OEM. Clause 5 “Overall Cybersecurity Management”, Clause 6 “Project Dependent Cybersecurity Management”, and Clause 7 “Continuous Cybersecurity Activities” of the standard could be used to evaluate the OEM’s CSMS, and Clause 8 “Risk Assessment Methods” can be used to assess risk for Vehicle Type approval.

The ultimate goal of the regulation however is not to simply build an effective CSMS, but to use this CSMS to gain Vehicle Type approval and ensure that the vehicles that will be on the road are cyber-secured.

The certification process is as follows:

  1. The OEM implements an effective and regulatory compliant CSMS
  2. The OEM submits an application for a Certificate of Compliance for
  3. Cyber Security Management System to an Approval Authority or its Technical Service
  4. The CSMS is the assessed by the Approval Authority or Technical Service
  5. The OEM signs a declaration of compliance
  6. The OEM is issued a CSMS certificate of compliance, with 3 years until a renewal is needed.
  7. The OEM develops vehicle architecture with CSMS involved
  8. The individual vehicle type is assessed by the Approval Authority or Technical Service
  9. Vehicle Type Certification is issued

The regulation details the format and design of the declarations, approval marks, and certificates in Annex 1-4. With regard to Vehicle Type approval, approved vehicles are marked with an E and a number, within a circle. The number beside the E indicates which country approved the item, and the other surrounding digits and letters indicate the version of the regulation and the type approval number.

What role does Upstream play in the implementation of the regulation?

As the regulation highlights, through its listing of relevant threats and vulnerabilities, cyber attacks target not only endpoint devices (vehicles), but back-end servers and entire network environments. As such, OEMs must integrate the necessary cybersecurity measures to achieve powerful protection against not only in-vehicle threats, but also remote attacks and data breaches. While in-vehicle cybersecurity tools are vital to protect against some attacks, connected vehicles require an additional defense layer to protect them from remote cyber attacks that target back-end servers. Effective cybersecurity requires a multi-pronged approach, as a one-size-fits-all product does not provide adequate protection. As such, OEMs must employ multiple measures and cybersecurity tools to ensure that they have end-to-end protection throughout the entire supply chain and production process.

For a true protection of the connected car ecosystem, OEMs must consider a defense-in-depth approach, with cybersecurity solutions to cover in-vehicle security, IT security, and most importantly the single and multi-vehicle automotive cloud. Upstream’s automotive cloud cybersecurity platform covers the entire operational security element of the vehicle through three vital spaces within this ecosystem:

  1. The communication channels to and from the vehicles
  2. The automotive cloud hosting the vehicle’s control systems
  3. The vehicle itself

In short, Upstream’s solution offers holistic monitoring of security events across all the connected sources, covering communications between the vehicles, the infrastructure, and the third party services and applications connected to the automotive cloud network.

This centralized automotive cloud security protects the connected car’s entire ecosystem and offers vital components such as context and behavioral analysis. Based on correlating multiple security events, cloud-based cybersecurity provides full visibility of all users, devices, and data feeds, and turns that data into actionable intelligence to alert on real-time events and prevent future attacks.

How can I check my organization's current compliance state and understand what we’re missing?

Upstream developed a and easy-to-use gap analysis tool in the form of a questionnaire. The report is generated based on WP.29’s Annex 5 to help you get a clearer picture of your current status vs. the requirements related to threats, vulnerabilities and mitigations. With this assessment, you can mark which cybersecurity mitigations are currently in place within your company and receive a security-gap analysis report. This will enable you to see where you stand in regard to regulatory compliance and offer a quick overview of areas that may need more attention. CLICK HERE for more details and request access to the tool. The tool is available both in English and Japanese.

Questions about the ISO/SAE 21434 Standard
Who was involved in the writing of the standard?

In 2016, SAE International, the professional association and standards developing organization for engineering professionals, and ISO, the International Organization for Standardization, an international standard-setting body composed of representatives from various national standards organizations, came together to tackle this issue of setting industry standards related to automotive cybersecurity. 

Both organizations had individually worked on automotive safety and security related standards in the past; ISO 26262 had previously set functional safety standards and SAE J3061 set the foundation for cybersecurity standards. When both organizations realized they had a common goal, they came together with OEMs, ECU suppliers, cybersecurity vendors, and governing organizations, and with more than 100 experts from more than 82 companies based in over 16 countries, a joint working group was established to compose a deep and effective global standard for automotive cybersecurity. Using four main working groups focusing on risk management; product development; production, operation, maintenance, and decommissioning; and process overview, the ISO/SAE 21434 draft was born.

Why was the standard needed?

The need for this standard was clear:

    1. Common cyber-related terminologies to be used in the automotive industry were needed. In the past, the many different terms being used caused difficulty in understanding cyber-risk and how to mitigate it. 
    2. Criteria for effective cybersecurity in a vehicle was needed. Prior to the ISO/SAE 21434 standard, there was never a definition of what “sufficient cybersecurity” meant.
    3. While there were advanced and accepted standards for automotive safety, where the concept of ASIL (Automotive Safety Integrity Levels) was understood and applied, there was no complementary cybersecurity standard definition, as proprietary levels of cybersecurity assurance differed company-by-company. 
    4. And finally, there needed to be a standardized reference for regulators to point to and use to enforce vehicle cybersecurity, ensuring that drivers of connected vehicles were kept safe and secure from cyber threats and attacks.
What are the benefits of the standard?

The benefits of the standard are obvious. ISO/SAE 21434 brings with it the potential for common terminology for the supply chain, industry consensus, a clear minimum criteria for vehicle cybersecurity engineering, cybersecurity driven into the vehicle design upfront, threat landscapes that are clearly defined, key references for regulators, and a new level of trust built between stakeholders.

How is the standard structured?

The first four clauses of the standard highlight the scope (Clause 1), references (Clause 2), definitions (Clause 3), and general considerations (Clause 4) of the standard. 

The bulk of the standard requirements are covered in Clauses 5-14, where: 

Clauses 5 and 6 focus on the management of cybersecurity and include the implementation of organizational cybersecurity policies, rules, and processes for overall cybersecurity management and for project dependent cybersecurity management (similar and relevant to the WP.29 CSMS regulation). 

Clause 7, titled “Continuous Cybersecurity Activities” defines activities that provide information for ongoing risk assessments and vulnerability management of vehicles. 

Clause 8 titled “Risk Assessment Methods” defines methods to determine the extent of cybersecurity risk. 

Clauses 9-14 cover the requirements throughout the entire lifecycle of a vehicle, with the “Concept Phase” (Clause 9) “Product Development Phases” (Clauses 10 and 11), and the “Post-Development Phases” (Clauses 12-14).

In Clause 15, titled “Distributed Activities” the standard details the requirements for supplier management, and defines the interactions, dependencies, and responsibilities between customers (OEMs) and suppliers (Tier 1 and 2s) for cybersecurity activities.

The standard also includes 10 Annexes (A-J) which as the standard explains “The annexes in this document are all informative and are used to provide additional information to the main body of the document for several reasons, for example:

  • when the information or table is very long;
  • to set apart special types of information;
  • to present information regarding a particular application of the document.
Which elements of the automotive ecosystem does the standard apply to?

In Clause 4 titled “General Considerations” of the standard it points out that: “The application of this document is limited to cybersecurity relevant items and components inside or on the vehicle

perimeter including aftermarket and service parts. Systems outside the vehicle perimeter can be considered for cybersecurity purposes but are not in the scope of this document. The following are examples of what can be considered for the vehicle level as a whole:

a) the vehicle E/E architecture

b) the cybersecurity cases of the cybersecurity relevant items and components”

What falls within the scope of the standard?

ISO/SAE 21434, in draft form as of May 2020, is a baseline for vehicle manufacturers and suppliers to ensure that cybersecurity risks are managed efficiently and effectively. The standard was specifically developed to ensure the safety and security of the ultimate road-user/driver, and as such, the determinant levels of risk and corresponding cybersecurity measures are set based on the final impact on the driver.

The standard provides a standardized cybersecurity framework, establishes cybersecurity as an integral element of engineering throughout the lifecycle of a vehicle from the conceptual phase all the way through decommissioning, ensures that cybersecurity is considered in post-production processes (software updates, service and maintenance, incident response etc), and calls for effective methods of lessons learned, training, and communication-related to automotive cybersecurity. 

More specifically, the scope of the standard includes:

  • Specific requirements for cybersecurity risk management 
  • A cybersecurity process framework
  • Common language to help manufacturers and organizations communicate their cybersecurity risk
What falls outside of the scope of the standard?

Quite intentionally, ISO/SAE 21434 does not dictate specific cybersecurity technologies or solutions, mandates around remediation methods, or cybersecurity requirements for telecommunications systems, connected backend-servers, EV chargers, or autonomous vehicles.

Rather, the standard heavily emphasizes risk identification methods and established processes to address the cyber-risks. As such, dictates the standard, if a compromised backend-server, charger, or autonomous vehicle leads to a direct risk to the road-user, it must be monitored, controlled, and mitigated. Upstream Security enables the relevant parties within the automotive ecosystem to identify the risk and respond as the standard requires.

How is risk assessment approached according to the standard?

The standard requires OEMs and service-providers to analyze new and emerging threats and risks throughout a vehicle’s lifecycle to determine the extent to which a road user/driver can be impacted by a threat scenario. This general process of threat analysis and risk assessment is called “TARA”. 

The standard’s methods for effective risk assessment (TARA) include:

  • Asset Identification- 
    • Knowing WHAT can be harmed
    • In the words of the standard: Identification of damage scenarios and assets of an item or component..  
  • Threat Scenario Identification
    • Knowing HOW the assets can be harmed
    • In the words of the standard: The identification of threat scenarios to the cybersecurity properties of the assets under analysis.
  • Threat Impact Analysis and Rating-
    • HOW MUCH harm will the threat cause
    • In the words of the standard: Estimation of the magnitude of damage or physical harm associated with a damage scenario.
  • Attack Path Analysis-
    • WHAT actions lead to the threat
    • In the words of the standard: Identification and linking of potential attack paths to one or more threat scenarios.
  • Attack Feasibility Analysis and Rating-
    • HOW LIKELY will it be for the harm to occur
    • In the words of the standard: The rating of the feasibility of attack paths based on the ease of exploitation.
  • Risk Determination-
    • HOW BAD is the risk caused by the threat
    • In the words of the standard: The determination of the risk value of a threat scenario.
  • Risk Treatment Decision: 
    • WHAT TO DO about the risk 
    • In the words of the standard: Addressing identified risks by selecting a suitable risk treatment option.

ISO-SAE explains that the methods/”modules” listed are not connected to a particular phase of the vehicle’s lifecycle and can be used in the order most appropriate for the OEM.

What does the standard require regarding Tier 1 and 2 suppliers?

Clause 15 of the standard focuses on “distributed cybersecurity activities” and discusses the cybersecurity relationship between OEMs and Tier 1 and 2 suppliers. 

An OEM is responsible to ensure that the suppliers used are implementing methods to ensure their products and components are cybersecure. There are three main strategies to develop a successful supplier and OEM relationship:

  1. Evaluate: (Clause 15.4.1) “Demonstration and Evaluation of Supplier Capability”
    • As part of the supplier assessment and evaluation by the OEM, the supplier should supply an “Cybersecurity Record of Capability” which includes 
      • Evidence of their capabilities regarding cybersecurity 
      • Evidence of continuous cybersecurity activities
      • A summary of previous cybersecurity assessments
      • Organizational audit results
      • Evidence of an information security management system
      • Evidence of the organization’s management systems
  2. Confirm: (Clause 15.4.2) “Request for Quotation”
    • When an OEM purchases supplies and components from Tier 1 or 2s, they should include within their quote:
      • A formal request that the supplier will comply with the standard
      • A list of the expectations of the cybersecurity responsibilities to be taken by the supplier
      • Details of the the cybersecurity goals or the set of relevant cybersecurity requirements for the supplier
  3. Align: (Clause 15.4.3) “Alignment of Responsibilities”
    • The OEM and supplier must agree with the division and alignment of responsibility, through a process called CIAD “cybersecurity interface agreement for development”. The CIAD division of responsibility includes agreements on:
      • OEM and suppliers’ points of contact regarding cybersecurity
      • A joint tailoring of the cybersecurity activities 
      • The identification of the cybersecurity activities that are to be performed by the OEM and by the supplier
    • The OEM and the suppliers should build the CIAD division of cybersecurity responsibilities using the RASIC model.
      • Mentioned in Annex C of the standard and stands for:
        • R (responsible): The organization that is responsible for getting the activity done
        • A (approval): The organization that has the authority to approve or deny the activity once it is complete
        • S (support): The organization that a will help the organization responsible for the activity;
        • I (inform): The organization that is informed of the progress of the activity and any decisions being made; and
        • C (consult): The organization that offers advice or guidance but does not actively work on the activity.
What role does Upstream play in the implementation of the standard?

Just as the ISO/SAE 21434 standard approaches the entire ecosystem related to the connected vehicle and not merely the vehicle itself, so too, Upstream analyzes the entire cybersecurity ecosystem of the connected vehicle through the automotive cloud for both on-board (in-vehicle) threats as well as off-board (back-end cloud telematics servers and services) threats. 

Upstream aids OEMs, connected vehicle fleets, Tier 1 suppliers, and others to meet important aspects of the ISO/SAE 21434 standard through multiple verticals using Upstream C4 “Centralized Connected Car Cybersecurity” a cloud-based automotive cybersecurity platform leveraging Upstream’s AutoThreat Intelligence, the first automotive cybersecurity threat feed in the industry. Specifically, Upstream provides solutions to help meet three primary requirements in the standard: continuous cybersecurity activities, defined methods to determine cyber risks, and post development phase of operations and maintenance.

To see how Upstream aids in the compliance with the standard, download our ISO/SAE 21434.

Where is the most updated text of the standard?

To learn more and purchase the standard draft, you can visit the SAE website by clicking here.