A first look at Cyber Resilience Act – from the perspective of ISO/SAE 21434

Before we dive in, let’s start with the exceptions. Certain industries and product groups that are already covered by other relevant regulations are excluded from the CRA requirements. This includes vehicles that are subject to type approval under UN Regulation No. 155. So, if you formally fall under an industry-specific directive (including civil aviation, medical devices, etc.), the CRA does not apply to you.

As a professional in vehicle cybersecurity, you are probably wondering about this: an interesting situation arises here. Formally, UN R155 only applies to vehicle manufacturers. However, they are held responsible for the cyber risks of their supply chain. They therefore usually cascade the UN R155 requirements 1:1.

Looking at development projects in practice, in which suppliers and technology providers can operate as suppliers across various markets with their hardware, software, control units, and networked components, the CRA is likely to apply. This is particularly true for players who place their products in the broader automotive ecosystem beyond the vehicle itself (and the associated type approval).

Comparing ISO/SAE 21434 with Cyber Resilience Act: Why should we do that?

It is important to understand that the Cyber Resilience Act, whose initial requirements will become mandatory in 2026 and which will be fully implemented in December 2027, effectively represents a barrier to market entry for products within the EU. Anyone who does not meet the relevant cybersecurity requirements will no longer be able to sell their products “with digital elements” within the EU.

It is therefore worth taking a look at the details of the CRA. Those who are already familiar with the ISO/SAE 21434 standard (officially published in 2021) will notice four possibilities when comparing ISO/SAE 21434 and CRA:

• Synergies: For example, both guidelines call for structured cybersecurity governance, systematic risk assessment (hello, Threat Analysis & Risk Assessment!), and continuous vulnerability management.
• Extensions, e.g., ISO/SAE 21434 remains abstract in many areas, while the CRA specifically identifies horizontal market requirements, such as CE marking, certain mandatory reporting, and the need for software bill of materials (SBOM) documentation.
• New dimensions/context, e.g., the CRA specifically mentions market surveillance, administrative penalties, and EU-wide reporting systems.
• Practical benefits, e.g., specifically, companies with existing ISO/SAE 21434 compliance will be able to use this as a foundation; however, they will still need to make significant additions.

The structure of ISO/SAE 21434 as a foundation for efficient implementation of the CRA

Let’s take a high-level look at all the clauses of ISO/SAE 21434:2021 to develop an initial analysis of the two guidelines.

Clause 5 Organizational Cybersecurity Management – What equivalence does the CRA provide?

Clause 5 of ISO/SAE 21434 refers to organizational cybersecurity requirements and cybersecurity management in the context of organization, processes, and structures. ISO/SAE 21434 creates a detailed organizational framework. Cybersecurity governance is comprehensively defined by specifying concrete obligations for organizations, for example in the areas of awareness, competence management, corporate culture, and continuous improvement processes.

Specific rules, policies, and processes are to be established to promote the exchange of information, knowledge, and skills within the organization with regard to cybersecurity.

ISO/SAE 21434 specifies concrete work products that need to be developed to ensure the organizational cybersecurity outlined. (These then form the basis for the Cybersecurity Management System (CSMS), as required by UN R155.)

In contrast, the Cyber Resilience Act does not contain any explicit organizational structures, nor does it define any processes or associated audits in a comparable manner. The CRA therefore does not require the establishment of a specific CSMS or concrete structures, processes, roles, and policies, as required by ISO/SAE 21434 in Clause 5.

Nevertheless, the CRA expects manufacturers – from a product perspective – to take appropriate measures to ensure cybersecurity. No specific process model or detailed specifications for establishing quality and information security management systems are provided.

Standards such as ISO 9001 or ISO/IEC 27001 can be helpful here, as they offer a certain process landscape into which specific CRA requirements can be integrated.

In summary: Although the CRA does not contain any specific process or structural definitions, orientation towards ISO/SAE 21434 can still be useful and effective in practice. This applies in particular to the efficient assignment of responsibilities and processes at the organizational level, which are likely to be necessary in order to meet all of the listed product cybersecurity requirements.

Chapter 6 Project-specific cybersecurity management and why CRA does not think in development projects

