Supply chain security guide: Vendor risks, regulations, and access control in 2026

A few years ago, the standard advice was simple: vet your vendors, sign an NDA, run an annual questionnaire. Then SolarWinds happened, then MOVEit, then XZ Utils — a backdoor planted over two years of legitimate open-source contributions, caught by an engineer who noticed a process running 500ms slower than it should. Every one of those attacks entered through a trusted relationship.

The pattern holds across every major incident. Third-party involvement now accounts for 48% of all data breaches (up from 30% the previous year) according to Verizon's 2026 DBIR, and the average supply chain compromise costs $4.91 million and takes 267 days to contain, per IBM's 2025 Cost of a Data Breach Report. 

Most organizations still respond with questionnaires and annual audits. Those have their place. But a questionnaire doesn't stop a breach. Revoking a vendor's standing privileges does. This guide treats supply chain security as what it actually is: an IAM and credential control problem, with a compliance layer on top.

Key takeaways

• Third-party involvement now accounts for 48% of all data breaches — up from 30% the previous year, according to Verizon's 2026 DBIR. Supply chain attacks are the dominant breach vector.
• The average supply chain compromise costs $4.91 million and takes 267 days to contain. That dwell time is what makes standing vendor privileges so dangerous — attackers don't need to move fast if the credentials never expire.
• Every major supply chain incident entered through a trusted relationship. SolarWinds, MOVEit, XZ Utils — in each case, the attacker used access that was already provisioned and already trusted.
• Questionnaires and annual audits don't stop breaches. Revoking standing vendor privileges does. The controls that matter are technical: credential vaulting, JIT access, RBAC scoped to the engagement, and phishing-resistant MFA.
• NIS2, DORA, and the EU Cyber Resilience Act make supply chain security a legal obligation. NIS2 Article 21, DORA Articles 28–30, and CRA requirements apply on a staggered timeline through 2027.
• 70% of the top 50 vendors shared by Global 2000 companies carry at least one unpatched KEV vulnerability, per Black Kite's 2026 Third-Party Breach Report.

What is cyber supply chain risk management (C-SCRM)?

Cyber Supply Chain Risk Management (C-SCRM) is the discipline of identifying, assessing, and mitigating cybersecurity risks that originate from an organization's extended network of suppliers, vendors, service providers, and software dependencies. It covers everything from the SaaS tools your developers use to the managed service provider (MSP) with admin access to your production environment.

C-SCRM sits at the intersection of procurement, IT security, and compliance. NIST SP 800-161 Rev. 1 provides the most detailed federal framework for it, defining C-SCRM as a structured process for managing exposure to cybersecurity risks throughout the supply chain lifecycle — from initial vendor selection through contract termination and access revocation.

The scope is broader than most teams realize. Your supply chain includes:

• Software vendors and open-source dependencies
• Cloud infrastructure and SaaS providers
• Managed service and IT support providers
• Hardware manufacturers and firmware suppliers
• Professional services firms with network or data access

Each of these is a potential entry point. The SolarWinds, MOVEit, and XZ Utils incidents all exploited that entry point in different ways.

The state of supply chain attacks in 2025–2026

Supply chain attacks reached record levels in 2025–2026. Verizon's 2026 DBIR recorded third-party involvement in 48% of all breaches analyzed — the highest in the report's history and a 60% increase over the prior year's 30%. IBM's 2025 Cost of a Data Breach Report puts the average supply chain compromise at $4.91 million, with a 267-day average lifecycle from detection to containment.

Threat actors have learned that compromising one trusted vendor yields access to dozens or hundreds of downstream organizations simultaneously. The economics favor the attacker: one successful intrusion, multiplied across an entire vendor's customer base.

According to Black Kite's 2026 Third-Party Breach Report, 70% of the top 50 vendors shared by Global 2000 companies carry at least one unpatched vulnerability from CISA's Known Exploited Vulnerabilities (KEV) catalog. These aren't theoretical risks — CISA flags KEV entries specifically because they are being actively exploited in the wild.

Lessons from SolarWinds, MOVEit, and XZ Utils

