The NIS2 Directive (EU 2022/2555) has been enforceable in EU member states since October 17, 2024, and it explicitly names software supply chain security as a compliance requirement under Article 21(2)(d). If you sell software to hospitals, energy operators, banks, cloud providers, or public administrations in the EU, your customers are now legally required to vet your security practices before they can use your product — and to report incidents involving your code within 24 hours of becoming aware of them. Fines for non-compliance reach €10 million or 2% of global annual turnover for "essential entities" and €7 million or 1.4% for "important entities," whichever is higher. Unlike NIS1, which covered roughly 500 organizations across the EU, NIS2 expands scope to an estimated 160,000+ entities across 18 sectors. For software vendors, that means a much larger customer base now asking for SBOMs, vulnerability disclosure processes, and evidence of supply chain controls before signing a contract.
What is the NIS2 Directive and who does it apply to?
NIS2 is an EU-wide cybersecurity law that replaced the original 2016 NIS Directive, expanding mandatory security and incident-reporting obligations to 18 sectors instead of 7. It splits covered organizations into "essential entities" (energy, transport, banking, health, water, digital infrastructure, public administration, space) and "important entities" (postal services, waste management, chemicals, food, manufacturing, digital providers, research). Software vendors are captured two ways: directly, if they fall under "digital infrastructure" or "ICT service management" (managed service providers, managed security service providers), and indirectly, because every essential and important entity that buys their software must now assess supply chain risk under Article 21. A mid-sized SaaS vendor selling to a German hospital network or a French energy utility is now inside the compliance perimeter even if it has no EU legal entity of its own, because its customer's NIS2 obligations flow contractually down the supply chain.
When did NIS2 compliance become mandatory?
NIS2 became enforceable on October 17, 2024, the deadline by which all 27 EU member states were required to transpose the directive into national law. The directive itself entered into force on January 16, 2023, giving member states 21 months to write implementing legislation — a deadline most missed; as of mid-2025, fewer than half of member states had fully transposed the directive, with countries like Germany, Belgium, and Italy finalizing national statutes on staggered timelines through 2025. That patchwork doesn't buy vendors time: national regulators (like Germany's BSI or France's ANSSI) are already applying enforcement based on the EU-level text and their draft national rules, and customer procurement teams stopped waiting for perfect legal clarity months ago. Vendors that wait for a single "compliance deadline" email are already behind the RFPs asking for SBOMs and incident-response SLAs today.
Does NIS2 apply to software vendors specifically?
Yes, through Article 21(2)(d), which requires covered entities to address "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure." This is the clause vendors feel first: it obligates your customers to evaluate the security of products they procure from you, which in practice means contract riders demanding a software bill of materials (SBOM), a documented CVE remediation SLA (commonly 30 days for critical, 90 for high), and a coordinated vulnerability disclosure process. Article 21(3) goes further, explicitly calling out supply chain security assessments of direct suppliers. A vendor that can't produce a CycloneDX or SPDX SBOM on request, or can't show mean-time-to-remediate data for the last 12 months of disclosed CVEs, will increasingly lose deals to competitors who can — regardless of whether the vendor itself is a "covered entity."
What are the penalties for NIS2 non-compliance?
Essential entities face fines up to €10 million or 2% of global annual turnover, and important entities face up to €7 million or 1.4%, with the higher of the two amounts always applying. Beyond fines, NIS2 introduces personal liability for management bodies — executives can be held accountable for inadequate cybersecurity risk management, and in some member state implementations (Germany's NIS2UmsuCG draft, for example) that includes temporary bans from management positions for repeated non-compliance. For a software vendor, the more immediate financial risk isn't a direct fine (most vendors aren't "covered entities" themselves) — it's contract termination clauses. EU enterprises are writing NIS2-compliance warranties into vendor contracts, and a failure to produce an SBOM or meet a disclosed-CVE remediation SLA within the timeline specified in Article 23 (72-hour early warning, 24-hour initial notification for significant incidents) can trigger breach-of-contract exposure that dwarfs a regulatory fine.
What does NIS2 require for software supply chain security?
NIS2 requires documented risk management measures covering the entire software supply chain, not just an organization's own infrastructure, per Article 21(2). In practice, auditors and enterprise procurement teams are asking for four concrete artifacts: a current SBOM per release, evidence of vulnerability scanning integrated into the CI/CD pipeline, a documented incident-reporting process that can hit the 24-hour/72-hour/1-month reporting cadence set out in Article 23, and proof that third-party and open-source dependencies are inventoried and monitored for newly disclosed CVEs. This is a meaningfully higher bar than a point-in-time penetration test. A vendor shipping monthly releases needs an SBOM generation process that runs on every build, not a PDF from last year's audit — and needs to be able to say, for any CVE published against a dependency it uses, exactly which product versions are affected and whether the vulnerable code path is actually reachable.
How do you demonstrate NIS2 compliance for your software supply chain?
You demonstrate NIS2 compliance by producing an audit trail: current SBOMs, a vulnerability disclosure policy, remediation SLA data, and incident response documentation that a customer's procurement or security team can review without a live meeting. Most enterprise buyers in regulated NIS2 sectors have started sending standardized security questionnaires (often mapped to ISO 27001 Annex A or the EU's ENISA guidance) that ask for exactly this evidence — SBOM format and cadence, CVE mean-time-to-remediate over trailing 12 months, and whether vulnerability triage distinguishes exploitable from theoretical exposure. Vendors relying on manual spreadsheet tracking typically take 2-4 weeks to assemble this package per RFP; vendors with automated SBOM and vulnerability management pipelines can turn it around in under a day, which increasingly determines who wins the deal before the technical evaluation even starts.
How Safeguard Helps
Safeguard automates the artifacts NIS2 procurement reviews actually ask for. It generates CycloneDX and SPDX SBOMs on every build and ingests SBOMs from your own vendors so you can answer Article 21(3) supply chain questions with real data instead of a spreadsheet. Griffin AI, Safeguard's reachability-analysis engine, distinguishes CVEs that are actually exploitable in your running code from the thousands that show up in a naive dependency scan, so your remediation SLA reporting reflects real risk instead of noise. When a fix is available, Safeguard opens auto-fix pull requests directly against the affected dependency, cutting mean-time-to-remediate from weeks to hours. That combination — continuous SBOMs, reachability-verified findings, and automated remediation — turns NIS2's supply chain requirements from a quarterly compliance scramble into a standing, audit-ready posture.