At first glance, the Cyber Resilience Act (CRA) and the NIS2 Directive might seem to cover similar ground. Both are powerful EU laws designed to bolster cybersecurity, but they approach the problem from fundamentally different directions. Understanding their distinct scopes is essential for any business operating in or selling to the EU.
The core difference boils down to what each piece of legislation protects. NIS2 is about securing the operational continuity of essential services—think energy grids, banks, and digital infrastructure. The CRA, however, focuses on securing the digital products themselves, like software and connected devices.
Untangling EU Cybersecurity: The CRA vs. NIS2
While both the CRA and NIS2 aim for a more secure digital Europe, they don’t overlap as much as you might think. They are complementary, tackling cybersecurity from opposite ends of the spectrum: one focuses on the organisations providing critical services, the other on the manufacturers building the products those organisations use.
The NIS2 Directive: Securing Critical Service Operations
The NIS2 Directive is all about the resilience of organisations that are vital to our economy and society. It imposes strict security and reporting obligations on entities in sectors like healthcare, transport, and finance to ensure they can withstand and recover from cyber incidents.
For example, a large Spanish hospital is designated an ‘Essential’ entity under NIS2. This means its management team is legally responsible for implementing risk management measures like multi-factor authentication, training staff on phishing, and reporting significant service disruptions (like a ransomware attack taking its patient system offline) to national authorities. NIS2 is concerned with how the hospital operates securely day-to-day.
The Cyber Resilience Act (CRA): Securing Products by Design
In contrast, the Cyber Resilience Act (CRA) is a regulation targeting the security of “products with digital elements.” This covers a huge range of tangible and intangible goods, from smart home devices and industrial controllers to standalone software. If you manufacture, import, or distribute a connected product for the EU market, the CRA applies to you.
To understand how it works in practice, let’s go back to that Spanish hospital. The manufacturer of a networked medical imaging machine used by the hospital must comply with the CRA. This means designing the machine to be secure from the ground up (e.g., no default passwords), providing security updates for its entire lifecycle, and reporting actively exploited vulnerabilities within 24 hours. The CRA is about ensuring the product itself is secure by design and remains so over time. For more background, you can learn about the Cyber Resilience Act in our detailed guide.
The core distinction is clear: NIS2 compels service providers to maintain robust cyber defences for their operations, while the CRA forces product manufacturers to build and maintain secure products throughout their lifecycle.
Core Differences Between CRA and NIS2 at a Glance
This table offers a high-level summary of the key distinctions between the two frameworks, highlighting their different targets, objectives, and scope.
| Aspect | NIS2 Directive | Cyber Resilience Act (CRA) |
|---|---|---|
| Primary Target | Providers of essential and important services (e.g., hospitals, banks, cloud providers). | Manufacturers, importers, and distributors of products with digital elements. |
| Main Focus | Operational resilience and incident response for critical services. | Product security throughout its entire lifecycle (secure-by-design). |
| Scope | Applies to specific sectors and entities meeting size-cap rules (e.g., >50 employees). | Applies to almost all digital products sold in the EU, regardless of company size. |
| Example | A regional power grid operator securing its control systems from outages. | The company that builds the software and hardware for that power grid’s control systems. |
Ultimately, an organisation might fall under both. A cloud provider, for instance, is an ‘Important’ entity under NIS2 and must secure its operations. If it also develops software that customers install (like a desktop sync client), that software product would need to comply with the CRA. The two regulations work in tandem to secure both the services we rely on and the products that power them.
Determining Your Scope and Applicability
Figuring out where you stand with the CRA and NIS2 starts with one crucial question: does your organisation make something, or does it do something? This is the fundamental difference in logic between the two frameworks, creating separate paths for product manufacturers and service providers.
This simple decision tree gets right to the point. Are you providing a service in a critical sector, or are you building a digital product for the market?
As you can see, NIS2 targets the operators of essential and important services. The CRA, on the other hand, zeroes in on the manufacturers of the very products those operators might be using.
How NIS2 Defines Its Scope
The NIS2 Directive identifies entities based on two straightforward criteria: their sector and their size. It lays out explicit lists of 18 sectors, splitting them into ‘Essential’ and ‘Important’ categories.
- Essential Entities: This covers the big ones—organisations in energy, transport, banking, health, and digital infrastructure.
- Important Entities: This category includes other vital sectors like postal services, waste management, and the manufacturing of certain critical goods.
Beyond the sector, NIS2 applies a simple size-cap rule. The directive generally targets medium and large organisations, which means those with over 50 employees or an annual turnover exceeding €10 million. For a practical example, a small, family-owned logistics company with 20 employees would likely be exempt, but a large national postal service falls squarely within the scope as an ‘Important’ entity.
The CRA’s Product-Focused Approach
The Cyber Resilience Act (CRA) comes at this from a completely different angle. It applies horizontally to nearly all ‘products with digital elements’ placed on the EU market. This is a massive net, catching everything from hardware like IoT devices to software like operating systems or mobile apps.
Crucially, the CRA’s applicability has no company size or revenue threshold. A two-person startup in a garage developing a smart thermostat app is just as subject to CRA rules as a multinational corporation building enterprise software. If you make it and sell it in the EU, the CRA applies.
This product-centric versus service-centric divide creates some very clear lines. Take a large German hospital, for instance. It’s an ‘Essential’ entity under NIS2 and is responsible for its own operational cybersecurity. But the manufacturer of the networked infusion pumps that hospital uses? They must comply with the CRA to ensure the pumps themselves are secure by design. You can dig deeper into these specifics by exploring our guide on Cyber Resilience Act applicability.
This distinction is especially sharp in markets like Spain, where regulatory alignment is vital for market access. While NIS2 targets an estimated 1,200 entities in Spain’s key service sectors, the CRA’s universal approach impacts a much broader base. It directly affects the country’s 45,000+ IoT-related enterprises, from multinationals down to the smallest startups, all of which now face immediate product security obligations and must prepare for CE marking requirements by 2027.
Whether your obligations fall under the CRA, NIS2, or both, the first step is always understanding your assets and risks. Using a comprehensive cybersecurity risk assessment checklist is a solid starting point for building out your compliance strategy.
Understanding Your Reporting Obligations and Timelines
When an incident strikes, the clock starts ticking. One of the most significant differences between the CRA and NIS2 is what triggers that clock and how you must respond. These reporting timelines aren’t just procedural details; they define your organisation’s response under pressure and shape your entire incident management strategy.
At a high level, NIS2 is reactive to service disruptions, while the CRA is proactive about product vulnerabilities. For a practical example, think of a major cloud provider, an ‘Essential Entity’ under NIS2, suffering a widespread outage that takes its customers offline. NIS2 gives them 24 hours to submit an ‘early warning’ to their national Computer Security Incident Response Team (CSIRT). This is then followed by a more detailed incident notification within 72 hours.
The CRA’s timeline, however, is triggered by a completely different event.
Different Triggers for the 24-Hour Clock
The CRA’s focus is squarely on product security, specifically when a flaw becomes an active threat. For a manufacturer, the 24-hour reporting duty begins the moment they become aware of an actively exploited vulnerability within their product. This is a critical distinction from NIS2.
Let’s take a practical example. A company manufacturing smart thermostats discovers a flaw in their firmware that attackers are actively using to gain control of devices and join them to a botnet. Under the CRA, they must notify ENISA (the EU Agency for Cybersecurity) and their national CSIRT within 24 hours. The report is about the vulnerability itself, not necessarily any resulting service disruption. We cover this in more detail in our overview of CRA reporting obligations under Article 14.
Key Takeaway: For NIS2, the trigger is a significant incident affecting service continuity. For the CRA, it’s the discovery of an actively exploited vulnerability in a product, demanding rapid, coordinated disclosure to prevent widespread harm.
This difference in triggers really highlights how the two frameworks complement each other. The CRA pushes manufacturers to report and fix exploitable flaws before they can be used to cause the large-scale service disruptions that would then trigger NIS2 reporting.
A Practical Comparison of Reporting Timelines
Getting the reporting timelines right is a common point of confusion, so let’s break down the practical differences. The table below highlights the key differences in what triggers a report, how quickly you must act, and who you need to inform.
CRA vs NIS2 Reporting Requirements At A Glance
| Requirement | NIS2 Directive | Cyber Resilience Act (CRA) |
|---|---|---|
| Primary Trigger | A significant cybersecurity incident causing severe operational disruption. | Discovery of a vulnerability in a product that is being actively exploited. |
| Initial Report | 24-hour “early warning” to the national CSIRT or competent authority. | 24-hour notification to ENISA and the relevant national CSIRT. |
| Follow-Up Report | 72-hour detailed incident notification, with a final report due within one month. | No mandatory 72-hour follow-up report is specified, but ongoing vulnerability handling is required. |
| Recipient | National competent authorities and CSIRTs. | ENISA and national CSIRTs. |
While both mandates have a 24-hour deadline, the substance of the report and the required follow-up steps are quite different. As you work to define your incident response plans, it’s also helpful to be aware of global best practices and specific regional requirements, such as those related to cybersecurity incident reporting obligations.
Ultimately, these distinct triggers and timelines require tailored workflows. A product security team must have a process ready for the CRA’s exploited-vulnerability trigger, which is fundamentally different from the broader service-outage focus of NIS2.
Comparing Compliance Paths and Enforcement Penalties
The path to proving compliance—and the penalties for getting it wrong—is where the CRA and NIS2 diverge most sharply. How you demonstrate your security posture is entirely different under each framework.
NIS2 relies on national oversight of your internal processes. The CRA, on the other hand, uses an established EU-wide product conformity framework. Getting this distinction right is critical.
The NIS2 Path: Proving Internal Resilience
For NIS2, the journey is internal and process-driven. As a directive, it is transposed into national law, meaning each Member State enforces it through its own authorities. Compliance means demonstrating robust internal governance, conducting regular risk assessments, and proving board-level accountability.
Under NIS2, an organisation proves compliance by showing, not just telling. National authorities will conduct audits and demand evidence that your security measures are actually in place and working.
Take a large logistics company in Spain, classified as an ‘Important’ entity. Its compliance path would involve:
- Developing and maintaining a comprehensive risk management policy.
- Conducting annual security audits performed by an independent third party.
- Running mandatory training programmes for all employees on cybersecurity hygiene.
- Demonstrating to national auditors that its board of directors has formally approved and oversees its cybersecurity strategy.
Failure to meet these obligations can bring significant fines from national authorities, reaching up to €10 million or 2% of the company’s total global annual turnover, whichever is higher.
The CRA Path: Proving Product Security via CE Marking
The Cyber Resilience Act, as a regulation, is directly applicable across the entire EU without national transposition. It cleverly piggybacks on the well-established New Legislative Framework (NLF), using the CE marking process as its compliance mechanism. This applies a familiar product-safety process to the world of cybersecurity.
The CRA essentially says, “If your product has a digital element, its cybersecurity is now a matter of public safety, just like its electrical or mechanical safety.” It must earn its CE mark by proving it is cyber-resilient.
For a manufacturer, this creates a clear, product-focused path:
- Conduct a Conformity Assessment: The manufacturer assesses the product against the CRA’s security requirements. For most products, this can be a self-assessment, but higher-risk products demand a third-party notified body.
- Create Technical Documentation: This file must contain everything from the risk assessment and a Software Bill of Materials (SBOM) to evidence of a secure development lifecycle.
- Issue an EU Declaration of Conformity: The manufacturer formally declares that the product meets all CRA requirements.
- Affix the CE Mark: Only then can the product be legally placed on the EU market.
This compliance and enforcement model has huge implications for Spain’s digital product teams. While NIS2 impacts around 8,000 important entities in Spain through nationally transposed laws, the CRA directly hits Spain’s 30,000+ software and firmware makers with its CE marking mandate, completely bypassing company size thresholds.
Enforcement also diverges sharply. CRA violations are policed by Market Surveillance Authorities who can order product recalls and impose EU-wide fines of up to €15 million or 2.5% of global annual turnover—potentially exceeding NIS2 penalties. You can discover more insights about these contrasting frameworks on holmsecurity.com.
For instance, a French company developing a smart home security camera must create a full technical file, prove it has a process to deliver security updates for at least five years, and then affix the CE mark. If a Market Surveillance Authority in Germany later finds the product non-compliant, it can be pulled from shelves across all 27 EU member states.
Navigating the Intersection of CRA and NIS2
Although the Cyber Resilience Act (CRA) and the NIS2 Directive target different things—products versus services—they are not independent. The two frameworks were designed to be complementary, creating a strong, interlocking set of security obligations that reinforce one another across the EU market.
For organisations caught in the middle, understanding this intersection is essential for managing dual obligations and turning complex compliance work into a clear market advantage.
The most important point of overlap is supply chain security. Under NIS2, critical entities have a legal duty to secure their supply chains. The CRA, in turn, provides the very mechanism for them to do just that.
The NIS2 Demand for CRA-Compliant Products
NIS2 forces Essential and Important entities to meticulously vet the security of their suppliers. This single requirement transforms CRA compliance from a manufacturer’s internal problem into a key procurement criterion for a huge market of critical service providers.
Take a practical example: a large Spanish power plant, an ‘Essential’ entity under NIS2, must verify the cybersecurity of its operational technology. When its procurement team needs a new industrial control system (ICS), they won’t just evaluate performance and price; they will demand proof of security.
The manufacturer of that ICS falls directly under the CRA. They are obligated to:
- Build the ICS according to secure-by-design principles.
- Provide a Software Bill of Materials (SBOM) listing all its software components.
- Commit to providing security updates for a defined support period.
- Affix the CE mark as proof of CRA conformity.
This creates an incredibly powerful market dynamic. The power plant will use the manufacturer’s CRA compliance—proven by the CE mark and technical documentation—to fulfil its own NIS2 supply chain security obligations. In practice, NIS2 entities will become major drivers of CRA adoption, creating a strong market preference for CRA-compliant products.
The intersection creates a clear value chain: NIS2 entities must manage supply chain risk, and they will do so by demanding CRA-compliant products. For manufacturers, CRA compliance is no longer just a regulatory hurdle; it’s a market access key.
When One Organisation Has Dual Obligations
Another critical scenario involves organisations that are simultaneously NIS2 entities and CRA manufacturers. This is especially common for digital service providers, particularly Software-as-a-Service (SaaS) companies.
Think about a cloud-based electronic health record (EHR) provider based in Germany. This company is both:
- An ‘Essential’ NIS2 entity because it provides a critical service to the healthcare sector.
- A ‘manufacturer’ under the CRA because it develops and commercialises the EHR software product.
Here, a single security event can trigger obligations under both frameworks. Imagine the company’s security team discovers an unpatched, actively exploited vulnerability in the EHR software’s code that allows unauthorized access to patient data.
- CRA Obligation Triggered: Because the flaw is actively exploited, the provider must notify ENISA within 24 hours, as required by the CRA.
- NIS2 Obligation Triggered: If this same vulnerability causes a data breach or service disruption for its hospital clients, it becomes a ‘significant incident’. This triggers the 24-hour early warning and 72-hour detailed incident report required by NIS2.
This dual-trigger scenario shows why a unified compliance strategy is non-negotiable. For organisations in this position, managing product vulnerabilities and operational incidents are two sides of the same coin. The European Commission has provided guidance on this topic, and you can learn more about how to prepare from our analysis of CRA implementation guidance. Ultimately, successfully navigating these overlapping requirements demands a clear understanding of both your role as a service provider and your responsibilities as a product manufacturer.
Developing a Unified Compliance Strategy
Trying to manage CRA and NIS2 requirements with separate spreadsheets and disconnected processes is a recipe for duplicated work. A unified strategy is the only practical way forward, helping you treat both regulations as a single, interlocking compliance challenge instead of two separate problems.
This approach starts with a clear mapping of your obligations. A guided applicability assessment, for example, can immediately clarify whether the CRA, NIS2, or both apply to your products and your customers, giving you a solid starting point.
From Rules to a Roadmap
Once you’ve established applicability, the next step is translating dense legal text into a concrete plan of action. This means generating a requirements matrix based on your product’s specific classification—whether it falls under the default rules or a higher-risk class. This matrix should map specific obligations from the CRA Annexes and give you actionable templates.
For instance, if you manufacture a smart home router, a unified platform can generate a checklist covering:
- Annex I Security Requirements: Specific secure-by-design principles you must implement, like ensuring encrypted communication and having a secure update mechanism.
- Vulnerability Handling Processes: Templates for documenting how you will manage and report discovered vulnerabilities.
- Technical Documentation: A structured outline for your EU Declaration of Conformity and the supporting evidence files.
This turns vague regulations into a concrete roadmap for achieving compliance by the 2026–2027 deadlines.
By centralising documentation, managing vulnerability disclosures, and tracking supplier compliance in one place, you can build a single, efficient programme that satisfies both product and service security demands, ensuring you can confidently serve the EU market.
An Integrated Compliance Example
Consider a SaaS company that provides logistics software to large shipping companies. This company faces dual obligations:
- As a NIS2 ‘Important’ entity: It must secure its own operations and service delivery.
- As a CRA ‘manufacturer’: Its software product must meet CRA’s security-by-design and lifecycle requirements.
Instead of running two parallel compliance projects, a unified approach allows them to use the same evidence for both. The secure software development lifecycle (SSDLC) process documented for CRA compliance also serves as proof of a key risk management measure required under NIS2.
Likewise, the vulnerability disclosure process mandated by the CRA becomes a core component of their NIS2 incident response plan. When a single platform like Regulus manages both the product-level requirements (CRA) and the operational security evidence (for their NIS2 customers), the company avoids duplicating effort. This not only reduces costs but also builds a more robust and defensible security posture across the board. The key is to see the CRA vs NIS2 differences not as a conflict, but as an opportunity for integrated efficiency.
Frequently Asked Questions About CRA and NIS2
The relationship between the Cyber Resilience Act and the NIS2 Directive often creates confusion, especially where their obligations seem to overlap. Here are some straightforward answers to the most common questions we hear from manufacturers and digital service providers.
If My Product Is CRA Compliant, Do I Still Need to Worry About NIS2?
Yes, absolutely. Think of it this way: CRA compliance is about the security of your product. NIS2 is about the operational security of the entity using it.
For a practical example, if you sell your CRA-compliant product to a hospital (an ‘Essential’ entity under NIS2), they have their own separate obligations. Specifically, they must manage their supply chain risks. Your CRA compliance—proven by your CE mark and technical documentation—becomes a critical piece of evidence they will need from you to meet their regulatory requirements. Your job is to provide the secure product; their job is to use it securely as part of their broader operations.
Can I Be Fined Under Both CRA and NIS2 for the Same Event?
It is possible, particularly if you are a dual-status organization. Imagine you’re a SaaS provider for the banking sector. A severe security flaw in your software would be a clear CRA violation. If that flaw leads to a major service disruption that prevents customers from accessing their accounts, that disruption could be classed as an NIS2 incident.
Because the two regulations address different failures—the insecure product (CRA) and the disrupted service (NIS2)—you could theoretically face penalties under both for a single root cause.
Which Regulation Has Stricter Penalties?
On paper, the CRA has higher maximum financial penalties. Fines can reach up to €15 million or 2.5% of global annual turnover, whichever is greater.
NIS2 penalties are capped slightly lower, at €10 million or 2% of turnover. However, focusing only on the numbers is a mistake. Both regulations grant authorities serious enforcement powers, from ordering product recalls (CRA) to issuing legally binding instructions (NIS2).
Key Takeaway: While the CRA’s fines are nominally higher, the enforcement powers under both regulations are severe and designed to compel compliance. The biggest risk isn’t just the fine; it’s the operational chaos from a product recall or a binding order from a supervisory authority.
What Is the Most Significant Difference for a Product Manufacturer?
For a product manufacturer, the biggest difference lies in the compliance mechanism itself. The CRA mandates compliance through the EU’s established CE marking framework. This means you must conduct a conformity assessment, compile a comprehensive technical file with a Software Bill of Materials (SBOM), and physically affix the CE mark to your product before it can be legally sold in the EU.
NIS2, on the other hand, is primarily about internal processes, risk management, and governance. These obligations fall mainly on your customers (the service providers), not directly on you as the manufacturer, though they will push those requirements down to you via their procurement process.
Navigating CRA and NIS2 requires a clear, actionable plan. Regulus provides a guided platform to assess your applicability, map requirements, and generate the evidence needed for CRA compliance. Gain clarity on your obligations and build your roadmap today.