All three incidents share a common thread: the initial access vector was trusted. Trusted software, trusted vendor, trusted contributor. Once inside, the attacker moved laterally using credentials and access that were already provisioned.

SolarWinds (2020)

Attackers compromised the build pipeline directly, inserting a backdoor into a signed software update that went out to customers as a routine patch. Roughly 18,000 organizations installed it. The legal fallout ran for years: the SEC filed a civil enforcement action against SolarWinds and its CISO in October 2023, with the case finally dismissed in full in 2025.

The lesson: software integrity controls and SBOM (Software Bill of Materials) visibility matter as much as network perimeter controls — and the liability exposure from a build pipeline compromise extends well beyond the initial breach.

MOVEit (2023)

A zero-day SQL injection vulnerability (CVE-2023-34362) in a managed file transfer product gave the Cl0p ransomware group access to data held by over 2,700 organizations — many of which had no direct relationship with MOVEit but were affected through their vendors' use of it. Final victim counts reached approximately 95 million individuals. 

The lesson: your attack surface includes software your vendors run, not just software you run.

XZ Utils (2024)

A multi-year social engineering campaign inserted a backdoor into a widely used open-source compression library. The attacker contributed legitimate code for two years before introducing the malicious payload — and the backdoor was caught not by any formal security process, but by a Microsoft engineer who noticed a 500ms delay in SSH logins. 

The lesson: open-source dependency risk is real, SBOMs are the only systematic way to track it, and your detection controls need to cover behavior, not just signatures.

Top vendor risks in the modern supply chain

The five most common supply chain risk categories are:

• Shared credentials and poor access control
• Software dependency vulnerabilities
• Hardware and component tampering
• Shadow AI and third-party data exposure
• Vendor concentration risk

Each requires a distinct control response. Shared credential failures are a process problem. Hardware tampering requires physical provenance verification.

Shared credentials and poor access control

The most common and most preventable supply chain risk is also the least glamorous: shared accounts. A vendor support team gets a single set of credentials to access your environment. Those credentials are shared across the vendor's staff, stored in a spreadsheet or email thread, and never rotated after the engagement ends.

When that vendor is breached, or when a disgruntled employee leaves, you have no way to know who used those credentials, when, or what they accessed. You have no audit trail. You have no way to revoke access for one individual without changing credentials for everyone.

Verizon's 2026 DBIR identifies authentication failures (missing or bypassed MFA, stolen credentials) as the primary mechanism in third-party breach scenarios. This is a process failure.

Software supply chain vulnerabilities and the need for SBOMs

A Software Bill of Materials (SBOM) is a machine-readable inventory of every component in a software product: libraries, dependencies, versions, and their known vulnerabilities. The U.S. Executive Order 14028 (2021) mandated SBOMs for software sold to federal agencies. The EU's Cyber Resilience Act (CRA) extends similar requirements to products sold in the European market, with vulnerability reporting obligations applying from September 2026 and full product requirements from December 2027.

Without an SBOM, you cannot answer "Are we running the vulnerable version of Log4j?" in under 24 hours. With one, you can. That speed difference is the gap between a contained incident and a breach that takes 267 days to close.

Hardware and component tampering

Hardware supply chain risk is distinct from software risk and often underestimated. Counterfeit or tampered components — network equipment, server hardware, firmware — can introduce persistent backdoors that survive OS reinstallation and are invisible to software-layer security controls.

The EU Cyber Resilience Act explicitly addresses hardware products with digital elements, requiring manufacturers to assess and document supply chain security for physical components. For organizations procuring network infrastructure or industrial control systems, this means verifying component provenance, requiring firmware integrity attestation from suppliers, and maintaining an inventory of hardware versions equivalent to a software SBOM.

Shadow AI and third-party data exposure

Verizon's 2026 DBIR identifies shadow AI as a top-three insider behavior — employees using unauthorized AI tools that process organizational data outside approved channels. The supply chain angle: many of these tools are third-party SaaS products with their own data retention policies, subprocessor agreements, and security postures that your organization never reviewed.

When a developer pastes database credentials into an AI assistant to debug a query, those credentials may be retained, logged, or used for model training. The vendor risk is not just the AI provider — it is every subprocessor in their chain.

