Cyber Resilience Act vs NIS2

The Core Difference Is Product Regulation vs Entity Cybersecurity

The clearest way to separate the two frameworks is to identify what each one regulates. The Cyber Resilience Act establishes cybersecurity requirements for products with digital elements and assigns duties to manufacturers and other economic operators involved in placing or making those products available on the Union market. NIS2 focuses on the cybersecurity of covered organisations and the network and information systems used for their operations or services. It requires essential and important entities to manage cybersecurity risks and meet incident-reporting obligations. A secure software product can therefore be relevant to CRA compliance while the organisation using that software can separately have NIS2 duties. The laws operate at related but different regulatory layers.

• CRA: product and economic-operator layer.
• NIS2: covered entity and operational cybersecurity layer.
• The same company can have obligations under both.
• Compliance with one framework does not automatically satisfy the other.

CRA Scope Starts With the Product and Market Route

A CRA analysis generally begins with the product with digital elements, its intended or reasonably foreseeable use, its connection to a device or network and the way it is made available on the Union market. The manufacturer's role is central because Article 13 contains the main product obligations. Importers and distributors also have role-specific responsibilities. Product classification can influence conformity assessment, while Annex I provides essential cybersecurity and vulnerability-handling requirements. This product-market structure explains why CRA compliance work is closely connected to engineering, release management, product documentation, support periods and conformity evidence. Whether the customer belongs to a critical sector can be relevant commercially or to risk analysis, but it is not a substitute for determining the CRA scope of the product itself.

NIS2 Scope Starts With the Entity, Sector and Activity

NIS2 uses a different starting point. It establishes requirements for essential and important entities in covered sectors and activities, subject to the Directive's scope rules and national implementation. The framework covers areas such as energy, transport, health, digital infrastructure, public electronic communications, certain digital services, manufacturing categories and other sectors identified in the Directive. Size and specific statutory rules can affect whether an entity is covered. The resulting duties concern the organisation's cybersecurity risk management, governance, operational resilience, incident handling and reporting. A business therefore cannot determine its NIS2 position simply by asking whether it sells a digital product. The analysis concerns the entity, its activities, sector, size, services and applicable national implementation.

• Identify the entity and its relevant activities.
• Check the applicable NIS2 sector and scope rules.
• Consider size and special inclusion rules.
• Review the Member State implementation that applies to the entity.

The Security Requirements Operate at Different Levels

CRA and NIS2 both address cybersecurity risk, but the control objectives attach to different subjects. CRA requires the manufacturer to address the cybersecurity of the product, including secure design, vulnerability handling, security updates and supporting evidence. NIS2 Article 21 requires covered entities to take appropriate and proportionate technical, operational and organisational measures to manage risks to the security of the network and information systems used for operations or services. NIS2 includes subjects such as incident handling, business continuity, supply-chain security, vulnerability handling, security in acquisition and development, cyber hygiene, access control and cryptography. A product manufacturer's CRA security controls can therefore support a customer's NIS2 supply-chain objectives without replacing the customer's wider organisational duties.

• CRA asks whether the covered product meets product cybersecurity requirements.
• NIS2 asks whether the covered entity manages cybersecurity risks appropriately.
• NIS2 reaches governance and operational resilience beyond individual products.
• CRA can improve the security baseline of technology used by NIS2 entities.

Supply-Chain Security Connects the Two Frameworks

Supply-chain cybersecurity is one of the clearest operational links between CRA and NIS2. NIS2 requires covered entities to address supply-chain security as part of cybersecurity risk management. The CRA raises the cybersecurity baseline for covered digital products by placing direct product-security duties on manufacturers. The CRA itself recognises this relationship and notes that secure products can facilitate compliance by digital infrastructure providers and other NIS2 entities with supply-chain requirements. Procurement teams can therefore use CRA evidence as one input when assessing technology suppliers. They should not, however, reduce NIS2 supplier assurance to a question of whether a product carries a CE marking. NIS2 supply-chain analysis can include broader supplier, service, dependency and organisational risks that sit outside product conformity.

• CRA product evidence can support supplier assurance.
• NIS2 supply-chain duties are broader than product conformity.
• Procurement should connect product and supplier risk information.
• Critical dependencies can require additional security analysis.

Both Frameworks Have Reporting Duties, but the Triggers Differ

The existence of 24-hour and 72-hour stages in both regimes can make the reporting frameworks look interchangeable, but the triggers and regulated persons are different. CRA Article 14 requires manufacturers to report specified actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. NIS2 Article 23 requires covered essential and important entities to report incidents that have a significant impact on the provision of their services. A product vulnerability can therefore raise a CRA question for the manufacturer while a resulting operational disruption can separately raise a NIS2 question for a customer or another covered entity. Compliance teams should maintain a regulatory reporting matrix rather than assume that submitting one report automatically satisfies every applicable EU reporting duty.

• CRA reporting focuses on specified product-security events.
• NIS2 reporting focuses on significant incidents affecting covered services.
• Different legal entities can have reporting duties arising from the same event.
• Reporting routes and competent authorities should be mapped separately.

CRA Is a Regulation, While NIS2 Is a Directive

The legal form is another practical distinction. The CRA is an EU Regulation and establishes directly applicable rules according to its application timetable. NIS2 is a Directive and requires Member States to implement its requirements through national law. Organisations operating in multiple Member States can therefore need to examine national NIS2 legislation, competent authorities and procedures in addition to the EU Directive itself. CRA compliance also interacts with national authorities through market surveillance and other implementation structures, but the underlying product requirements come from the Regulation. For multi-country compliance programmes, this means a central CRA product framework and national NIS2 implementation analysis may need to coexist rather than be maintained as a single legal checklist.

• CRA is Regulation (EU) 2024/2847.
• NIS2 is Directive (EU) 2022/2555.
• NIS2 implementation depends on Member State law.
• Cross-border organisations should map applicable national NIS2 regimes.

A Company Can Be Subject to Both CRA and NIS2

The frameworks are complementary rather than mutually exclusive. A technology company can manufacture products with digital elements and therefore have CRA obligations while also qualifying as an essential or important entity under NIS2 because of the services or sector in which it operates. A NIS2 entity can also purchase and depend on CRA-regulated products from other manufacturers. The practical response is to map obligations by regulatory role. Product engineering and product-security evidence can support CRA work, while enterprise security, governance, continuity and service-level incident response can support NIS2 work. Shared processes such as vulnerability management, supplier assurance and incident response can serve both programmes, but each process should identify the distinct legal trigger, scope, reporting route and evidence requirement that applies.

• Map CRA economic-operator roles.
• Map NIS2 entity status separately.
• Reuse operational controls where appropriate.
• Keep the legal evidence and reporting triggers distinct.