A key difference between ISO/SAE 21434 and CRA is evident in the way projects are handled. ISO/SAE 21434 is based on clearly defined development projects in which cybersecurity-related aspects must be planned and documented from the very beginning. Among other things, this is done by means of the required Cybersecurity Plan, which specifies responsibilities, measures, and project structure. The so-called Cybersecurity Case finally explains why the product can be classified as being harmless from a security perspective.

This approach is reviewed as part of an assessment, often by an independent body.

The CRA, on the other hand, does not think in terms of projects, but requires the preparation of a technical product documentation, as described in Article 31 and Annex VII.

In addition, there is no explicit obligation in the CRA to structure activities or responsibilities on a project basis. In practice, however, it is still advisable to integrate the preparation of documentation into project management in a meaningful way – for example, to keep costs down. In addition, there is no explicit obligation in the CRA to structure activities or responsibilities on a project basis. In practice, however, it is still advisable to integrate the creation of documentation into project management in a meaningful way – for example, to avoid costs, delays, or coordination problems. Unlike ISO/SAE 21434, the CRA does not require any proof of planning.

Particularly in the automotive industry, where development projects are complex and involve many stakeholders, it makes sense to create cybersecurity documentation not in isolation, but within the framework of established project structures. In other, less project-heavy industries, the approach may be more flexible – nevertheless, detailed planning with a view to the ultimately product-specific cybersecurity requirements should not be neglected there either.

With regard to documentation as part of cybersecurity-related evidence, it should be mentioned here that another connecting element is the so-called Conformity Assessment in the CRA. It is reminiscent of the Cybersecurity Assessment from ISO/SAE 21434, but goes even further in regulatory terms: The dealer – i.e., the distributor – must prove that the cybersecurity requirements are met (see CRA, Annex I).

Depending on the criticality of the product, a self-declaration may suffice, or an assessment by a specific third-party body may be necessary – especially for safety-critical or highly connected products.

In summary: The CRA does not explicitly require the development of a Cybersecurity Plan, Cybersecurity Case, and a Cybersecurity Assessment Report (as per ISO/SAE 21434). However, they can be a useful support (in the sense of preparatory work!) for fulfilling the CRA’s documentation requirements.

 And to put it more abstractly: the CRA does not care how a development project fulfills the obligations imposed on it.

Clause 7 Distributed Cybersecurity activities – A closer look at manufacturer liability in the CRA

A key difference between ISO/SAE 21434 and CRA is evident in the way suppliers and ongoing security activities are handled—in other words, what happens “after the project start” or even “after the start of production (SOP for short).”

ISO/SAE 21434 makes a clear distinction between

• Distributed development, e.g., when a supplier develops a system on behalf of a customer
• and components that are integrated into a vehicle as so-called “off-the-shelf” products (e.g., standardized hardware modules).

In both cases, the standard requires that responsibilities be clearly defined — ideally in the form of a cybersecurity-specific service interface agreement, known as a Cybersecurity Interface Agreement (CIA) — and that cybersecurity activities be taken into account throughout the entire product lifecycle.

The CRA, on the other hand, does not initially make an explicit distinction between different models of cooperation (e.g., OEM vs. Tier 1).

However, it does set out clear requirements: Manufacturers who place a product on the market are fully responsible for compliance with cybersecurity requirements – including all integrated components.

This means that even if a manufacturer (re)uses a product from a supplier, it must ensure that the cybersecurity of this component in its product is guaranteed.

In addition to the CRA, this includes, in particular, effective vulnerability management along the entire supply chain. Manufacturers must therefore establish processes to identify and evaluate vulnerabilities in components – including those from third parties – and provide updates if necessary. This applies to the entire product lifecycle until complete decommissioning, exactly as it does in ISO/SAE 21434.

Although the CRA does not contain an explicit section on supplier management requirements, several articles and recitals (e.g., Article 13 and Recital 34) point out that manufacturers may only place products on the market if they can guarantee the security of the integrated components.

This also includes open-source components. This makes it clear that even without a cybersecurity-specific formalization of cybersecurity responsibilities, as provided for in the CIA of ISO/SAE 21434, manufacturers must take organizational and technical measures to keep their supply chain under control in terms of cybersecurity.