Availability disruptions and vendor concentration risk

A supply chain security failure does not always mean a data breach. Vendor outages, ransomware attacks on critical suppliers, and single points of failure in shared infrastructure can disrupt operations entirely. DORA's operational resilience mandate exists precisely because the EU financial sector recognized that availability risk from ICT third parties is as material as confidentiality risk.

Concentration risk compounds this: when 70% of Forbes Global 2000 companies share the same top 50 vendors, a single compromise propagates at scale. Mapping your critical vendor dependencies and maintaining documented continuity plans for Tier 1 supplier failures is a DORA Article 28 requirement for financial entities.

European and international regulatory requirements for supply chain security

NIS2, DORA, and the EU Cyber Resilience Act together form the binding regulatory framework for supply chain security in the European market. NIST CSF 2.0 and SP 800-161 are U.S. frameworks — not EU legal obligations — but are widely referenced by multinational organizations and provide operational detail that complements the EU requirements.

NIS2 Directive (Article 21)

NIS2 Article 21 requires covered entities to implement "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." This is a legal obligation for essential and important entities across 18 sectors, with enforcement that EU member states began applying in late 2024.

In practice, Article 21 means you must assess the security posture of your direct vendors, include security requirements in contracts, and maintain a documented process for managing vendor-related incidents. For credential management specifically, this translates to: no shared accounts, documented access provisioning and revocation procedures, and audit logs that can be produced during a supervisory review.

For a detailed breakdown of how NIS2 maps to access control requirements, see Passwork's NIS2 compliance guide.

DORA (Digital Operational Resilience Act)

DORA applies to financial entities and their ICT third-party service providers operating in the EU. Articles 28 through 30 establish a detailed ICT third-party risk management framework, including requirements to maintain a register of all ICT providers, conduct risk assessments before onboarding, and ensure contracts include provisions for audit rights and incident notification.

DORA also introduces the concept of "critical ICT third-party providers" (CTPPs), which the European Supervisory Authorities can designate for direct oversight. If your organization is a CTPP — or relies on one — the scrutiny on your supply chain security controls is substantially higher. The availability disruption risk described above is a DORA concern as much as a security one: Article 28 explicitly requires documented continuity plans for critical third-party dependencies.

EU Cyber Resilience Act (CRA)

The CRA was adopted in 2024 and applies in a staggered timeline. Vulnerability and incident reporting obligations take effect from 11 September 2026. Full product requirements — including SBOM mandates and conformity assessments for products with digital elements — apply from 11 December 2027. Organizations selling connected hardware or software in the EU market need to begin compliance work now; the 2027 deadline arrives faster than most product development cycles allow.

NIST CSF 2.0 and NIST SP 800-161

NIST CSF 2.0, released in February 2024, added "Govern" as a sixth core function. The GV.SC subcategory explicitly addresses supply chain risk management, requiring organizations to integrate C-SCRM into enterprise risk governance — not treat it as a separate IT project. For EU organizations, CSF 2.0 is not a legal requirement but provides useful operational structure that maps well onto NIS2 and DORA obligations.

NIST SP 800-161 Rev. 1 provides the operational detail: how to conduct supplier assessments, what controls to require in contracts, and how to structure a C-SCRM program across the full acquisition lifecycle. For U.S. federal contractors, alignment with SP 800-161 is increasingly a procurement requirement.

How to secure vendor access: The technical blueprint

The four highest-impact controls for vendor access security are RBAC scoped to the engagement, just-in-time privileged access, centralized credential vaulting, and phishing-resistant MFA. Applied in that order, they address the most common failure modes — standing privileges, shared accounts, and authentication gaps — without requiring new infrastructure in most environments.

Enforce strict role-based access control (RBAC)

Role-based access control (RBAC) assigns permissions to roles, not individuals. A vendor support engineer gets the "read-only production monitoring" role, not a personal admin account. When the engagement ends, you remove the role assignment. When the vendor rotates their staff, you don't need to track individual accounts — the role defines what's accessible.

For vendor access specifically, RBAC should be scoped to the minimum required for the engagement. A database vendor performing a performance audit does not need write access to application configuration. Define the role before provisioning access, not after.

