Picture a supplier of infotainment control units that receives a new request for quotation from a carmaker. Alongside the functional requirements, it contains a set of cybersecurity questions: how the company identifies threats to the component, who approves the risk assessment, how it reports vulnerabilities after the start of production and how it secures software updates. The scenario is hypothetical, but it reflects the situation of companies in the automotive supply chain well — questions about ISO/SAE 21434 are no longer the preserve of R&D departments and have reached sales teams.
This article puts the topic in order from the perspective of a vehicle manufacturer and its suppliers. We explain what the scope of the standard actually says, why its legal status is often misunderstood, what UN Regulations No 155 and No 156 require and how to plan implementation so that preparing for type approval does not start with chaos in the documentation. The wider background of threats to connected vehicles is covered in our article on connected car security and ISO 21434.
What is ISO/SAE 21434 and what does it cover?
ISO/SAE 21434:2021 “Road vehicles — Cybersecurity engineering” is a joint ISO and SAE standard dedicated to cybersecurity engineering for road vehicles. According to the description of its scope, published for example in the catalogue of the Estonian standards body EVS, the document specifies engineering requirements for cybersecurity risk management regarding the concept, product development, production, operation, maintenance and decommissioning of electrical and electronic (E/E) systems in road vehicles, including their components and interfaces.
The standard defines a framework that includes requirements for cybersecurity processes and a common language for communicating and managing cybersecurity risk. A vehicle manufacturer, a module supplier and a software supplier must describe threats, goals and security measures in a comparable way, otherwise the exchange of documentation in the supply chain turns into translating between different methodologies.
Two limitations written into the scope also matter. First, the standard applies to series production road vehicle E/E systems whose development or modification began after its publication. Second, it does not prescribe specific technology or solutions — it does not say which encryption, which network gateway or which hardware security module to use. Instead, it expects the choice of security measures to follow from risk management.
In practice this means that ISO/SAE 21434 is first and foremost a process standard. What is assessed is not whether a control unit contains a particular mechanism, but whether the organisation can show why it applied it, who made the decision and how the risk will be controlled throughout the product lifecycle.
Is ISO/SAE 21434 mandatory for vehicle manufacturers?
The short answer is that the standard itself is not directly required, whereas the requirements of UN Regulation No 155, which the standard helps to meet, are mandatory. The distinction is worth knowing, because market materials often repeat the simplification “ISO 21434 is required by UNECE”. The text of UN Regulation No 155 published in the Official Journal of the EU mentions ISO/SAE 21434 in a footnote — as an example of a standard, next to ISO 26262-2018 and ISO/PAS 21448, in the context of the competence of the personnel of approval authorities.
In the European Union, the obligation comes from type-approval law. Regulation (EU) 2019/2144 in its consolidated version lists in Annex II the requirement “D4 Protection of vehicle against cyberattacks”, refers in it to UN Regulation No 155 and assigns it the dates of group B. For that group, the rules set refusal to grant EU type-approval from 6 July 2022 and prohibition of the registration of vehicles from 7 July 2024.
Already in the recitals of the original text of Regulation (EU) 2019/2144, the legislator stated that UN Regulations or other regulatory acts on cyber security should be applied on a mandatory basis as soon as possible after their entry into force. The rationale was the connectivity and automation of vehicles, which increase the possibility for unauthorised remote access to in-vehicle data.
So why do manufacturers expect ISO/SAE 21434 from their suppliers anyway? Because Regulation No 155 says what has to be demonstrated, but it does not describe in detail how to organise the engineering work. The standard fills that gap and provides a common reference point for supplier audits. The decision on formal implementation still belongs to the organisation and its customers, which is why it is worth stating it explicitly in contracts and specifications.
What does UN Regulation No 155 require from a vehicle manufacturer?
UN Regulation No 155 applies to vehicles of categories M and N with regard to cybersecurity, and also to vehicles of category O if they are fitted with at least one electronic control unit. Its core is the cybersecurity management system (CSMS), a systematic risk-based approach defining organisational processes, responsibilities and governance.
The manufacturer must demonstrate that the CSMS covers the development phase, the production phase and the post-production phase. The last of these lasts until the end-of-life of all vehicles of a given type, that is long after production ends. CSMS processes must include, among other things, the identification of risks to vehicle types, their assessment and categorisation, cybersecurity testing, keeping the risk assessment current, and monitoring for and detecting cyberattacks as well as responding to them.
Monitoring does not end at the factory gate. The regulation requires monitoring to include vehicles after first registration, and the manufacturer reports to the approval authority at least once a year the outcome of its monitoring activities, including relevant information on new cyberattacks. Responsibility for an effective CSMS therefore lies with an organisation that maintains the ability to analyse data from vehicles in operation for years.
The formal confirmation is the Certificate of Compliance for the cybersecurity management system, which remains valid for a maximum of three years from the date of issue unless it is withdrawn. Vehicle type approval is granted separately, and a valid Certificate of Compliance relevant to the vehicle type is a condition for it.
How does threat analysis and risk assessment (TARA) work in practice?
Threat analysis and risk assessment, TARA for short, is the point at which general principles turn into design decisions. UN Regulation No 155 defines risk assessment as the overall process of finding, recognising and describing risks, determining their level and comparing the results of the analysis with risk criteria to determine whether the risk is acceptable or tolerable.
The requirements for the vehicle type are specific. The manufacturer identifies the critical elements of the vehicle type and performs an exhaustive risk assessment that considers the individual elements, their interactions and interactions with any external systems. Annex 5 of the regulation contains a list of threats and corresponding mitigations. Failing to perform an exhaustive risk assessment is one of the grounds for refusing approval listed in the regulation.
In a well-run TARA, every identified attack scenario has an owner, an impact and feasibility rating, a risk treatment decision and a link to requirements for the design teams. The biggest mistake is treating TARA as a one-off document for type approval. The regulation requires processes that keep the risk assessment current, so a new vulnerability in a communication library or a new diagnostic interface should trigger its review.
For many organisations, a good starting point is an external review of the risk assessment methodology before it is replicated in further projects. nFlo provides reviews, audits and consulting in the area of risk analysis, which help check the consistency of criteria and the completeness of documentation.
What obligations for software updates does UN Regulation No 156 introduce?
UN Regulation No 156 complements Regulation No 155 with the software update process. It applies to vehicles of categories M, N, O, R, S and T that permit software updates. Its counterpart to the CSMS is the software update management system (SUMS), a systematic approach defining organisational processes and procedures to comply with the requirements for the delivery of software updates.
The regulation introduces the RXSWIN identifier, a dedicated identifier defined by the manufacturer for software relevant to type approval. It makes it possible to document which software versions were in the vehicle before and after an update. The authenticity and integrity of software updates must be protected to reasonably prevent their compromise and reasonably prevent invalid updates.
Over-the-air (OTA) updates add functional requirements. The vehicle must be able to restore systems to their previous version or be placed into a safe state after a failed or interrupted update. An update may only be executed when the vehicle has enough power to complete the process, and the manufacturer must demonstrate that the vehicle user is able to be informed about an update before the update is executed.
From the ISO/SAE 21434 perspective, the update channel is one of the key assets to cover in the risk assessment. Package signing, protection of cryptographic keys and separation of software build environments are areas where design mistakes translate directly into difficulties in demonstrating compliance with Regulation No 156.
What do ISO/SAE 21434 and Regulation No 155 mean for component suppliers?
UN Regulation No 155 addresses the vehicle manufacturer, but its requirements quickly cascade down the supply chain. The manufacturer must demonstrate how its CSMS will manage dependencies that may exist with contracted suppliers or service providers. It must also identify and manage supplier-related risks, and the approval authority checks whether information was collected and verified through the supply chain.
For a supplier, this means specific expectations: a described cybersecurity process for the component, a split of responsibilities with the customer, the ability to hand over risk analysis and test results, and a vulnerability handling process after the start of production. ISO/SAE 21434 provides a common vocabulary for this, so that the supplier and the manufacturer can agree on the scope of work without disputes about terminology.
In commercial relationships, three things are worth agreeing in advance: who performs the risk assessment for the component and at what level of detail, how long the supplier supports the product in the post-production phase, and how it passes on information about new vulnerabilities. Missing agreements usually surface only when documentation is being prepared for type approval, when there is the least time for changes.
A separate issue is the protection of information exchanged in the project. The regulation provides that information covered by intellectual property rights of the manufacturer or its suppliers shall be treated on a confidential basis, but securing the exchange of design documents itself is up to the companies.
How does ISO/SAE 21434 differ from TISAX?
TISAX and ISO/SAE 21434 often appear in the same procurement requirements, but they answer different questions. According to the ENX Association, which governs TISAX, TISAX was developed to create a standardized and scalable approach to information security in the automotive industry, and it is based on the Information Security Assessment (ISA) catalogue. What it protects includes design data, production information, customer information, prototypes and intellectual property.
ISO/SAE 21434, by contrast, concerns cybersecurity engineering of the product itself, that is the vehicle’s E/E systems, their components and interfaces across the whole lifecycle. To simplify: TISAX answers the question of whether an organisation handles customer information securely, while ISO/SAE 21434 answers whether a product is designed and maintained with cybersecurity risk under control.
The form of the result differs too. The results of a TISAX assessment are issued as labels which, according to ENX, are valid for three years, and the company shares them with selected partners through the ENX Portal. For ISO/SAE 21434, it is worth agreeing with the customer already at the offer stage which evidence of compliance will be handed over in the project and in what form.
The two frameworks complement each other well. The details of preparing for a TISAX assessment are covered in our article What is TISAX and how to prepare for it, and nFlo supports this process through TISAX reviews and consulting for the automotive industry.
How to prepare an organisation for implementing ISO/SAE 21434?
Implementation starts with a decision on scope, not with tools. You need to establish which products and projects it covers, what the role of the organisation is (vehicle manufacturer, system supplier, software supplier) and which requirements have already arrived from customers. On that basis, a product cybersecurity policy and an assignment of responsibilities are created — with a person who has real influence on design decisions.
The second step is a gap analysis against current engineering processes. Companies with a mature functional safety process usually have ready elements: requirements management, reviews and configuration management. ISO/SAE 21434 adds a cybersecurity risk layer to them. It is also worth checking cryptography along the way, because Regulation No 155 requires cryptographic modules to be in line with consensus standards and, if they are not, the manufacturer must justify their use.
The third step is a pilot on a single project. It is better to go through the full cycle — from risk assessment, through requirements and tests, to a monitoring plan — on one component than to produce documents for the whole portfolio in parallel. The pilot shows which templates work, how much effort the analysis requires and where competences are missing.
The fourth step is operational capability after the start of production: monitoring of vulnerability information sources, assessing their impact on vehicles already produced and a path for delivering fixes. Regulation No 155 requires cyber threats and vulnerabilities which require a response from the manufacturer to be mitigated within a reasonable timeframe.
What role do penetration tests of ECUs and embedded software play?
Testing is a requirement, not an add-on. UN Regulation No 155 states that the vehicle manufacturer shall perform, prior to type approval, appropriate and sufficient testing to verify the effectiveness of the security measures implemented. The approval authority or the technical service additionally verifies by testing a vehicle of the vehicle type that the manufacturer has implemented the cybersecurity measures it has documented.
In practice, tests verify the assumptions of the risk assessment. If the analysis assumes that a diagnostic interface requires authentication, the test checks whether this is really the case and whether it can be bypassed. If update protection relies on a digital signature, the test checks the handling of malformed packages and resistance to rolling back to an older, vulnerable software version.
The test scope usually covers control unit firmware, communication interfaces, companion applications and the backend services the vehicle connects to. nFlo performs firmware and embedded software penetration tests, and for network services and applications — penetration testing of infrastructure and applications. The link between testing and supply chain requirements is also discussed in our article on TISAX and penetration testing in automotive.
It is worth linking test results to documentation straight away. A finding should return to the risk assessment as a new or updated scenario, and its handling to the action plan. The test report then becomes evidence for the approval authority rather than a separate document.
What documents need to be prepared for type approval?
An application for type approval with regard to cybersecurity includes, among other things, the Certificate of Compliance for the cybersecurity management system. Annex 1 of UN Regulation No 155 lists documents for the vehicle type: the outcome of the risk assessment and the identified risks, a description of the mitigations implemented and how they address the stated risks, a description of the protection of dedicated environments for aftermarket software and data, a description of the tests used together with their outcome, and a description of the consideration of the supply chain.
The documentation has two parts: a formal package supplied with the application and additional material made open for inspection. The manufacturer must ensure that material made open for inspection remains available for at least a period of 10 years counted from the time when production of the vehicle type is definitively discontinued. This is an argument for designing the evidence repository with long-term retention in mind from the start.
A good practice is to keep a single traceability matrix: threat, risk assessment, requirement, mitigation, test and result. Such a matrix makes it easier to answer questions from the authority and the customer and shows gaps before an auditor does.
How to plan implementation step by step?
The roadmap below links the requirements of the standard and the regulations with the work products worth having at each stage. The order matters more than the pace: each stage uses the results of the previous one.
| Stage | Goal | Work product | Reference point |
|---|---|---|---|
| Scope and responsibility | Establish products, the role of the organisation and the topic owner | Product cybersecurity policy, role matrix | ISO/SAE 21434 — process framework |
| Gap analysis | Compare current engineering processes with the requirements | List of gaps with an action plan | ISO/SAE 21434, UN Regulation No 155 (CSMS) |
| Pilot risk assessment (TARA) | Go through the full cycle on one component | Risk assessment with decisions and owners | UN Regulation No 155 — exhaustive risk assessment |
| Requirements and design | Translate risks into mitigations | Security requirements and architecture | UN Regulation No 155 — Annex 5 |
| Testing | Verify the effectiveness of measures before approval | Test report linked to the risk assessment | UN Regulation No 155 — testing prior to type approval |
| Software updates | Secure the update channel and version records | SUMS process, RXSWIN records | UN Regulation No 156 |
| Monitoring and response | Keep risk under control after first registration | Vulnerability handling process, report at least once a year | UN Regulation No 155 — continual monitoring |
Key takeaways
- ISO/SAE 21434 is a process standard: it specifies engineering requirements for cybersecurity risk management across the lifecycle of E/E systems and does not prescribe specific technologies.
- In the EU, UN Regulation No 155 is mandatory (through Regulation (EU) 2019/2144), not the standard itself; the regulation names ISO/SAE 21434 as an example.
- The CSMS covers the development, production and post-production phases, and monitoring includes vehicles after first registration.
- UN Regulation No 156 adds requirements for software updates: SUMS, RXSWIN and safe OTA updates.
- Component suppliers feel the requirements through contracts with the manufacturer, so the scope of risk assessment and vulnerability handling is worth agreeing before the project starts.
Cybersecurity for Your Industry
Learn more about cybersecurity in your industry:
