CRA vs NIS2: What Each Asks of a Software Company

· Yunus Yildiz

Both laws are about cybersecurity, both were adopted within two years of each other, and both have a 24-hour early warning. That is roughly where the resemblance ends. The Cyber Resilience Act sets rules for products; NIS2 sets rules for organisations. A software company usually meets the first as a manufacturer and the second as a supplier to organisations that are regulated.

Side by Side

Cyber Resilience Act NIS2
Instrument Regulation (EU) 2024/2847, directly applicable in every Member State Directive (EU) 2022/2555, applied through national law (in the Netherlands, the Cyberbeveiligingswet, since 15 August 2026)
Who is obliged Manufacturers of products with digital elements made available on the EU market, plus importers, distributors and open-source stewards Essential and important entities in the sectors of its Annexes I and II, as a rule medium-sized or larger (Article 2(1))
What it regulates Properties of the product and how its vulnerabilities are handled (Annex I), conformity assessment, technical documentation, CE marking The entity's risk-management measures (Article 21), its incident reporting (Article 23) and its management's accountability (Article 20)
Reporting trigger An actively exploited vulnerability in the product, or a severe incident having an impact on the security of the product (Article 14) A significant incident: severe operational disruption or financial loss, or considerable damage to others (Article 23(3))
Reported to The CSIRT designated as coordinator, via ENISA's single reporting platform, simultaneously accessible to ENISA The national CSIRT or, where applicable, the competent authority
Deadlines 24h early warning, 72h notification, final report 14 days after a fix is available (vulnerabilities) or one month after the notification (incidents) 24h early warning, 72h incident notification, final report one month after the notification
Enforced by Market surveillance authorities National competent authorities
Maximum fines Up to EUR 15 million or 2.5% of worldwide turnover for Annex I and Articles 13 and 14 (Article 64) Member States must set maxima of at least EUR 10 million or 2% (essential) and EUR 7 million or 1.4% (important) (Article 34)
Applies from Reporting: 11 September 2026. Manufacturers' other obligations: 11 December 2027 (timeline) National measures from 18 October 2024 (Article 41); in practice from each Member State's transposition

Two details in that table are easy to misread. NIS2's fines are minimum ceilings, so a national law may go higher; the CRA's are the ceilings. And the CRA's reporting deadlines already apply, while its product requirements do not until December 2027.

Why They Rarely Hit a Software Company the Same Way

The CRA asks: is what you put on the market secure, and do you handle its vulnerabilities? Its obligations follow the product: the risk assessment, the essential requirements, the SBOM from December 2027, the support period, the reporting. If you ship software, you are likely a manufacturer, whatever your size. There is no medium-sized threshold.

NIS2 asks: is this organisation managing the risks to the services it provides? A small software vendor is usually not itself an essential or important entity. Larger ones may be, in particular as cloud computing or managed service providers, which NIS2 lists under digital infrastructure and ICT service management. Whether a SaaS offering counts is covered in does the CRA apply to SaaS.

Where They Meet

Through your customers. NIS2 requires regulated entities to address supply chain security and to take into account "the overall quality of products and cybersecurity practices of their suppliers ..., including their secure development procedures" (Article 21(3)). That is where NIS2 reaches a vendor that is not itself in scope: as a contractual requirement and a questionnaire. The questions, and a way to answer them once, are in answering NIS2 supplier questionnaires.

Through procurement on top of the CRA. A product that meets the CRA may still not be enough for a particular buyer. Recital 13 says Member States cannot add product requirements for matters the CRA harmonises, but "any entity, public or private, can however establish additional requirements ... for the procurement or use of products with digital elements for its specific purposes". A NIS2 entity asking for more than the CRA requires is doing exactly that.

In the same evidence. What a customer asks for under NIS2 and what a manufacturer needs under the CRA overlap almost entirely: an inventory of components, known vulnerabilities and how they are handled, proof of integrity, and a way to be told when something goes wrong. Produce it once per release and both regimes draw on it.

In the same company, occasionally. A manufacturer that also operates a service in NIS2 scope can face both reporting duties for related events: a CRA notification because a vulnerability in its product is actively exploited, and a NIS2 notification because an incident significantly affects the service it provides. The triggers, recipients and final-report clocks differ, so a single runbook needs two branches rather than one form.

Placing Yourself

  • You supply software (installed, embedded, a client, an agent, a library, a self-hosted edition): the CRA applies to you as a manufacturer. Article 14 reporting already does.
  • You operate a service in a NIS2 sector and are medium-sized or larger: NIS2 applies to you as an entity, through your national law.
  • Your customers are NIS2 entities: NIS2 reaches you through their supplier management, whether or not you are in scope yourself.

Most software companies are in the first and third groups at once. That is the sentence on our homepage: your product falls under the CRA, your customers fall under NIS2.

Sources

This article compares the two EU texts; national transpositions of NIS2 differ in detail. It reflects our reading as of the date above and is not legal advice.