Implement just-in-time (JIT) privileged access

Just-in-time (JIT) access means privileged credentials are issued for a defined time window and automatically revoked when that window closes. A vendor engineer requests access for a two-hour maintenance window; the system grants it, logs the session, and revokes it at hour two regardless of whether the engineer remembers to log out.

JIT access eliminates standing privileges: the persistent, always-on access that attackers exploit during the 267-day average dwell time of a supply chain breach. There is nothing to steal if the credentials expire before the attacker can use them. JIT is particularly effective for break-glass scenarios: emergency vendor access during an incident, where speed matters but so does accountability.

Secure vendor credential vaulting

Shared vendor accounts are a liability. The alternative is a credential vault: a centralized, encrypted store where vendor credentials are held by your organization, not the vendor. The vendor authenticates to the vault, checks out credentials for their session, and the vault logs every access event.

This approach gives you a complete audit trail of who accessed what and when, the ability to rotate credentials without coordinating with the vendor, automatic revocation when the vendor relationship ends, and compliance evidence for NIS2 Article 21 and DORA Article 30 audit rights requirements.

Passwork's enterprise password and secrets manager supports time-limited credential sharing, session logging, and integration with AD/LDAP and SSO infrastructure — with AES-256 client-side encryption and a full REST API for integration into existing provisioning workflows.

Mandate phishing-resistant MFA for third parties

MFA is the single highest-ROI control for third-party access. Verizon's 2026 DBIR attributes the majority of third-party breach scenarios to authentication failures — and most of those failures are missing MFA, not bypassed MFA.

For privileged vendor access to production systems, the bar should be phishing-resistant MFA: FIDO2/WebAuthn hardware keys or passkeys, not SMS OTP. SMS-based MFA is vulnerable to SIM-swapping and real-time phishing proxies. Contractually require phishing-resistant MFA from vendors as a condition of access. Include it in your vendor security addendum, not just your internal policy.

Most of the access control failures described in this guide trace back to the same root cause: vendor credentials that were never properly vaulted, scoped, or revoked. Passwork addresses that directly — centralized credential vaulting, role-based access, time-limited sharing, and a full audit log tied to named identities. Available self-hosted or as a cloud deployment, it integrates with AD/LDAP and SAML SSO and is ISO 27001 certified.

Building a vendor risk assessment framework

A vendor risk assessment framework classifies third parties by access level and applies proportionate security requirements to each tier. The 5-tier model below scales from Tier 1 vendors with privileged production access, which require full security assessments and annual reviews — down to Tier 5 vendors with no data or system access, where standard procurement due diligence is sufficient.

The 5-tier vendor risk classification model:

The classification drives proportionate effort. You don't need a full penetration test report from your office supply vendor. You do need one from the MSP with admin access to your Active Directory.

Vendor access control checklist

The following pre-audit vendor access checklist maps directly to NIS2 Article 21, DORA Article 28, and NIST SP 800-161 requirements. Use it at vendor onboarding and at each annual review.

Pre-access provisioning:

•  Vendor classified by tier based on access level
•  Minimum necessary access scope defined in writing
•  Named individuals identified (no shared/generic accounts)
•  MFA requirement confirmed and tested
•  Access provisioned via credential vault, not direct credential sharing
•  Session logging enabled

During the engagement:

•  Access scope reviewed if engagement scope changes
•  Unusual access patterns flagged for review
•  Vendor incident notification clause active in contract

Access revocation:

•  Offboarding trigger defined (contract end, staff change, incident)
•  Credentials rotated immediately on offboarding
•  Vault access revoked and audit log exported
•  Access review documented for compliance records

Conclusion: Making supply chain security operational

Organizations that manage this well don't have fewer vendors; they have tighter controls on how those vendors authenticate, what they can access, and for how long.

The technical blueprint is clear: classify vendors by access tier, eliminate shared accounts, vault credentials centrally, enforce JIT access for privileged sessions, and require phishing-resistant MFA. NIS2, DORA, and the CRA provide the governance structure and the contractual leverage to hold vendors to the same standard.

