NIS2 does not name software bills of materials or dependency scanning, but Article 21 requires supply chain security and secure acquisition, development and maintenance, including vulnerability handling. Software supply chain controls such as inventories, patching and supplier checks are ways to meet those measures, and management bodies are accountable for approving them.
What does Article 21 require?
Directive (EU) 2022/2555 sets cybersecurity risk-management measures for essential and important entities. Article 21(2) lists measures, which we paraphrase here:
- (a) policies on risk analysis and information system security
- (b) incident handling
- (c) business continuity, including backup management, disaster recovery and crisis management
- (d) supply chain security, including security aspects of relationships with direct suppliers or service providers
- (e) security in acquiring, developing and maintaining network and information systems, including vulnerability handling and disclosure
- (f) policies and procedures to assess whether the measures are effective
- (g) basic cyber hygiene practices and cybersecurity training
- (h) policies on cryptography and, where appropriate, encryption
- (i) human resources security, access control policies and asset management
- (j) where appropriate, multi-factor or continuous authentication, secured communications and secured emergency communication systems
Article 21(3) adds that, on supply chain, entities must take into account the vulnerabilities specific to each direct supplier and service provider, the overall quality of suppliers' products and cybersecurity practices including secure development, and the results of coordinated security risk assessments of critical supply chains.
Article 20 puts governance on management bodies: they approve the risk-management measures, oversee implementation and can be held liable for infringements of Article 21.
How do software supply chain controls map?
This is our mapping, not an official one. The directive text does not prescribe tools.
- (a) risk analysis: Dependency and component inventory feeding a risk register
- (d) supply chain security: Supplier questions about secure development, a software bill of materials from vendors, and tracking of their fix timelines
- (e) acquisition, development, maintenance: Scanning of code and dependencies, a patch process, and a vulnerability disclosure channel
- (f) effectiveness: Metrics such as time to fix known exploited flaws, reviewed on a schedule
- (g) cyber hygiene: Pinned versions, lockfiles, and training for developers
- (i) asset management, access control: Inventory of repositories, build systems and who can publish
- (j) authentication: Strong authentication on source control, CI and package registries
Recital 85 supports this reading. It says entities should assess the overall quality and resilience of suppliers' products and services, including their secure development procedures, and should be encouraged to write cybersecurity requirements into contracts with direct suppliers.
What does Article 21(3) mean for software buyers?
It means supplier risk is assessed per supplier, not as a blanket policy. Two vendors with different histories and practices can need different handling. In practice you want a supplier register with, for each critical supplier, what software they provide, how they publish security fixes and how you will hear about problems.
What to do
- Decide whether you are an essential or important entity, and which national rules apply. Member States transpose the directive, so check your country's law.
- Create the supplier register for software and cloud services.
- Add contract language on security requirements and incident notice, as recital 85 encourages.
- Build an inventory of components in the software you ship and run.
- Define a vulnerability handling process with owners and target times.
- Pick effectiveness measures for item (f) and report them to management.
- Brief the management body, since Article 20 makes approval and oversight theirs.
Where Safeguard fits
Dependency inventory, reachability analysis and compliance automation help produce the evidence behind items (a), (d), (e) and (f). They support your program and do not make an entity compliant with NIS2. Whether an entity meets the directive is for its national authority to judge.
Quick check
Does NIS2 require an SBOM?
The directive text we read does not name SBOMs. It requires supply chain security and secure development and maintenance, and an SBOM is one practical way to support that.
Who is accountable under NIS2?
Under Article 20, management bodies approve the measures, oversee implementation and can be held liable for infringements of Article 21.
Sources
Last reviewed: 18 October 2026.
