NIS2 and the Cyber Resilience Act: What They Mean for Automotive Cybersecurity and What Mobility Stakeholders Need to Know Today

Anyone responsible for cybersecurity in vehicle development or the automotive industry has likely spent the past few years building ISO/SAE 21434 processes and structuring UN R155 type approval documentation. The persistent feeling: just as one regulatory framework reaches some level of stability, the next one arrives. (Most recently, with growing attention to global UN R155 equivalents)

Running parallel to this, the industry has long dealt with TISAX, though on a different level: information security at the organizational and site level, and therefore always slightly removed from the focus of vehicle development and engineering.

With NIS2 and the Cyber Resilience Act (CRA), many in the industry perceive yet another wave arriving: more compliance effort hitting the same teams and the same budgets.

That perception is understandable. It is also imprecise.

That imprecision can have far-reaching consequences. It is therefore useful for those working across the many disciplines of vehicle development and security to have a clear picture of what NIS2 and the CRA actually require, how they relate to the familiar automotive frameworks, and what the practical implications are for automotive organizations.

An important note for engineers: NIS2 and the CRA are structurally different from anything automotive cybersecurity teams have worked with before. They are not product development or engineering standards. They are public law instruments, with government authorities, board-level liability, fines, and defined reporting chains.

That comes with a different level of abstraction. While familiar automotive frameworks specify requirements in relatively concrete terms (even if that still leaves considerable room for interpretation), NIS2 and the CRA operate at a much higher level and often describe only which topic a manufacturer must address, not how. Think: “the manufacturer shall exercise due diligence.” (The Essential Requirements in Annex I of the CRA are an exception to this pattern.)

Add to this the language itself: unlike ISO standards and UN regulations, NIS2 and the CRA are written to be legally defensible. Engineers encountering them for the first time will find a writing style that is quite unfamiliar.

All of this changes who is responsible inside an organization, what documentation is required, and what the consequences of non-compliance look like.

Three Frameworks, Three Layers: What ISO/SAE 21434, UN R155, and TISAX Are Designed to Do

A brief mapping of the familiar frameworks is helpful before adding NIS2 and the CRA to the picture.

• ISO/SAE 21434:2021 is the leading international industry standard for developing cybersecure products in the automotive sector. It describes how cybersecurity risk management is structured throughout the development of vehicle electrical and electronic systems across the full lifecycle, and how cybersecurity is to be integrated into projects and organizations. The core methodology is Threat Analysis and Risk Assessment (TARA). The standard is addressed directly at development teams at OEMs and suppliers in the vehicle and automotive industry. There are no reporting obligations or regulatory oversight. Obligations arise primarily from customer requirements and, where applicable, from liability questions when work does not reflect the state of the art.
• UN Regulation No 155 is a type approval regulation that applies exclusively to vehicle manufacturers, not to component or subsystem suppliers. It requires a demonstrably functioning Cybersecurity Management System (CSMS) and its application across vehicle types as a precondition for type approval. The relevant counterparties are approval authorities and technical services.
• TISAX is the established industry assessment mechanism for information security at the organizational and site level. It is based on the VDA ISA, is conceptually close to ISO/IEC 27001, and extends it to include prototype protection. TISAX produces recognized assessment results but no public law reporting obligations. For European manufacturers, TISAX is today a baseline requirement for collaboration.

None of these frameworks, by themselves, generate the organization-wide reporting obligations and board-level liability that come with NIS2, or the CE-backed product and post-market obligations of the CRA.

What NIS2 Is Primarily About: Public Law IT Resilience at the Organizational Level

NIS2 is fundamentally an organization-focused regulation. It requires entities in certain sectors to implement cybersecurity measures for the resilience of their network and information systems, covering IT, OT, supplier relationships, and service continuity.

For the automotive industry, the scope is relevant: NIS2 covers 18 sectors in total (11 in Annex I as “highly critical sectors,” 7 in Annex II as “other critical sectors”). Automotive is addressed in Annex II, Number 5 (“Manufacturing”), sub-item (e): the manufacture of motor vehicles, trailers, and semi-trailers under NACE Rev. 2 Division 29.

