The CRA is the EU Cyber Resilience Act, which focuses on security requirements for products with digital elements before they reach the market and during their support life. NIS2 is an EU directive for essential and important entities, covering organisational cyber risk management and incident reporting. One targets product security, the other entity security and governance.
How CRA and NIS2 Differ in Scope
The cleanest way to separate them is to ask what is being regulated. CRA is product-facing, so its centre of gravity is the security of a product with digital elements across design, development, and support. nis2 is organisation-facing, so it governs the cyber risk management and reporting obligations of essential and important entities. The difference is not just legal form, it is the object of control.
That distinction matters in practice because the same vulnerability can trigger different obligations depending on whether you are shipping a product, operating a regulated entity, or both. A manufacturer may need to satisfy CRA requirements for the product while also meeting NIS2 duties for its own corporate environment and incident handling. In other words, one regime follows the product lifecycle, the other follows the operating entity and its governance duties.
For teams that sell software, embedded devices, SaaS components, or connected services, the boundary is often operational rather than theoretical. The product team may own secure development, vulnerability handling, and support commitments, while the legal or security governance function owns entity-level risk measures and reporting. When both apply, you should treat them as overlapping but distinct compliance tracks, not as substitutes for one another.
Where the Compliance Burden Falls
CRA places obligations on the product side of the house, so the evidence trail tends to be technical: secure-by-design decisions, vulnerability handling processes, conformity-related documentation, and lifecycle support commitments. The relevant question is whether the product itself is being made resilient enough before it is placed on the market and while it remains supported.
NIS2 places obligations on the organisation, so the evidence trail is broader: risk management policies, incident response, supplier oversight, management accountability, and reporting discipline. The relevant question is whether the entity can operate safely, report material incidents on time, and maintain governance over the services it provides.
That difference changes ownership. Product security, engineering, and release management usually carry the CRA workload, while risk, compliance, security operations, and senior management carry most of the NIS2 workload. In practice, the same company may need two different control narratives, one for product assurance and one for enterprise resilience.
When the organisation builds connected products, the compliance boundary also determines how you evidence control maturity. CRA evidence is strongest when it shows product-level security requirements being built into the delivery pipeline and support model. NIS2 evidence is strongest when it shows the organisation can govern risk, detect incidents, and escalate them through a formal process.
When Both Regimes Apply at Once
Many organisations will touch both regimes, especially if they manufacture, distribute, or operate digital products while also falling within NIS2 scope as an essential or important entity. That is where confusion usually starts. The right response is to split the problem into two questions: what must the product do, and what must the entity do?
That split prevents a common mistake, assuming that product compliance automatically satisfies entity compliance, or that a corporate cyber programme automatically proves product security. It does neither. A secure product can still sit inside a weak organisation, and a well-run organisation can still ship a non-compliant product.
For readers comparing them, the practical test is simple. If the issue is product design, vulnerability disclosure, or support obligations, you are in CRA territory. If the issue is enterprise risk controls, incident reporting, governance, or management accountability, you are in NIS2 territory. The overlap is real, but the legal and operational lenses are different.
Risk and Threat Considerations
Misclassifying the regime can leave gaps in ownership, deadlines, and evidence. The usual failure mode is treating a product-security obligation as if it were just a general security best practice, or treating an entity-level governance duty as if it were only an engineering concern.
Failure mechanism: A company focuses on one regime and misses the other, so product evidence, reporting workflows, or executive accountability never get built into the right process owner.
Impact: That can create exposure to non-compliance, delayed incident handling, weak audit evidence, and fragmented remediation when a product flaw or operational incident crosses both boundaries.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
EU Cyber Resilience Act, NIS2 and ISO/IEC 27001:2022 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU Cyber Resilience Act | Cyber Resilience Act scope and product security requirements | The question compares an EU product-security regime with another directive. |
| Recommendation — Map product security obligations to CRA and evidence secure-by-design, support, and vulnerability handling. | ||
| NIS2 | Directive on measures for a high common level of cybersecurity | The question contrasts CRA with entity-level cyber risk and reporting duties. |
| Recommendation — Map organisational risk management and incident reporting duties to NIS2 and assign accountable owners. | ||
| ISO/IEC 27001:2022 | A.5.1 — Policies for information security | The comparison turns on governance separation and control ownership across product and entity scopes. |
| Recommendation — Separate product-security and organisational-security policies so each regime has clear control ownership. | ||
Practitioner Guidance
What to prioritise: Build a two-column assessment that separates product obligations from entity obligations. For each digital product, decide who owns secure development, vulnerability handling, and support commitments; for each regulated business unit, decide who owns risk management, incident reporting, and management escalation.
What to verify: Check whether your compliance evidence maps cleanly to the right subject. If the artefact describes the product, it should support CRA-style obligations. If it describes the organisation, it should support NIS2-style governance and reporting. Mixed evidence is a sign the ownership model needs tightening.
Practitioner takeaway: Treat CRA and NIS2 as complementary, not interchangeable, because the first regulates what you ship and support, while the second regulates how the entity manages cyber risk and reports incidents.
Related resources from NHI Mgmt Group
- Guide: EU Cyber Resilience Act Guide
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?