A particular sticking point in the context of the CRA is the handling of suppliers from non-EU countries. Although these are not formally subject to the requirements of the CRA, the European distributor remains fully responsible for the cybersecurity compliance of the overall product.

Companies must therefore ensure that components from third countries also comply with EU requirements – for example, through contractual agreements, technical evidence, or additional security checks. (In the light of geopolitical shifts, new developments are always conceivable here, like the recent US ban on specific automotive components from China and Russia)

In summary: With its requirements for due diligence, the Software Bill of Materials, and technical documentation, the CRA makes it clear that manufacturers are fully responsible here, even when using third-party components; at the same time, formalization is largely dispensed with here.

Clause 8 Continual Cybersecurity Activities – Obligation to provide cybersecurity support over many years, reporting requirements, and more (the core of the CRA!)

Cybersecurity requirements do not end with the delivery of a product: Both ISO/SAE 21434 and CRA require manufacturers to remain active even after series production has started, particularly with regard to (new) vulnerabilities and security incidents.

ISO/SAE 21434 requires that cybersecurity-specific monitoring be established as soon as a product is in the field. The standard even describes a multi-stage procedure that precisely defines how security-related information must be handled – from gathering and assessing criticality to classifying it as a vulnerability or even an incident.

Manufacturers and suppliers must therefore create processes to continuously analyze and evaluate potential risks during the operational phase (this is where the CIA also comes into play!).

The CRA goes even further here. With regard to the need to monitor cybersecurity even after the product has been placed on the market, the CRA sets binding requirements: According to Article 13, paragraph 8, manufacturers must ensure that vulnerabilities – including those in integrated components – are addressed and dealt with during the expected product lifetime and the promised support period.

The CRA Regulation also specifies that this period must be based on the typical use of the product, taking into account user expectations, product type, and intended purpose. In addition, manufacturers must provide cybersecurity-specific support for at least five years (!).

This can be seen as an extension or clarification introduced by the CRA: While ISO/SAE 21434 does not specify a fixed time period for support (it merely requires a “Communication of End of Cybersecurity Support”), the CRA sets clear minimum requirements here. For manufacturers, this means that responsibility beyond the SOP is specified in much more concrete terms.

The reporting obligation in the event of an exploited vulnerability, as described in Article 14, is also particularly relevant. Such an obligation does not exist in ISO/SAE 21434, which merely recommends structured vulnerability management.

The CRA, on the other hand, requires manufacturers to issue an initial report within 24 hours of becoming aware of active exploitation. Information on planned or initiated corrective measures must follow within a further 72 hours (see Article 14). A comprehensive final report must be prepared within 14 days at the latest, containing details of the vulnerability, its severity, and the measures implemented.

In the automotive sector, this obligation is not new: UN R155 imposes similar requirements on vehicle manufacturers/OEMs.

However, the CRA extends these obligations to a much broader range of products – and thus also affects countless suppliers and component manufacturers who were not previously subject to such reporting requirements.

In summary: Ongoing vulnerability handling, reporting obligations, and the cybersecurity support period (and update provision) are defined more precisely in the CRA than in ISO/SAE 21434. The work product artifacts and the procedural structure of the standard are only part of the far-reaching obligations that many players are likely to be confronted with for the first time.

Clause 9 Product development according to ISO/SAE 21434 (with Item Definition and others) vs. CRA requirements

From a product development perspective, ISO/SAE 21434 begins with the Item Definition. The aim of this work product is to create a complete understanding and clear scope of the system under consideration – as a basis for all subsequent steps, such as the cybersecurity-specific risk assessment.The Item Definition typically describes the system, including its interfaces, functions, dependencies, and the components used, if these are already known.

The CRA, on the other hand, does not require an explicit document describing the planned system or product.

Nevertheless, in the course of the CRA’s explicit obligation to perform a cybersecurity risk assessment (see Article 13), manufacturers must provide various information about the product, for example, its intended purpose, the conditions of use, and the operating environment.

This means that the CRA only indirectly requires a documented understanding of the system and does not explicitly state this as a formal requirement.

The cyber risk assessment of ISO/SAE 21434, the so-called Threat Analysis and Risk Assessment (TARA) methodology, defines specific Cybersecurity Goals that can be understood as protection objectives or cybersecurity requirements at a high level of abstraction. These goals describe the technical risks of the product, from which concrete measures are derived.