Medium and large companies in these sectors are generally in scope. Since NIS2 is a directive, the specific registration mechanics, competent authorities, and country-specific extensions depend on national implementation. Cross-border legal review remains necessary.

What NIS2 Specifically Requires

NIS2 requires appropriate and proportionate technical, operational, and organizational measures. Article 21(2) of the Directive lists ten core elements: risk analysis and information security policies, incident handling, business continuity, supply chain security, security in acquisition, development, and maintenance (including vulnerability management and disclosure), effectiveness assessment, basic cyber hygiene and training, cryptography, personnel security and access control, and multi-factor authentication and secured communications.

This shifts the compliance discussion away from ECU and item level and upward, toward the resilience of IT, OT, supplier relationships, and service continuity across the entire organization.

Board Responsibility and Sanctions

New for many automotive organizations is the explicit management responsibility. NIS2 requires governing bodies to approve cybersecurity measures, oversee their implementation, and participate in training. Governing bodies can be held personally liable for violations. In practical terms: cybersecurity can no longer be fully delegated downward. Responsibility remains anchored at the leadership level.

Even if this is often dismissed as compliance theory, a look at the fine ceilings is worthwhile (to be understood as minimum values; member states may set higher thresholds in their national implementations):

• Important entities: at least EUR 7 million or 1.4% of global annual turnover, whichever is higher. This is the category that typically applies in automotive, since Annex II entities are automatically classified as “important” under Article 3(2) NIS2.
• Essential entities: at least EUR 10 million or 2% of global annual turnover. This category applies in an automotive context only in specific constellations, for example when a group also operates Annex I entities such as an energy division, qualified trust services, or large cloud services.

Automotive manufacturers and larger suppliers in Annex II sectors are generally classified as important entities. This may create a different sense of urgency than a TISAX audit result or a type approval record. The key difference between NIS2 and UN R155 is worth stating clearly: while UN R155 puts market access on the line, the individuals involved are accountable only to their employer. Under NIS2, they are personally liable.

The NIS2 Reporting Chain

NIS2 establishes a fixed reporting cascade to authorities for significant incidents:

• an early warning within 24 hours,
• an incident notification with initial assessment within 72 hours,
• an interim report on request,
• and a final report within one month.

UN R155 does include a reporting obligation to the approval authority, at least annually “or more frequently if relevant.” In practice, this is generally interpreted as a timely notification obligation in critical incidents (often within 24 hours), not least because failure to do so could call the effectiveness of the CSMS and thus the type approval itself into question.

The difference lies in binding force: NIS2 sets the deadlines directly in the legislative text. UN R155 leaves them to the interpretation between OEM and authority.

TISAX and NIS2: Closer Than Expected, But Not the Same

For teams with TISAX maturity, the relevant nuance is this: TISAX materially covers many NIS2 requirements and in some areas goes beyond them. The ENX opinion from 2025 (“Coverage of NIS2 by TISAX”) confirms this. However, country-specific implementation obligations and national reporting requirements are not covered and must be addressed separately. The conclusion: TISAX is not a NIS2 compliance certificate.

What the Cyber Resilience Act Adds: Product Obligations with CE Marking

The CRA is structured fundamentally differently from NIS2. It regulates products, not organizations. The European Commission describes it as a horizontal framework for products with digital elements placed on the EU market. In scope are, among others, standalone software, separately placed firmware, and hardware components such as integrated circuits and sensors.

The CRA entered into force on December 10, 2024. The reporting obligations under Article 14 apply from September 11, 2026, including for products already placed on the market before December 11, 2027. Full application of the main obligations begins on December 11, 2027.

What the CRA Specifically Requires

Before placing a covered product on the market, the manufacturer must conduct a cybersecurity risk assessment, implement the Essential Cybersecurity Requirements, prepare technical documentation, conduct a conformity assessment, issue an EU Declaration of Conformity, and affix CE marking.

This combination of technical file, declaration, CE marking, and market surveillance has no real equivalent in ISO/SAE 21434, TISAX, or NIS2.

(Although there is already meaningful coverage from ISO/SAE 21434 here, see also the article on a first look at the CRA from a 21434 perspective.)

