The Cyber Resilience Act, Regulation (EU) 2024/2847, is a product regulation: it sets cybersecurity requirements for products with digital elements placed on the EU market. NIS2, Directive (EU) 2022/2555, is an organisational directive: it sets cybersecurity and incident-reporting duties for essential and important entities operating in the EU. They address different subjects, the product versus the organisation, and most software businesses will need to satisfy both.
The legal form matters. The CRA is a regulation, so it applies directly and uniformly across the EU from its dates of application, with the main obligations applying from 11 December 2027.
NIS2 is a directive, so it takes effect through national law. Member States were to transpose it by 17 October 2024 and apply the measures from 18 October 2024 (Article 41). As a directive, its practical applicability depends on national transposition, and several Member States transposed late, so the exact requirements and timing can vary by country.
The two instruments meet in the middle even though they start from different places.
If you build and sell software, the CRA governs what you ship, while NIS2 may govern how your organisation runs, and the supply-chain security duties in NIS2 pull in the security of the products you use and produce.
The work you do for one regime feeds the other. A well-maintained SBOM, a disciplined vulnerability handling process, and clear conformity documentation are CRA artefacts, but they are also exactly the supply-chain evidence that supports NIS2 risk management. Building the evidence once, in a structured form, avoids duplicating effort across the two regimes.
Machine-readable control and assessment data helps you reuse evidence across frameworks rather than re-authoring it for each. OSCAL is a NIST-led, machine-readable interoperability framework for security-control and assessment information; it is not named or mandated by either the CRA or NIS2 and should therefore be presented as an optional compliance-automation format rather than a regulatory obligation. Used this way, the same underlying evidence can be presented against CRA obligations and NIS2 measures.
CRANIS2 is built for the CRA, and its NIS2 support exists for one practical reason: to help software suppliers sell into larger, often NIS2-regulated customers in a frictionless manner. The SBOM, vulnerability records, and conformity evidence you build for the CRA also answer the supply-chain questions those customers ask under NIS2, exported through an OSCAL-based structure so the data stays reusable. See where you stand with a NIS2 conformity assessment.
Possibly. They apply to different things: the CRA to products with digital elements you place on the market, and NIS2 to essential and important entities as defined in national transposition. Many software organisations fall within both, so assess each separately.
Because NIS2 is a directive. Member States were to transpose it by 17 October 2024 and apply the measures from 18 October 2024, but as a directive its practical applicability depends on national transposition, and several Member States transposed late.
Yes, in practice. The SBOM required under Annex I Part II of the CRA is supply-chain evidence that also supports the supply-chain risk management expected under NIS2, so structured evidence can serve both.
Related guides: Does the CRA apply to my product? and CRA alongside DORA, GPSR and the Product Liability Directive.