NIS2 vs CRA: Why ‘Entity’ and ‘Product’ Obligations Don’t Merge Into One Programme

NIS2 and the CRA are frequently discussed as if they’re the same regulatory push wearing two names. They regulate two entirely different things, aimed at two entirely different actors — and an organisation that’s mapped one against its obligations has often mapped nothing useful against the other.

I’ve written separately about NIS2’s essential-entity obligations and the CRA’s reporting deadline. This is the piece that matters once both are on the table simultaneously, which is increasingly the normal case for any organisation that both operates critical infrastructure and manufactures or distributes connected products: they don’t overlap the way most compliance mapping exercises assume.

Two different questions, two different answers

NIS2 asks: is this entity operating essential or important services, and is its cyber risk management good enough? It regulates organisations — energy operators, hospitals, digital infrastructure providers, and a wide second tier of important entities — based on what they do and how significant that activity is to society. The obligations attach to the entity’s operations as a whole: risk management measures, incident reporting, governance, and increasingly personal liability for the management body if the entity fails.

The CRA asks a completely different question: is this product connected, and was it built securely? It regulates manufacturers of products with digital elements, based on what they place on the market, not on what kind of organisation they are. The obligations attach to the product’s lifecycle — secure-by-design requirements, vulnerability handling, the Article 14 reporting duty for actively exploited vulnerabilities — regardless of whether the manufacturer is itself a critical-infrastructure operator or a small hardware vendor selling to consumers.

Where an organisation can carry both simultaneously

The confusion mostly arises because a single organisation frequently sits on both sides at once. An energy utility is an NIS2 essential entity because of what it operates — and if that same utility manufactures or distributes smart metering hardware, it is also a CRA manufacturer for that specific product line, carrying an entirely separate set of product-level obligations that have nothing to do with its NIS2 status as an operator. The two regimes don’t merge into one obligation; they stack, addressed to different aspects of the same organisation’s activity.

This stacking is where compliance programmes most often go wrong — treating NIS2 readiness as if it automatically covers CRA obligations, because both involve “cybersecurity” and both involve “reporting.” It doesn’t. An entity-level incident-response process built for NIS2’s 24-hour early warning to a national CSIRT is a different process, potentially with different triggers and a different regulator, from a product-level vulnerability disclosure process built for the CRA’s Article 14 duty to ENISA. Treating them as one programme risks building a single process that satisfies neither regulator’s specific requirements precisely.

What actually needs mapping separately

The practical fix is treating the two as genuinely separate regulatory maps that happen to intersect at specific organisational points, rather than one map with two names. For each product line, ask the CRA scope question independently of the entity’s NIS2 status. For each operational function, ask the NIS2 essential/important question independently of any product the organisation happens to manufacture. Where the two intersect — an essential entity that also manufactures a connected product — build two coordinated but distinct response chains, sharing underlying evidence infrastructure where genuinely possible, but not assuming one filing satisfies both regulators.

This is the same evidence-model discipline running through every regulation on this site, applied to the specific trap of assuming regulatory overlap where the actual overlap is much narrower than the shared vocabulary suggests.

Where the two chains actually diverge

A water utility with an in-house-developed smart-metering product is a clean version of this stacking. As an NIS2 essential entity, its obligation is entity-wide: risk management across its operational technology, a 24-hour early warning to its national CSIRT for a significant incident affecting service delivery, governance and training reaching the management body. As a CRA manufacturer of the metering hardware it sells to other utilities, its obligation is product-specific: secure-by-design engineering for that product line, a 24-hour early warning to ENISA for an actively exploited vulnerability in the meter itself, and conformity documentation tied to that specific product’s lifecycle. An incident in the utility’s own network is an NIS2 matter. A vulnerability discovered in the metering hardware it manufactures is a CRA matter, reported to a different body, on a related but legally distinct clock — and treating one incident-response plan as covering both, because both involve a 24-hour deadline, has already conflated two obligations that a regulator will not treat as interchangeable. Building two coordinated response chains that share underlying evidence infrastructure, rather than one chain stretched to cover both, is the difference between a defensible answer and a scramble the day a regulator asks which regime actually applies.

The entity-side obligations specifically are covered in full in NIS2 essential entities.

Mapping which of your organisation’s activities fall under NIS2, which fall under the CRA, and where the two genuinely intersect is exactly the kind of regulatory-architecture work a technology control assessment is built to untangle before an incident forces the distinction.