Post-market obligations apply as well: manufacturers must define and disclose a support period, at minimum five years, unless the expected use period is shorter. Throughout this period, vulnerabilities must be addressed and security updates provided. (Those familiar with proper TARA methodology will recognize the parallel to vulnerability management functions across the product lifecycle – do not miss CYMETRIS)

The CRA Reporting Channel

Manufacturers must actively report exploited vulnerabilities and severe incidents through the single reporting platform operated by ENISA to the CSIRT designated as coordinator in their member state (with ENISA receiving the report in parallel): an early warning within 24 hours, a more complete notification within 72 hours. For actively exploited vulnerabilities, the final report follows no later than 14 days after a fix or risk mitigation measure is available. For severe incidents, it follows within one month of the incident notification.

For an automotive group subject to both NIS2 and CRA obligations, the two reporting chains must be kept clearly distinct:

• NIS2 targets incidents in the entity’s own network and information systems, meaning when the entity’s own service delivery is significantly disrupted (Article 23 NIS2).
• The CRA targets actively exploited vulnerabilities and severe incidents affecting the security of a product the manufacturer has placed on the market (Article 14 CRA).

In practice: a ransomware infection in a plant’s IT network triggers a NIS2 notification but not a CRA notification. An actively exploited vulnerability in a sold workshop tool triggers a CRA notification but not necessarily a NIS2 notification. Only when an event affects both spheres simultaneously, for example a vulnerability in a backend service that the OEM both operates and sells, do both reporting chains apply in parallel.

What the CRA Means for Type-Approved Vehicles

In practice, the CRA is not a second UN R155 for type-approved road vehicles. The European Commission’s CRA Implementation FAQ makes clear: the CRA does not apply to products covered by Regulation (EU) 2019/2144 (the General Safety Regulation, GSR). This covers motor vehicles, trailers, and related systems, components, and separate technical units under the EU type approval framework. In addition, Delegated Regulation (EU) 2025/1535 explicitly excludes certain Category L vehicles from the CRA.

More concretely: automotive and vehicle development organizations already working with UN R155 and ISO/SAE 21434 on a daily basis are exempt from the CRA with respect to their type-approved vehicle products. But not automatically with respect to the rest of their product portfolio.

That said, many people working across automotive and vehicle value chains are reading this for good reason. The greatest CRA impact often lies outside the type-approved vehicle scope: in standalone software, separately placed components, operating systems, chips, mobile apps, workshop tools, and other non-excluded digital products. Automotive-adjacent products outside the (continuously evolving) UN R155 scope can also become subject to the CRA, including e-bikes, pedelecs, e-scooters, quads, and agricultural and forestry machinery.

This is particularly relevant for suppliers currently trying to establish themselves in other industries to reduce their dependence on the struggling automotive sector. Once they place products outside the type approval framework, the CRA applies in full force.

A note on an interpretive gap: for vehicle category O (trailers), a known gray area currently exists. UN R155 includes category O in its scope (provided at least one E/E component is present), but Annex II of the GSR does not explicitly apply the D4 cybersecurity requirement to category O. Product-level legal classification is therefore advisable here.

A Brief Note: The DIN EN 40000 Standard Series on Cybersecurity for Products with Digital Elements

For interpreting the deliberately abstract CRA requirements in Annex I, the horizontal DIN EN 40000 standard series is currently being developed at the European level, comprising four modules: common vocabulary, principles of cyber resilience, vulnerability handling, and generic security requirements.

All four parts are currently available as prEN drafts. The series is intended to serve as a practical guide to CRA compliance, much as ISO/SAE 21434 serves as a guide to UN R155 compliance.

Three Layers, Three Frameworks: Recommendations for a Compliance Architecture

The practical answer to how all relevant frameworks work together is not framework consolidation.

A compliance architecture with clear routing rules per asset, product, site, and service appears to be the right approach, organized across three layers.