The CRA does not define the approach to cybersecurity risk assessment in such a structured manner here.

One of the most important key statements on this can be found in Article 13, paragraph 1:

When placing a product with digital elements on the market, manufacturers shall ensure that it has been designed, developed, and proeduced in accordance with the essential cybersecurity requirements set out in Annex I, Part I.

A closer look at Annex I, “Essential Cybersecurity Requirements,” already makes it clear that it indirectly assumes that security objectives are known and incorporated into product development. However, the CRA does not explicitly require such objectives to be formally defined (for example, as part of a Cybersecurity Concept), as is the case in the ISO/SAE 21434 standard.

ISO/SAE 21434 then goes on to define technical and organizational measures within the framework of the Cybersecurity Concept that contribute to the achievement of the previously set objectives. This concept development represents a methodologically comprehensible bridge between analysis and implementation.

At this point, the CRA becomes more specific. Annex I already lists a number of basic cybersecurity requirements, including, for example, appropriate control mechanisms to protect against unauthorized access, ensuring the confidentiality and integrity of data, and measures to reduce the attack surface.

In summary: ISO/SAE 21434 provides a structured approach for deriving and documenting security measures in the Concept Phase. The CRA requires comparable content, but leaves the implementation or development process undefined.

Clauses 10 and 11 Implementation of cybersecurity and verification – The approach of ISO/SAE 21434 and the open approach of the CRA

In vehicle development and the automotive industry, there has always been an intense debate about whether the ISO/SAE 21434:2021 standard is too abstract. It hardly ever describes “what” needs to be done, but primarily provides requirements for “how” something should be done.

(Based on the procedures, methodologies, activities, work products, etc. outlined.)

This becomes particularly clear in the product development phase, where clauses 10 and 11 of the standard specify how cybersecurity should be properly implemented within product development. ISO/SAE 21434 follows the classic approach of systems engineering. Concrete cybersecurity requirements are derived from the Cybersecurity Concept. These are integrated into the system architecture and then implemented.

After implementation, verification takes place to ensure that the measures (the cybersecurity controls) are working correctly and without errors.

To this end, the standard requires consistent consideration and consistency in the process, i.e., complete traceability between requirements, architecture, and testing. In addition, the principle of traceability and transparency applies: All steps and results must be clearly documented, and open issues must always be resolved.

The Cyber Resilience Act takes a completely different view: Although manufacturers are obliged to implement certain cybersecurity requirements (see previous explanations), the CRA does not specify how these are to be methodically derived, specified, and documented in terms of processes.

In concrete terms, this means that cybersecurity and closed vulnerabilities that have been identified, recognized, and reduced through risk analyses must be included in the product. However, the CRA does not define prescribed procedures and standard methodologies for this.

The situation is similar with regard to the distinction between Clause 11 Cybersecurity Validation and the CRA.

ISO/SAE 21434 requires a separate step that goes beyond simply processing the specifications and verifies the effectiveness of the implemented cybersecurity in a real-world context (i.e., whether the predefined cybersecurity objectives and requirements are actually being achieved).

The CRA, on the other hand, does not require a specific validation process, but focuses on formal compliance with the requirements. In the course of the technical documentation required for CE marking, it is therefore necessary to demonstrate, in addition to the risk assessment with reports, that the product’s conformity with the essential cybersecurity requirements (see Annex I) has been verified. However, the CRA does not specify a more detailed methodological approach for these tests or specific test methods.

Clauses 12 to 14 Cybersecurity in production, delivery, operation, and decommissioning — What do ISO/SAE 21434 and CRA say?

The product is now finally in production (Start of Production, SOP for short) and is ready for use — we are now in the so-called post-development phase. In recent years, the topic of cybersecurity has caused a huge rethink in this process. Whereas the focus used to be primarily on development work, today the downstream phases are given equally high priority.

ISO/SAE 21434 specifies the procedural requirements that are intended to ensure that cybersecurity mechanisms are in place and risks are consistently reduced during these phases, for example through measures to protect production. (See also Cybersecurity in vehicle production)