Start with your Tier 1 vendors — the ones with privileged access to production systems. Audit their current access scope, confirm individual account assignment, and verify MFA is active. That single pass will surface more actionable risk than a year of questionnaires.

Frequently asked questions

What is the difference between supply chain security and vendor risk management?

Vendor risk management (VRM) is the broader discipline covering financial, operational, reputational, and cyber risks from third parties. Supply chain security is the cybersecurity-specific subset: protecting systems, data, and software integrity from threats that enter through supplier relationships. VRM informs procurement decisions; supply chain security governs technical access controls and software integrity.

Which regulations require supply chain security controls in 2025–2026?

NIS2 Directive Article 21 requires EU essential and important entities to assess and manage supplier security risks. DORA Articles 28–30 impose ICT third-party risk management obligations on EU financial entities. The EU Cyber Resilience Act requires vulnerability reporting from September 2026 and full SBOM and conformity requirements from December 2027. In the U.S., NIST SP 800-161 and Executive Order 14028 set C-SCRM expectations for federal contractors.

What is just-in-time (JIT) access and why does it matter for vendor security?

JIT access issues privileged credentials for a defined time window and revokes them automatically when that window closes. It eliminates standing privileges — persistent access that attackers exploit during the extended dwell time typical of supply chain breaches. IBM's 2025 data shows supply chain compromises average 267 days to identify and contain; JIT access reduces the exploitable window to hours, not months.

How do SBOMs reduce supply chain risk?

A Software Bill of Materials (SBOM) is a machine-readable inventory of all software components and their versions. When a new vulnerability is disclosed — such as Log4Shell in 2021 — an SBOM lets you determine within minutes whether any of your systems or vendor-supplied software contains the affected component. Without an SBOM, that same determination can take days or weeks, during which the vulnerability remains unpatched and exploitable.

What should a vendor security contract addendum include?

At minimum: a requirement for named individual accounts (no shared credentials), phishing-resistant MFA for privileged access, notification obligations within 24–72 hours of a security incident, audit rights allowing your organization to review access logs, and a defined offboarding process including credential rotation. NIS2 Article 21 and DORA Article 30 both require contractual security provisions — the addendum is your compliance evidence.

How should organizations classify vendors for risk assessment purposes?

Classify by access level, not by contract value or vendor size. A small consultancy with admin access to your production environment is higher risk than a large software vendor with no direct system access. The 5-tier vendor risk classification model above provides a practical structure: Tier 1 (privileged production access) through Tier 5 (no data or system access), with assessment requirements and review frequency scaled accordingly.

What is the most common access control failure in third-party breaches?

Shared credentials with no individual accountability. A single set of credentials issued to a vendor team, stored outside a vault, never rotated, and never revoked when the engagement ends. Verizon's 2026 DBIR identifies authentication failures as the primary mechanism in third-party breach scenarios. The fix is individual named accounts, credential vaulting, and a documented offboarding process — not more complex technology.

What is hardware supply chain risk and how is it different from software supply chain risk?

Hardware supply chain risk involves counterfeit or tampered physical components — network equipment, server hardware, firmware — that can introduce persistent backdoors invisible to software-layer security controls. Unlike software vulnerabilities, hardware tampering survives OS reinstallation. The EU Cyber Resilience Act addresses this directly, requiring manufacturers to document supply chain security for hardware products with digital elements.

Inside real supply chain attacks: Bitwarden CLI, Axios, and Vercel

Why breach your network when attackers can compromise a trusted dependency with millions of downloads and slip silently into thousands of organizations at once? Three 2026 campaigns prove supply chain attacks are no longer isolated incidents.

Passwork BlogAlex Muntyan

Shadow IT vs Shadow AI: Why AI is the bigger threat

Employees are using AI tools you didn’t approve, on accounts you can’t monitor, with data you can’t recover. Here’s what the risk actually looks like and what governance needs to address.

Passwork BlogAlex Muntyan

NIS2 access controls for supply chain security

48% of breaches now involve third parties. NIS2 Article 21 makes supplier access governance a legal obligation. Here’s how to map vendor access, enforce MFA and least privilege, and keep the audit evidence that proves your controls work.

Passwork BlogAlex Muntyan