• Layer 1: The product development layer. ISO/SAE 21434 and UN R155 remain the home for item definition, TARA, cybersecurity goals, lifecycle work products, CSMS documentation, and interaction with approval authorities. Vehicle and E/E engineering stays anchored here.
• Layer 2: The infrastructure layer. TISAX as the industry assurance baseline for information security, supplemented by NIS2 as a standalone legal layer for board governance, registration obligations, authority interaction, and incident reporting.
• Layer 3: The product market layer. A formal CRA screening gate in the product release process. First question: does an automotive exclusion apply under the EU type approval framework? If yes, the CRA is not relevant. If no, the product needs a full CRA file, including risk assessment, CE marking, defined support period, vulnerability disclosure policy, and reporting obligations.

Two common mistakes that this structure avoids:

1. First, viewing everything through the lens of ISO/SAE 21434 alone. The standard remains central, but it is not the legal home for NIS2 board liability or CRA CE conformity.
2. Second, treating NIS2 or the CRA as a substitute for automotive engineering discipline. The correct framing: 21434 and R155 apply primarily to vehicle engineering (and, broadly speaking, what surrounds it), TISAX to the assurance of infrastructure, NIS2 to organizational resilience, and the CRA to non-excluded market products.

Summary: What This Means in Practice for OEMs, Tier Suppliers, Mobility Stakeholders, and Other Manufacturers and Providers

Take notes. Based on the above:

• OEMs and regulated vehicle manufacturers: The vehicle CSMS, TARA, and type approval documentation remain in the engineering layer. NIS2 sits above this as an organizational layer covering board governance, entity reporting obligations, and the resilience of IT, OT, plants, and backend. On the CRA: do not prematurely classify all vehicle components as CRA-relevant. The right question is whether the specific product is excluded under the EU type approval framework, or whether it constitutes a separately placed product with digital elements.
• Tier suppliers and component manufacturers: Medium and large suppliers may themselves fall under NIS2 as important entities. What matters is not size alone, but the combination of sector classification (Annex II NIS2 covers, among others, the manufacture of computers, electrical equipment, machinery, and vehicles) and the size threshold. Manufacturers of chips, sensors, or control units frequently fall within scope across multiple sector classifications, regardless of whether the end product undergoes type approval. Smaller suppliers will feel NIS2 indirectly through the supply chain requirements of their customers. On the CRA, the decisive question is whether the supplier places a covered product on the market under its own name in the EU. Chips, operating systems, and separately placed software can qualify as standalone products with digital elements, each requiring their own risk assessment, technical file, support period, and reporting channel. Unfamiliar for automotive teams: the CRA treats placing a product on the market under one’s own name as equivalent to manufacturing it (Article 21 CRA). Distributors or resellers who market a product under their own brand or substantially modify it become CRA manufacturers themselves. This differs from the classic type approval model, where cybersecurity responsibility remains with the OEM.
• Software, apps, backend, tooling, and similar products: A mobile app needs a CRA classification decision. A vehicle function needs 21434 and R155 documentation. A plant, SOC, or backend operation needs NIS2 governance and reporting. A blanket “automotive cyber compliance” label is no longer sufficient.

Open Questions as a Starting Point for an Initial Self-Assessment

The regulatory frameworks described here are complex. Not all implications can be fully mapped today, as national NIS2 implementation laws vary and certain CRA interpretation questions in edge cases remain open.

What can already be usefully addressed at this stage is a critical self-assessment:

• Does the organization fall under NIS2, and if so, as an essential or important entity? Has registration in the relevant member state been addressed?
• Is explicit board responsibility under NIS2 reflected in the organization’s governance structure? Or does cybersecurity still sit exclusively with engineering teams?
• Which products in the portfolio could fall under the CRA? Are they also sold to industries outside the automotive value chain? Is there a formal screening gate that distinguishes between type-approved vehicles and separately placed digital products?
• Is a dual reporting chain already in place for when it matters? NIS2 organizational reporting and CRA product reporting. Or is that still to be built?
• Is the compliance architecture structured so that the engineering layer, organizational layer, and product market layer are clearly separated? Or is there an attempt to map everything into a single framework?

In a single sentence: good automotive cybersecurity engineering work remains substantively unchanged. What shifts with NIS2 and the CRA is who inside the organization is responsible, what the consequences of gaps are, and the public law framework within which products must now hold up, in addition to type approval.