Vendor access governance is failing where third and fourth parties meet

At a glance

What this is: This recap argues that vendor access governance breaks down when third- and fourth-party access is broad, untracked, and weakly audited.

Why it matters: It matters because IAM, PAM, and NHI teams all inherit the same problem: external access must be time-bound, least-privilege, and traceable across the full supply chain.

👉 Read Imprivata's analysis of vendor access risks and third-party governance

Context

Vendor access management is an identity problem as much as a procurement problem. Once a third party can reach systems or sensitive data, the organisation has created a non-human access path that must be governed like any other privileged identity, including scope, duration, accountability, and offboarding.

The article’s central point is that third-party risk does not stop at the first supplier. Fourth-party dependencies, dormant accounts, and broad VPN-style access all widen the attack and audit surface, which is why data mapping and lifecycle control matter more than checkbox compliance.

Key questions

Q: How should security teams govern third-party access in supplier-heavy environments?

A: Security teams should govern third-party access as a lifecycle, not a one-time exception. Every external identity should have a named owner, a defined purpose, least-privilege scope, and an expiry tied to the contract or task. Sessions should be auditable, and dormant access should be revoked automatically when the business need ends.

Q: Why do fourth-party vendors increase identity governance risk?

A: Fourth-party vendors increase risk because control and visibility weaken as access moves further from the organisation that owns the data. Security requirements can disappear between contract layers unless pass-through obligations, audit rights, and notification duties are enforced. The result is more opaque privilege, weaker accountability, and harder incident response.

Q: What breaks when vendor access is not tied to offboarding?

A: When vendor access is not tied to offboarding, dormant accounts and forgotten entitlements remain active after the relationship has ended. That creates standing exposure, increases the chance of misuse, and makes investigations harder because access no longer reflects current business intent. Revocation must be automatic and contract-linked.

Q: Who is accountable when a supplier or subcontractor misuses access?

A: Accountability should be assigned in layers. The organisation owns the data and the access decision, the direct vendor owns enforcement of the agreed controls, and subcontractors must be bound through pass-through obligations. If those obligations are not explicit, accountability becomes ambiguous and enforcement usually fails.

Technical breakdown

Third-party access becomes NHI governance when identities are shared

When a vendor connects to your environment, the security question shifts from vendor trust to identity control. Every external session should map to a named identity, a defined purpose, and a bounded entitlement set. Shared accounts, inherited access, and broad network reach remove the ability to attribute action or enforce least privilege. In practice, this is NHI governance because the organisation is managing non-human access paths that can outlive the original business need. The technical failure is not only lack of authentication, but lack of identity lifecycle control across the relationship.

Practical implication: require named, scoped identities for all third-party access and retire shared accounts from production pathways.

Pass-through obligations are the control point for fourth-party exposure

Fourth-party risk appears when your supplier delegates work to another provider, but your governance model still assumes the first contract is enough. Pass-through obligations close that gap by forcing the third party to carry your security requirements down its own chain. That matters for encryption, audit rights, breach notification, IAM, and RBAC because each added layer can inherit privilege without inheriting accountability. Without explicit contractual transfer of control requirements, the organisation loses visibility exactly where the access chain becomes most opaque.

Practical implication: require contract language that extends security, audit, and notification duties to subcontractors before access is granted.

Time-bound access and offboarding are the difference between review and exposure

The article’s offboarding message is straightforward: access must expire when the contract ends or the work stops. That is a lifecycle control, not a documentation exercise. If access remains after the commercial relationship changes, dormant credentials become standing exposure, especially in long-running vendor relationships. Automation helps because manual revocation is easy to miss, but the design principle is more important than the tool: the entitlement must track the business term. This is the same failure mode seen in many external access incidents, where access outlives the justification for it.

Practical implication: align access expiration with contract timelines and automate revocation when work, payment, or renewal changes.

Threat narrative

Attacker objective: The attacker aims to use trusted external access paths to move through supplier-linked identities, access sensitive data, and widen the breach footprint.

1. Entry occurs when a third-party vendor is granted broad access through VPNs, shared accounts, or excessive entitlements that are difficult to scope precisely.
2. Credential abuse or escalation follows when those permissions are not tied to a named identity, allowing activity to blend into normal vendor operations without strong accountability.
3. Impact occurs when dormant access, fourth-party exposure, or weak monitoring expands the blast radius of a breach, complicating incident response and data containment.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Vendor access without lifecycle offboarding: This article shows that the core governance failure is not vendor access itself, but access that survives the business need. Third-party and fourth-party relationships change, yet entitlements often remain open because ownership, renewal, and termination events are not wired into identity controls. The implication is that external access should be governed as a lifecycle, not as a one-time approval.

