NIS2 Directive supply-chain security
how essential and important entities meet Article 21 and the 24h/72h reporting rules
The NIS2 Directive (Directive (EU) 2022/2555) raises the cybersecurity baseline for "essential" and "important" entities across 18 sectors. Article 21(2)(d) and (e) make supply-chain security and vulnerability handling explicit obligations, and Article 21(3) forces you to weigh the vulnerabilities and secure-development practices of each direct supplier.
This page explains, requirement by requirement, how to meet those obligations: supplier vulnerability visibility, vulnerability handling in development and maintenance, risk-based prioritisation, and the Article 23 incident reporting timeline (24-hour early warning, 72-hour notification).
A binding cybersecurity baseline with supply chain and vulnerabilities written into law
NIS2 replaced the original NIS Directive and entered into force on 16 January 2023, with a member-state transposition deadline of 17 October 2024. It applies to "essential" and "important" entities across 18 sectors, including energy, transport, banking, health, digital infrastructure, ICT service management, and public administration, generally covering medium and larger enterprises.
What makes NIS2 different is that supply-chain security and vulnerability handling are no longer optional good practice. Article 21(2)(d) covers the security of relationships with direct suppliers and service providers, Article 21(2)(e) covers security in acquisition, development and maintenance including vulnerability handling and disclosure (Art 21(2)), and Article 21(3) requires entities to take into account vulnerabilities specific to each direct supplier and the secure-development procedures of those suppliers.
NIS2 also makes leadership accountable. Management bodies must approve and oversee the risk-management measures, and national authorities can impose fines of up to €10 million or 2% of global annual turnover for essential entities, and €7 million or 1.4% for important entities. Transposition into national law remains uneven across member states in 2026, so check your national implementing act for the exact thresholds and timelines.
Find it before attackers do. Catch it if they try. Fix it fast.
Across these requirements, O3 runs one continuous loop on your own software so issues surface, get caught, and get fixed before they become an incident.
Test like an AI-assisted attacker
An agentic pentest probes your app across 50+ vulnerability classes the way a real attacker chains them, so exploitable flaws surface in your build before someone outside finds them.
Detect and block exploitation at runtime
A kernel-level eBPF agent watches process trees and syscalls, recognises an attack sequence as it unfolds, and restricts the offending process on the spot rather than taking down the host.
Auto-patch what is reachable
Reachability ranks what genuinely matters, then autofix opens a pull request with the change, so remediation starts inside tight fix windows instead of sitting in a queue.
From alert flood to a short list
KEV + EPSS + reachability turn a raw scan into the few findings that actually need action now.
Illustrative funnel. Reachability removes the bulk of unexploitable noise before triage.
The clock by finding type
Indicative fix windows. Tightest where exposure and active exploitation meet.
How to secure your direct-supplier relationships under NIS2
Article 21(2)(d) requires risk-management measures covering the security of relationships with direct suppliers and service providers. The obligation is about your direct suppliers, not the entire upstream chain, but it expects you to know what you depend on and to manage the risk that flows from it.
O3 produces a CycloneDX SBOM with deps.dev enrichment and VEX, and runs SCA against OSV plus malicious-dependency detection (typosquats, malicious postinstall, compromised maintainers), giving you concrete visibility into the components and known vulnerabilities each direct supplier introduces.
How to assess supplier vulnerabilities and secure-development quality
Article 21(3) goes further than a contract checkbox. When choosing measures under 21(2)(d), entities must take into account the vulnerabilities specific to each direct supplier and the overall quality of products and secure development procedures of their suppliers.
O3 ranks supplier-introduced vulnerabilities with function-level reachability (is the flawed code actually reachable) and EPSS plus KEV prioritisation, and reads existing SLSA and cosign provenance, so supplier risk is evidence-based rather than a questionnaire.
How to handle vulnerabilities in development and maintenance
Article 21(2)(e) requires security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure. This is the secure-development and AppSec heart of NIS2.
O3 covers the development side directly: code-property-graph SAST with source-to-sink interprocedural taint, SCA, Gitleaks-based secret scanning, agentic DAST/pentest across 50+ vulnerability classes, and autofix with auto-PR to close findings.
How to build the core risk-management and incident-handling measures
Article 21(2) also mandates risk-analysis and information-system security policies (a), incident handling (b), and business continuity including backup and crisis management (c). These are the foundation the supply-chain and vulnerability obligations sit on.
O3 contributes detection signal for incident handling through its eBPF runtime agent (kernel process trees, syscalls, attack-chain detection) and L7 deep packet inspection for exfiltration and DNS-tunnel detection. Governance, business continuity, and backup/DR remain organisational controls O3 does not provide.
How to meet the basic cyber hygiene, crypto, and access controls
Article 21(2) closes with measures on the effectiveness of cybersecurity (f), basic cyber hygiene and training (g), cryptography and encryption (h), human resources, access control and asset management (i), and multi-factor authentication and secured communications (j).
How to meet the 24-hour and 72-hour incident reporting deadlines
Article 23 sets a staged reporting clock for significant incidents. Missing these windows is one of the most common ways entities fall foul of NIS2, so the process must be rehearsed in advance.
O3's eBPF runtime agent and L7 egress monitoring help detect attack chains and exfiltration quickly and supply indicators of compromise, shortening the time to a meaningful early warning and 72-hour notification.
Every NIS2 obligation mapped to a concrete control
All 21 requirement areas, each with the reference and a vendor-neutral note on how teams meet it.
Turn NIS2 Article 21 into evidence you can show an auditor
O3 Security maps directly to the development side of NIS2: SBOM and SCA for supplier and component visibility (Art 21(2)(d), 21(3)), SAST, secret scanning, DAST and autofix for vulnerability handling (Art 21(2)(e)), reachability plus EPSS/KEV for risk-based prioritisation, and eBPF runtime detection to feed the Article 23 reporting clock. Governance, MFA, and business continuity stay with you; O3 gives you the technical proof for the rest.
Read it on EUR-Lex- Article 21(2)(d) requires risk-management measures covering the security of relationships with direct suppliers and service providers. You must know which suppliers touch your network and information systems and manage the security risk those relationships create, including through contracts and ongoing assessment, proportionate to each supplier's criticality.
- Article 21(2)(e) is about your own systems: security in acquisition, development and maintenance, including vulnerability handling and disclosure. Article 21(3) is about suppliers: when choosing measures you must take into account the specific vulnerabilities of each direct supplier and the quality of their products and secure-development procedures.
- Article 23 sets a staged clock. You submit an early warning to the CSIRT or competent authority within 24 hours of becoming aware of a significant incident, a fuller notification with severity and impact within 72 hours, and a final report within one month covering root cause and mitigations.
- NIS2 applies to essential and important entities across 18 sectors including energy, transport, banking, health, digital infrastructure, ICT service management, and public administration, generally medium and larger enterprises. The essential/important split affects supervision intensity and maximum fines. Check your national transposing law for exact thresholds.
- For essential entities, national authorities can impose fines up to €10 million or 2% of total worldwide annual turnover, whichever is higher. For important entities the ceiling is €7 million or 1.4%. Management bodies can also be held accountable for failing to approve and oversee the required risk-management measures (Art 20).
- NIS2 does not name SBOM explicitly, but Article 21(2)(d), 21(2)(e), and 21(3) require supplier and component vulnerability visibility and secure-development assurance. A CycloneDX SBOM is a practical way to evidence which third-party and open-source components each supplier contributes and what known vulnerabilities they carry.
- Directive (EU) 2022/2555 entered into force on 16 January 2023, with a member-state transposition deadline of 17 October 2024. Because it is a directive, it takes effect through national implementing laws, and transposition remains uneven across member states in 2026, so the binding detail comes from your national act.
- O3 covers the technical, development-side obligations: SBOM and SCA with malicious-dependency detection for supplier visibility (21(2)(d), 21(3)), SAST, secret scanning, DAST and autofix for vulnerability handling (21(2)(e)), reachability and EPSS/KEV for prioritisation, and eBPF runtime detection to support Article 23 reporting. Governance and access controls remain organisational.
See O3 Security in Action
See why security and engineering leaders trust O3
to secure their entire software supply chain.