The CRA also addresses the production phase: Article 1 specifies that cybersecurity requirements also apply to the manufacturing phase. It is particularly important to note that the aforementioned assessment of cybersecurity risks for your products not only forms the basis for the requirements already outlined in the planning, design, and development phases of the product, but also for the manufacturing, delivery, and maintenance phases.

Throughout this entire period, it is important to minimize cybersecurity risks and prevent security incidents as far as possible.

ISO/SAE 21434 and CRA are similar with regard to vulnerabilities occurring in the field. Both formulate this rather vaguely by requiring incident response management, but without specifying concrete process requirements.

It is important that the end date of the support period (during which product vulnerabilities are addressed in accordance with the basic cybersecurity requirements) specified in the CRA is clearly and comprehensibly stated by manufacturers in terms of month and year, as provided for in ISO/SAE 21434 in Clause 14 in specific customer communications.

Clause 15: Comparison of the Threat Analysis and Risk Assessment Method and the CRA Risk Assessment

The core of the ISO/SAE 21434 standard is the methodology for identifying and assessing cyber risks, known as Threat Analysis and Risk Assessment (TARA). In the First Edition of the standard (2021), this method was moved to the end and can now be found in Clause 15.

In the field of vehicle development, the steps required in this methodical, structured approach are well known:

• Definition of assets (e.g., systems, components, data, interfaces)
• Identification of potential threats to these assets
• Determination of relevant vulnerabilities and attack vectors
• Derivation of possible damage scenarios and their effects
• Assessment of threat scenarios in terms of probability of occurrence and severity
• Determination of the risk level for each scenario
• Derivation of cybersecurity objectives and requirements for risk mitigation

A direct comparison of the TARA methodology according to ISO/SAE 21434 with the CRA’s risk assessment requirements shows that the standard focuses on the methodological steps, while the CRA specifies the minimum objectives and requirements for the product. The CRA does not prescribe the choice of formal methodology.

The aspects to be included in the assessment of cybersecurity risks throughout the product’s lifecycle and taking into account the basic cybersecurity requirements (see Annex 1) are specified:

• Intended use,
• Foreseeable use,
• Operating environment,
• Assets

It should be noted that, in case of doubt, the CRA requires justification as to why certain requirements from Annex I are not applicable.

Both TARA and CRA risk assessment require a risk assessment of the entire product lifecycle or support period. Accordingly, documentation (and, if necessary, updating) is required for both.

The CRA specifies this point in more detail (see Article 13, paragraph 4): The assessment of cybersecurity risks must be included in the technical documentation.

Depending on the organization, product, and development processes, the question may arise as to the extent to which the TARA methodology can be used to meet the CRA requirements in terms of content.

Due to its structure, a correctly implemented TARA not only meets the requirements of cyber risk assessment as formulated by the CRA, but also provides the necessary traceability and documentation. It is therefore a suitable procedure for meeting the CRA’s requirements with regard to risk assessment. However, organizations must also ensure that it is integrated into the required technical documentation in an appropriate manner.

In a nutshell: Looking at the CRA from the perspective of ISO/SAE 21434

The good news is that organizations and development projects that follow ISO/SAE 21434 can remain committed to this pacemaker for proper cybersecurity engineering throughout the product lifecycle, on a project-specific and evidence-based basis.

Ultimately, the Cyber Resilience Act supplements the legally binding market access within the European Union. Or to put it briefly: ISO/SAE 21434 defines how to develop in compliance with cybersecurity, while the CRA specifies what must be verifiable when placing products on the market in the European Union.

Based on the above, an initial overview of areas for action that need to be addressed in detail can be compiled:

• Mapping of work products: Compare ISO/SAE 21434 artifacts with the specific requirements of the CRA (see appendices).
• Prepare previous elaborations for the required content of the technical documentation (see Appendix VII).
• Examine the obligations that manufacturers must fulfill in order to obtain CRA compliance (appropriate conformity assessment).
• Integration of evidence obligations and timings into existing development and project plans.
• Review and realign procedures in the vulnerability management (CVD) and incident response management (PSIRT) processes.
• Coordinate operational obligations in reporting systems in line with CRA requirements.
• And other aspects (such as Software Bill of Materials processes, supplier integration, defining support periods, etc.).