NIS2 Article 21 fundamentally changes third-party risk management: You are now legally liable for your vendors' security failures. When a supplier's vulnerability causes your breach, you face the same €10M fines—even if you did nothing wrong. Here's how to protect yourself.
The NIS2 Directive (EU 2022/2555) Article 21 states:
"Member States shall ensure that essential and important entities take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use for their operations or for the provision of their services, and to prevent or minimise the impact of incidents on recipients of their services and on other services."
Translation: You are responsible for securing your entire supply chain—including third-party software, cloud services, SaaS platforms, APIs, and vendor infrastructure. If a supplier's vulnerability leads to your breach, you are liable, not them.
NIS2 supply chain obligations cover:
Unlike GDPR (where you can transfer some liability to processors via contracts), NIS2 provides no safe harbor for supply chain failures. You cannot contractually shift NIS2 liability to vendors. Even with perfect vendor contracts, you face BSI penalties if their vulnerability causes your breach.
The SolarWinds Orion compromise remains the most sophisticated supply chain attack in history. Russian APT29 (Cozy Bear) injected malware into SolarWinds' software build pipeline, distributing it as a legitimate update to 18,000 customers—including NATO, the Pentagon, and Fortune 500 companies.
Attack timeline:
NIS2 implication: Every organization that installed the compromised SolarWinds update would be liable under NIS2—even though they were victims. BSI would require incident notification, forensic investigation, and proof of supply chain due diligence.
REvil ransomware gang exploited a zero-day in Kaseya VSA (remote management software) to simultaneously encrypt 1,500 organizations via their managed service providers (MSPs). A single vulnerability in one software vendor cascaded into the largest ransomware attack in history.
Attack mechanics:
NIS2 implication: Organizations using MSPs are liable for the MSP's security failures. You cannot argue "our MSP got hacked" to BSI. Your compliance, your responsibility.
The MOVEit Transfer SQL injection vulnerability (CVE-2023-34362) was weaponized by the Cl0p ransomware gang to breach 2,000+ organizations globally, including Shell, British Airways, BBC, and government agencies across the EU.
Why it matters for NIS2:
CVE-2021-44228 (Log4Shell) was a remote code execution vulnerability in Log4j, a ubiquitous Java logging library. Because Log4j is a transitive dependency (embedded in other software), organizations had no idea they were vulnerable.
NIS2 implication: You are liable for vulnerabilities in all dependencies—even ones you didn't know existed. BSI expects you to maintain a Software Bill of Materials (SBOM) and patch within 14 days of critical CVE disclosure.
NIS2 requires "appropriate and proportionate" supply chain security measures. Here's a practical framework for vendor risk management that will satisfy BSI audits:
You can't secure what you don't know about. Create a comprehensive supplier inventory:
| Category | What to Document | Risk Level |
|---|---|---|
| Software Vendors | All commercial software, licenses, update mechanisms | Critical |
| Open Source Dependencies | Direct + transitive dependencies (use SBOM) | Critical |
| Cloud Providers | AWS/Azure/GCP services, access methods, data locations | Critical |
| SaaS Platforms | CRM, email, analytics, APIs with data access | High |
| Managed Service Providers | IT support, SOC, backup services, remote access | Critical |
| Hardware Suppliers | Network equipment, firmware versions, update policies | Medium |
For every critical vendor, conduct a security assessment. Here are the questions BSI expects you to ask:
NIS2 requires ongoing supply chain risk management. Annual questionnaires are insufficient. Implement continuous monitoring:
The Log4Shell incident proved that organizations don't know what's running in their infrastructure. Software Bill of Materials (SBOM) is now a de facto NIS2 requirement.
An SBOM is a complete inventory of all software components—direct dependencies AND transitive dependencies (the dependencies of your dependencies).
Example SBOM for a typical web application:
| Component | Version | License | Known CVEs |
|---|---|---|---|
| express | 4.18.2 | MIT | 0 |
| lodash | 4.17.19 | MIT | CVE-2020-8203 (prototype pollution) |
| axios | 0.21.1 | MIT | CVE-2021-3749 (SSRF) |
| log4j-core (transitive) | 2.14.0 | Apache 2.0 | CVE-2021-44228 (Log4Shell RCE) |
Notice that log4j-core is a transitive dependency—your application doesn't directly import it, but another library does. Without an SBOM, you'd never know you're vulnerable to Log4Shell.
Modern tools can auto-generate SBOMs:
npm sbom (native npm command), Syft, OWASP Dependency-Checkpip-audit, Syft, CycloneDXgo mod graph, SyftHypothetical BSI audit question: "Your incident report states you were breached via CVE-2024-XXXXX in a third-party library. When was this CVE disclosed? When did you discover it in your environment? Why wasn't it patched?"
Compliant answer: "We maintain automated SBOM scanning. CVE-2024-XXXXX was disclosed on January 15. Our scanner detected it on January 16. We patched within 8 days (under our 14-day SLA). This particular breach occurred because the vulnerable library was present in a legacy system not covered by our scanner—we've since added it."
Non-compliant answer: "We didn't know we were using that library."
Use this checklist to prepare for BSI audits:
Not all vendors pose equal risk. Prioritize your security efforts:
| Tier | Criteria | Security Requirements |
|---|---|---|
| Critical | Access to production data, remote admin access, or essential service | ISO 27001 + SOC 2 Type II required, annual audits, 24h breach notification |
| High | Access to sensitive data or critical business function | SOC 2 or equivalent, security questionnaire, breach notification SLA |
| Medium | No data access but provides infrastructure/tools | Basic security questionnaire, MFA required |
| Low | No data access, non-critical service | Standard contract terms, no special assessment |
Every vendor is a potential attack vector. Reduce your attack surface by consolidating vendors:
Never grant vendors direct network access. Implement zero-trust controls:
Manual supply chain management doesn't scale. Use automation:
| Tool Category | Purpose | Examples |
|---|---|---|
| SBOM Generation | Auto-generate software inventories | Syft, OWASP Dependency-Check, KENSAI |
| CVE Scanning | Match dependencies against NVD | Grype, Trivy, Snyk, KENSAI |
| Vendor Risk Monitoring | Track vendor security posture | SecurityScorecard, BitSight, UpGuard |
| Contract Management | Centralize vendor contracts + SLAs | OneTrust, ServiceNow VRM, Archer |
| Access Management | Control vendor remote access | CyberArk, BeyondTrust, Okta |
KENSAI automatically generates NIS2-compliant SBOMs, detects vulnerable dependencies across 8 programming languages, and provides BSI-ready audit reports. No installation required—scan from your CI/CD pipeline or web dashboard.
Start Free Supply Chain Scan →Your vendor's vulnerability is your liability.
KENSAI Security Research Team
March 2, 2026 — 14:00 CET