The NIS2 Directive is the biggest expansion of European cybersecurity law to date, and it lands squarely on the desks of software and platform teams. Formally Directive (EU) 2022/2555, it repealed and replaced the original 2016 Network and Information Security Directive, widening the range of sectors in scope, harmonising rules across Member States, and — for the first time — writing supply-chain security and secure development into binding minimum requirements. If your organisation builds, ships, or operates software that supports an essential service in the EU, NIS2 changes what you have to do and, critically, what you have to be able to prove.
What NIS2 actually is
NIS2 is a directive, not a regulation, which means it does not apply directly. Each EU Member State transposes it into national law, and the details (thresholds, registration mechanics, exact penalty ceilings) can vary at the margins. The directive sets a floor. It defines two categories of in-scope organisation: essential entities and important entities, distinguished mainly by sector and size. Both must meet the same core security obligations; the difference shows up in how strictly regulators supervise them and how large the fines can be.
The directive covers 18 sectors split into "sectors of high criticality" (energy, transport, banking, financial market infrastructure, health, drinking and waste water, digital infrastructure, ICT service management, public administration, space) and "other critical sectors" (postal services, waste management, chemicals, food, manufacturing of certain products, digital providers such as online marketplaces and search engines, and research). Digital infrastructure and ICT service management are where most software vendors, cloud providers, managed service providers, and data-centre operators find themselves.
Who it applies to, and the timelines
As a rule of thumb, NIS2 applies to medium-sized and larger organisations in the listed sectors — generally 50 or more staff, or annual turnover and balance sheet above EUR 10 million. Some entities are in scope regardless of size because of the systemic role they play, including DNS service providers, top-level-domain registries, and certain public administration bodies.
The transposition deadline was 17 October 2024. In practice, transposition has been uneven: several Member States missed the deadline, and the European Commission opened infringement proceedings against a number of them through 2024 and 2025. Because obligations flow from national law, teams should track the specific transposing statute in each country where they operate rather than relying on the directive text alone. Treat the directive as the baseline and the national law as the operative rule; where a Member State has not yet transposed, plan against the directive because enforcement follows quickly once the law is on the books.
The software and supply-chain obligations
The heart of NIS2 for engineering teams is Article 21, which requires an "all-hazards" set of cybersecurity risk-management measures. Two of its ten minimum elements matter most for software:
- Supply-chain security (Article 21(2)(d)) — security in the relationships with direct suppliers and service providers, including the security practices of those suppliers. This is where knowing your software components stops being optional.
- Security in acquisition, development, and maintenance, including vulnerability handling and disclosure (Article 21(2)(e)) — you must have a defined way to find, triage, and remediate vulnerabilities in the software you build and use, and to receive disclosures about them.
Article 22 adds EU-level coordinated risk assessments of critical supply chains, and Article 12 tasks ENISA with maintaining a European vulnerability database. Incident reporting under Article 23 runs on a strict clock: an early warning within 24 hours of becoming aware of a significant incident, a fuller incident notification within 72 hours, and a final report within one month. Management bodies must approve and oversee these measures under Article 20, can be held personally liable, and are required to undergo training. Penalties reach up to EUR 10 million or 2% of total worldwide annual turnover for essential entities, and EUR 7 million or 1.4% for important entities.
Compliance checklist
| Obligation | What to have in place | NIS2 anchor |
|---|---|---|
| Component inventory | A maintained SBOM for every product and service in scope | Art 21(2)(d) |
| Supplier assurance | Documented security requirements and reviews for direct suppliers | Art 21(2)(d) |
| Vulnerability handling | A process to detect, rank, and remediate known CVEs with SLAs | Art 21(2)(e) |
| Coordinated disclosure | A published channel to receive vulnerability reports | Art 21(2)(e), Art 12 |
| Secure development | Security requirements and testing across the SDLC | Art 21(2)(e) |
| Incident reporting | 24-hour, 72-hour, and one-month reporting runbooks | Art 23 |
| Governance | Board approval, oversight, and training records | Art 20 |
| Evidence retention | Retrievable logs of scans, fixes, and decisions | Art 21 (accountability) |
How Safeguard helps
NIS2 does not name "SBOM" as a term, but Article 21(2)(d) and 21(2)(e) are impossible to satisfy without one, because you cannot secure a supply chain you have not inventoried. SBOM Studio generates and maintains a component inventory for every application in scope, so the supplier-security element rests on data rather than a questionnaire. Safeguard's SCA engine continuously matches those components against known vulnerabilities and ranks them by reachability, which turns the vulnerability-handling obligation into a prioritised, SLA-tracked workflow instead of an unbounded CVE list. Because Safeguard records scan history, remediation timestamps, and fix decisions in one place, the accountability and reporting expectations under Articles 20 and 23 are backed by a retrievable trail. Our compliance pages map each capability to the specific NIS2 elements it supports, so you can show a national regulator which control evidences which duty.
Frequently Asked Questions
Does NIS2 apply to companies outside the EU? It can. An organisation established outside the EU that provides in-scope services within the EU generally falls under NIS2 and must designate a representative in a Member State where it offers services. The trigger is the service you provide into the EU, not where your headquarters sit, so many non-EU cloud and software vendors are captured.
Is an SBOM legally required under NIS2? Not by name. The directive requires supply-chain security and vulnerability handling (Article 21), and an SBOM is the practical mechanism regulators and auditors expect to see behind those measures. Treat it as strongly implied rather than explicitly mandated, and expect national guidance to lean on it heavily.
What counts as a "significant incident" for the 24-hour report? An incident that causes or is capable of causing severe operational disruption or financial loss, or that affects others through considerable material or non-material damage. Implementing acts and national law refine the thresholds for specific sectors, so confirm the definition in your transposing statute rather than assuming a single EU-wide number.
How is NIS2 different from the original NIS Directive? NIS2 covers far more sectors, removes the old distinction between operators of essential services and digital service providers in favour of essential and important entities, sets harmonised incident-reporting deadlines, adds explicit supply-chain and secure-development duties, and introduces management liability with much higher fines. It is a step change, not a refresh.
Ready to evidence your NIS2 supply-chain obligations? Compare approaches on our platform comparison hub or start reading the setup guides in the Safeguard documentation.