Those who have started working on the CRA have brought a precise object into focus: the product. Essential requirements, vulnerability handling, SBOM, support period. Everything revolves around the device you place on the market. But there is a second rule that looks at a different object, your company, and for a good share of device manufacturers it applies in parallel with the CRA: NIS2. They are two distinct obligations, with different recipients and channels, and those who have only the first in mind notice the second late.
The CRA (Regulation (EU) 2024/2847) is a product-security law. NIS2 (Directive (EU) 2022/2555, transposed in Italy by Legislative Decree 138/2024) is a law on the security of the organisation’s systems. They are not two versions of the same thing: the complete picture, with object, legal form and addressees compared, is in the guide NIS2, DORA and the CRA compared. Here I start from a single question: if you make devices and you are already inside the CRA, does NIS2 concern you as a company too?
When NIS2 concerns you as a company
For many device manufacturers the answer is yes, and the reason lies in two combined criteria set out in Art. 3 of NIS2: the sector and the size.
On the sector: Annex II of NIS2 includes manufacturing, and among the branches it lists the manufacture of medical devices, of computer, electronic and optical products, of electrical equipment, of machinery and equipment. Those who build controllers, sensors, gateways, panels, connected machines most likely fall within one of these branches.
On size: the reference threshold is that of the medium-sized enterprise, from 50 employees or more than EUR 10 million in turnover or balance-sheet total (Recommendation 2003/361/EC). A manufacturer in those sectors that exceeds the threshold generally falls among the “important entities”.
In concrete terms: the very product that makes you subject to the CRA as a manufacturer can make your company a NIS2 entity as a manufacturing business in an Annex II sector. They are two qualifications that arise from two different criteria, the product for the CRA, the sector plus the size for NIS2, and it is not a given that whoever is on top of the first has noticed the second.
What NIS2 asks, and how much you have already done
NIS2 does not ask for documentation on the product. It asks for risk-management measures borne by the company, listed in Art. 21(2): from risk-analysis policies to incident handling, from business continuity to supply-chain security, from cyber hygiene to access control.
Two of these measures touch exactly the work the CRA already imposes on you for the product:
- supply-chain security, including the aspects relating to the relationships with direct suppliers (Art. 21(2)(d));
- security in the acquisition, development and maintenance of systems, including vulnerability handling and disclosure (Art. 21(2)(e)).
These are the same processes the CRA asks for the product: the secure development lifecycle, the SBOM (Software Bill of Materials, the inventory of software components), coordinated vulnerability handling (Annex I, Part II, of the CRA). The framework you build to CE-mark produces evidence that is also usable for Art. 21 of NIS2. Those who own these processes and can generate documented evidence of them find part of the NIS2 work already in hand.
What the CRA does not cover, and NIS2 adds, is everything that concerns the company and not the product: business continuity and recovery (point c), cyber hygiene and staff training (point g), access control and management of internal assets (point i), multi-factor authentication on your systems (point j). These are the systems with which you design, produce and run the company, not the ones you sell. The CRA does not touch them.
Two notifications for two different objects
The point where the two obligations do not merge, and where getting it wrong costs, is the notification.
The CRA requires notifying actively exploited vulnerabilities and severe incidents affecting the security of the product, to the coordinating CSIRT and to ENISA, with an early warning within 24 hours (Art. 14). NIS2 requires the entity to notify significant incidents affecting the delivery of its services, to the national CSIRT, also with an early warning within 24 hours and notification within 72 (Art. 23).
Different trigger, partly different recipient. The CRA channel activates on a product problem; the NIS2 channel on an incident that hits the company’s operations. Ransomware that halts your production is a NIS2 case, not a CRA one. A vulnerability exploited in the firmware you shipped to customers is a CRA case. An incident can, in theory, trigger both. The deadlines and the workings of the CRA channel are in the guide to the Single Reporting Platform; when a report becomes a notification, in From report to notification.
Operational note (my reading, not the text of the law). The efficient thing is a single internal process for incident and vulnerability handling, with a branch that knows when to route to the CRA channel (product problem) and when to the NIS2 channel (company service). One team, two destinations. Keeping the two processes separate leads to duplicating the work and, worse, to missing one of the two clocks when the event triggers them both.
And DORA?
DORA (Regulation (EU) 2022/2554) almost never concerns you as a direct addressee: it applies to financial entities, not to a device manufacturer. It reaches you if you sell to the financial sector, and by way of contract: the bank or insurance customer must pass on to you, by contract, the requirements of Chapter V of DORA (Art. 30). Here CRA compliance plays in your favour, as a base for passing the customer’s due diligence. It is a chapter of its own, which I cover in a dedicated article.
One system, two maps to keep distinct
The way I advise manufacturers to look at it is this: a single security-management system, which generates reusable evidence on several fronts. The secure development lifecycle and the vulnerability handling you build for the CRA cover part of Art. 21 of NIS2; the documented evidence you keep for market surveillance also serves towards the NIS2 authority.
What does not unify, and must be kept explicit, are two maps. The map of the obligations: the CRA ends at the product, NIS2 reaches your internal systems, and the company side is not covered by any work done on the device. And the map of notifications and authorities: different channels, different triggers, partly different recipients. The first concrete step is to check whether your company exceeds the NIS2 threshold in its Annex II branch. If the answer is yes, the CRA is half the work, not all of it.
References: Regulation (EU) 2024/2847 (CRA), Articles 3 and 14 and Annex I, Part II; Directive (EU) 2022/2555 (NIS2), Articles 3, 21 and 23 and Annex II; Legislative Decree No 138 of 4 September 2024; Regulation (EU) 2022/2554 (DORA), Articles 2 and 30; Recommendation 2003/361/EC. The notes flagged as operational are my interpretations, not regulatory text. Article numbers verified against the official texts.