Third-party risk becomes NHI risk the moment a vendor identity can act in your environment: Once a supplier session reaches cloud, data, or privileged infrastructure, the organisation is managing a non-human identity with all the usual problems of scope, auditability, and over-privilege. The practical distinction is that this identity is outside your employee lifecycle but still inside your control plane. That is why NHI governance and vendor risk management should converge.

Identity blast radius: Broad vendor access turns a single supplier relationship into a multi-system exposure problem. The article’s emphasis on data mapping, named identities, and audit trails is really about reducing how far one compromised external account can travel. When the identity boundary is vague, incident response becomes slower and containment becomes less certain. Practitioners should treat every external entitlement as a potential blast-radius multiplier.

Contract language only works when access enforcement follows it: Pass-through obligations, audit rights, and indemnity clauses matter, but they do not create security on their own. The article correctly ties legal terms to access controls and monitoring because governance fails when contracts and entitlements drift apart. The implication is that supplier management must be measurable in identity terms, not only in procurement terms.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to Oasis Security & ESG.
• That is why lifecycle control belongs in the same operating model as vendor governance, and why practitioners should also compare their programme against the NHI Lifecycle Management Guide.

What this signals

Third-party identity risk is now a lifecycle problem, not a procurement checkbox: Organisations that treat vendor access as a point-in-time approval tend to miss the real failure mode, which is entitlement persistence after the business need changes. The practical shift is to connect contracts, access reviews, and offboarding into one control path.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security, external access governance is already operating with incomplete inventory in many environments. That makes named identities, auditability, and expiry controls more important than broad trust relationships.

Identity blast radius: The next maturity step for vendor governance is not simply more due diligence, but better traceability across the entire access chain. Teams that already understand the Top 10 NHI Issues will recognise this as the same over-privilege and visibility problem appearing in supplier form.

For practitioners

• Map every external identity to a business purpose Inventory which vendors, tools, and subcontractors can reach sensitive systems, then document what data they touch, why they need it, and how long that access should last.
• Write pass-through security duties into supplier contracts Require subcontractor coverage for encryption, audit rights, breach notification, and access constraints so the first vendor cannot offload your controls onto an ungoverned fourth party.
• Replace broad network access with purpose-bound sessions Move away from VPN-style reach and define minimum necessary access for each vendor task, with named identities, term limits, and explicit approval for any extension.
• Tie offboarding to contract expiry and inactivity signals Automate revocation when a contract ends, when a vendor role changes, or when access goes unused beyond an agreed threshold, and require re-approval for reinstatement.
• Audit vendor sessions for traceability, not just presence Confirm that logs show who accessed what, when, why, and whether data moved, so investigations can reconstruct activity across both the third party and its subcontractors.

Key takeaways

• Vendor risk becomes an identity issue once external access is broad, persistent, or hard to attribute.
• The evidence points to a structural visibility problem, not a documentation problem, because access often outlives the business relationship.
• Practitioners should align contracts, lifecycle controls, and audit trails so third-party access expires, traces cleanly, and cannot spread through subcontractors unchecked.

Key terms

• Third-party risk management: Third-party risk management is the discipline of governing the security, compliance, and operational exposure created by external suppliers. In identity terms, it means controlling who can access what, for how long, and under what contractual and monitoring conditions.
• Fourth-party risk: Fourth-party risk is the exposure created by a vendor’s own suppliers, subcontractors, or service providers. The organisation may not contract with those parties directly, but their access, failures, or breaches can still affect data, operations, and accountability.
• Pass-through obligation: A pass-through obligation is a contract requirement that forces a direct supplier to impose your security and compliance terms on its own subcontractors. It matters because access chains often become weaker and less visible as they move away from the organisation that owns the data.
• Identity blast radius: Identity blast radius is the amount of damage a compromised identity can cause before detection and containment. In vendor environments, the radius grows when access is broad, poorly scoped, or not linked to named identities and lifecycle events.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Imprivata: vendor access risks, fourth-party exposure, and best practices for third-party risk management. Read the original.