NIS2 (Directive (EU) 2022/2555) requires essential and important entities to manage cybersecurity risk in their supply chain under Article 21(2)(d), and to handle vulnerabilities in acquired software under Article 21(2)(e). For a team shipping software, the practical evidence is a maintained SBOM, a documented dependency-scanning cadence, and a written record of how you triage and respond to newly disclosed vulnerabilities.
Most NIS2 coverage is written for compliance officers, not the engineers who maintain the software those officers are accountable for. That gap matters because NIS2's supply-chain provision — Article 21(2)(d) — reaches directly into how you manage open-source dependencies, even though the directive never mentions "npm" or "SBOM" by name.
Accuracy note: every article number, deadline, and requirement below is cross-checked against Directive (EU) 2022/2555 on EUR-Lex and ENISA's published NIS2 guidance, not secondary summaries alone. NIS2 is transposed into 27 different national laws with some local variation — verify against your member state's transposing legislation and the current regulation text before making compliance decisions. This is not legal advice.
Who NIS2 Covers — And Who It Reaches Through Suppliers
NIS2 directly regulates "essential" and "important" entities across sectors named in its Annexes — energy, transport, banking, health, drinking water, digital infrastructure, public administration, and more — in every EU member state, plus, separately, any managed-service or managed-security provider serving them. It does not directly regulate a software vendor outside those sectors or that provider category. But Article 21(2)(d) forces every regulated entity to push supply-chain security obligations onto its own suppliers and service providers, which is how the directive reaches software that was never itself "in scope" in the first place.
The European Commission has stated that NIS2 significantly expands on the original 2016 NIS Directive's coverage, bringing far more medium and large entities into scope by removing the case-by-case designation model the first directive used. If your customer is an essential or important entity, your product is now a supply-chain dependency their Article 21(2)(d) risk management has to account for — regardless of your own company's size.
This is the mechanism worth understanding: NIS2 doesn't require your SaaS product to be independently audited by a regulator. It requires your customer to demonstrate they assessed the security-related risk you introduce, and increasingly that assessment shows up as a contractual requirement — an SBOM on request, evidence of a vulnerability-handling process, or proof of a defined patch cadence — flowing down from their compliance obligation to your engineering practice.
NIS2 also replaces the earlier directive's binary "operator of essential services" designation with a self-assessment model: an entity determines its own status as "essential" or "important" based on sector and size thresholds, rather than waiting for a national authority to name it. That shift means far more mid-sized organizations now have to actively work out whether they're in scope, and — because they no longer wait for a designation letter — they tend to start pushing supply-chain security requirements onto suppliers earlier in the compliance timeline than they did under the original 2016 directive.
Article 21(2)(d) and (e) in Plain Terms
Article 21(2)(d) requires "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." Article 21(2)(e) requires "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure." Read together, they turn dependency management from an engineering hygiene practice into a documented risk-management control a regulator or auditor can ask to see.
In practice, entities implementing these two measures are expected to:
- Assess the cybersecurity risk each direct supplier and service provider introduces, proportionate to the relationship's criticality
- Consider the overall quality of a supplier's products and the supplier's own cybersecurity practices — not just the contract terms
- Maintain a documented process for handling and disclosing vulnerabilities discovered in acquired or developed software
- Apply secure-development practices across the systems acquisition and maintenance lifecycle
ENISA's technical guidance for implementing the Article 21(2) measures frames this proportionally — a small important entity isn't held to the same supplier-audit rigor as a critical-infrastructure operator — but the underlying expectation is the same across entity sizes: you cannot claim to manage supply-chain risk for dependencies you haven't inventoried.
The Evidence a Dependency Scanner Actually Produces
The most direct way to demonstrate Article 21(2)(d) and (e) compliance for your software dependencies is the documentation a dependency-scanning tool already generates as a byproduct of normal use: a current software bill of materials, a dated history of vulnerability scans, and a triage log showing which findings you acted on and why.
A software bill of materials is the artifact that answers "what's actually in this software" — the direct dependencies you chose plus the transitive ones they pulled in. That transitive layer is where the risk concentrates: Sonatype's State of the Software Supply Chain research finds roughly 6 out of every 7 known open-source vulnerabilities sitting in transitive packages, not the ones a developer chose directly, which is exactly the layer a manual dependency list omits. Generating an SBOM is no longer a manual spreadsheet exercise; GeekWala's free SBOM generator produces a CycloneDX or SPDX document directly from your manifest or lockfile.
An SBOM alone doesn't satisfy Article 21(2)(e)'s vulnerability-handling requirement — you also need evidence you act on what the SBOM reveals, and evidence you're not treating every finding as equally urgent. Only a small fraction of published CVEs are ever exploited: the FIRST EPSS research team puts the historical exploited share at roughly 5.5-6.4% of the full CVE corpus, and CISA's Known Exploited Vulnerabilities catalog — the strictest confirmed-exploitation floor — lists roughly 1,700 entries against 355,000+ published CVEs. A triage log that shows EPSS scores and KEV status driving remediation order, rather than CVSS severity alone, is what turns "we scan" into "we manage risk," which is what Article 21(2)(e) actually asks for. That log needs: when you last scanned, which vulnerabilities were found, how you prioritized them, and what remediation happened. A scan history with timestamps and a resolved/accepted-risk disposition for each finding is exactly the kind of artifact an auditor evaluating Article 21(2)(d)/(e) implementation would ask a supplier to produce.
How NIS2 Interacts With the CRA
NIS2 and Regulation (EU) 2024/2847 — the EU Cyber Resilience Act — regulate different layers of the same underlying problem and are not interchangeable substitutes for one another, even though both ultimately bear on the same software dependencies you already ship. NIS2 is an entity-level risk-management and incident-reporting directive aimed at essential and important organizations across critical sectors. The CRA is instead a product-level regulation aimed at manufacturers of "products with digital elements," with its own security requirements and a separate incident-reporting clock that starts applying from September 11, 2026.
A single company can be an NIS2 "important entity" and a CRA "manufacturer" at the same time — for example, a healthcare provider (NIS2-regulated) that also builds and sells a connected medical device (CRA-regulated). In that case, the two regimes' supply-chain and vulnerability-handling expectations overlap heavily but are tracked and reported separately. If you maintain the dependency inventory, scan cadence, and vulnerability-handling process described above, most of the underlying evidence serves both regimes — see our software supply-chain security guide for how the full evidence chain fits together across CRA, NIS2, and general best practice.
Checklist: Article 21(2)(d)/(e) Evidence for Software Dependencies
- Maintain a current SBOM for every product with third-party dependencies
- Document your dependency-scanning cadence (e.g., every build, or at minimum weekly)
- Keep a dated vulnerability scan history, not just the latest snapshot
- Prioritize findings using EPSS and the CISA KEV catalog, and record the reasoning
- Maintain a written vulnerability-handling and disclosure policy
- Be able to produce the above on request from a customer's supply-chain risk assessment
Frequently Asked Questions
Does NIS2 apply to my company if we're a software vendor, not a critical-infrastructure operator?
Only if your company itself falls into one of the sectors and size thresholds in NIS2's Annexes. If it doesn't, NIS2 still reaches you indirectly the moment one of your customers is a regulated essential or important entity — their Article 21(2)(d) obligation requires them to assess your security practices as a supplier, so expect contractual requests for the evidence described above even without direct regulatory exposure.
What's the difference between NIS2 Article 21(2)(d) and the CRA's supply-chain requirements?
Article 21(2)(d) is about an entity managing risk from its suppliers and service providers as part of its own organizational risk management. The CRA instead places direct product-security obligations — vulnerability handling, security updates, and incident reporting — on the manufacturer of a "product with digital elements." A supplier can face both: NIS2 obligations from a customer's risk assessment, and separate CRA obligations if it manufactures a qualifying product itself.
Is there a specific SBOM format NIS2 requires?
No. Unlike the CRA, which points toward machine-readable SBOM formats as part of its essential requirements, NIS2's Article 21(2) measures are written at a principles level and leave the specific evidence format to the entity implementing them and any sector-specific guidance from national authorities. CycloneDX and SPDX are the two formats in practical industry use, and either satisfies the underlying "can you show what's in your software" expectation.
When did NIS2 become enforceable?
NIS2 entered into force on January 16, 2023, with EU member states required to transpose it into national law by October 17, 2024. Enforcement details, including registration and supervision timelines, vary by member state — check your national transposing legislation for the exact dates and thresholds that apply to your entity.
