Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
Compliance›NIS2 Directive
EU · Directive (EU) 2022/2555

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).

Talk to our advisory team Read it on EUR-Lex
At a glance
17 Oct 2024Member-state transposition deadline
18 sectorsIn scope as essential or important entities
24h / 72hEarly warning and incident notification (Art 23)
€10M / 2%Max fine for essential entities (or % of global turnover)
Directive (EU) 2022/2555 (NIS2 Directive)
Why NIS2 matters

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.

How O3 helps

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.

1 · Find it first

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.

2 · Catch it live

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.

3 · Fix it fast

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.

Risk-based prioritisation

From alert flood to a short list

KEV + EPSS + reachability turn a raw scan into the few findings that actually need action now.

Raw findings in dependency tree~12,400
Vulnerable & version-matched~4,700
Reachable in your code~1,360
KEV / high-EPSS · act now~370

Illustrative funnel. Reachability removes the bulk of unexploitable noise before triage.

Remediation expectations

The clock by finding type

Indicative fix windows. Tightest where exposure and active exploitation meet.

Early warning to CSIRT / competent authority24 hours
Incident notification (severity, impact, indicators)72 hours
Final report after incident handled1 month
Article 21(2)(d)

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.

Art 21(2)(d)
Build an inventory of direct suppliers and service providers, and map which products and services touch your network and information systems (Art 21(2)(d)).
Generate a component inventory (SBOM in CycloneDX) for the software you build and operate so you can see the third-party and open-source components each supplier contributes.
Set contractual security requirements with direct suppliers covering patching commitments, vulnerability disclosure, and the right to evidence of secure development.
Tier suppliers by criticality and reassess high-impact suppliers regularly rather than treating all suppliers equally.
Where O3 helps

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.

Article 21(3)

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.

Art 21(3)
Score each direct supplier on the known vulnerabilities present in the products and components they provide, not just their paperwork (Art 21(3)).
Request evidence of secure development from suppliers: SBOMs, vulnerability disclosure policies, patch SLAs, and SLSA or signed provenance where available.
Track which supplied components carry actively exploited or high-probability vulnerabilities so supplier risk is grounded in real exposure.
Feed supplier vulnerability data into procurement and renewal decisions so consistently weak suppliers are remediated or replaced.
Where O3 helps

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.

Article 21(2)(e)

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.

Art 21(2)(e)
Establish a vulnerability handling process: intake, triage, remediation, and verification, with a coordinated disclosure policy (Art 21(2)(e)).
Scan source and dependencies in CI: static analysis for code-level flaws, software composition analysis for known component vulnerabilities, and secret scanning for leaked credentials.
Run dynamic and penetration testing against running applications to find issues that static analysis cannot see.
Fix findings on a defined SLA and re-test to confirm closure, keeping an auditable record of each vulnerability lifecycle.
Where O3 helps

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.

Article 21(2)(a)-(c)

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.

Art 21(2)(a)Art 21(2)(b)Art 21(2)(c)
Document risk-analysis and information-system security policies approved by the management body (Art 21(2)(a)).
Stand up an incident-handling capability with detection, response, and post-incident review aligned to the Article 23 reporting clock (Art 21(2)(b)).
Maintain backups, disaster recovery, and crisis-management procedures, and test them on a schedule (Art 21(2)(c)).
Ensure measures are proportionate to the entity's size, exposure, and the likelihood and severity of incidents.
Where O3 helps

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.

Article 21(2)(f)-(j)

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).

Art 21(2)(f)Art 21(2)(g)Art 21(2)(h)Art 21(2)(i)Art 21(2)(j)
Define cyber-hygiene baselines and deliver recurring security awareness training to staff and management (Art 21(2)(g)).
Adopt policies on the use of cryptography and, where appropriate, encryption (Art 21(2)(h)).
Implement access control, asset management, and identity practices, with multi-factor authentication and secured voice, video, and text communications (Art 21(2)(i),(j)).
Periodically assess the effectiveness of the measures and feed gaps back into the risk-management cycle (Art 21(2)(f)).
Article 23

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.

Art 23
Submit an early warning to the CSIRT or competent authority within 24 hours of becoming aware of a significant incident (Art 23).
Provide an incident notification within 72 hours, including an initial assessment of severity, impact, and any indicators of compromise (Art 23).
Deliver a final report within one month covering root cause, mitigations, and cross-border impact (Art 23).
Pre-build templates, an on-call escalation path, and an evidence pipeline so the 24-hour clock does not start against an unprepared team.
Where O3 helps

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.

The whole framework

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.

13Art 20-21
Governance and risk-management measures
3Art 21(2)(d),(e),(3)
Supply chain and vulnerability handling
3Art 23
Incident reporting timeline
4Art 24-34
Certification, registration, enforcement
Requirement area
Scope: essential and important entitiesArt 2-3, Annex I-IIDetermine scope across 18 sectors and size
Governance and management accountabilityArt 20Management body approves and oversees measures
Risk-analysis and security policiesArt 21(2)(a)Document and approve IS security policies
Incident handlingArt 21(2)(b)Detect, respond, review security incidents
Business continuity and crisis managementArt 21(2)(c)Maintain backup, DR, crisis procedures
Supply-chain security (direct suppliers)Art 21(2)(d)Inventory and manage supplier security risk
Secure acquisition, development, maintenanceArt 21(2)(e)SAST, SCA, secret scan, vuln handling in CI
Vulnerability handling and disclosureArt 21(2)(e)Triage, remediate, re-test, disclose
Effectiveness assessmentArt 21(2)(f)Measure and review control effectiveness
Basic cyber hygiene and trainingArt 21(2)(g)Baselines plus recurring security training
Cryptography and encryptionArt 21(2)(h)Policy on use of crypto and encryption
Access control and asset managementArt 21(2)(i)HR security, access control, asset inventory
Multi-factor authentication and secure commsArt 21(2)(j)MFA and secured voice/video/text
Supplier vulnerability and secure-dev qualityArt 21(3)Score per-supplier vulns and dev practices
Early warningArt 23Notify CSIRT within 24 hours
Incident notificationArt 23Severity and impact within 72 hours
Final incident reportArt 23Root cause and mitigations within 1 month
Use of European cybersecurity certificationArt 24Use certified ICT products where required
StandardisationArt 25Apply relevant European/international standards
Registration of entitiesArt 27Register with the competent authority
Supervision and enforcementArt 31-34Support audits; face fines up to 2% turnover

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
FAQ

Common
questions.

Everything teams ask before rolling this out. Still stuck? Reach our team.

  • 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.