Third-party privileged access still depends on identity controls

At a glance

What this is: This is an analysis of vendor privileged access management and the key finding is that third-party access remains risky unless it is tightly scoped, authenticated, logged, and deprovisioned.

Why it matters: It matters because third-party access sits across NHI, human IAM, and lifecycle governance, and weak controls here create lateral movement, audit, and offboarding gaps for practitioners.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Leostream's guidance on securing third-party vendor access with VPAM

Context

Vendor privileged access management is the governance pattern for giving third parties only the access they need to perform a task, then proving that the access was constrained, monitored, and removed at the end of the relationship. The problem is that many organisations still extend vendor access with employee-style accounts, VPN connectivity, or shared credentials, which defeats the very controls that privileged access was meant to create.

For IAM teams, the challenge is not limited to external contractors. The same access model touches human identity controls, NHI lifecycle management, and privilege governance because vendor access often lands in shared systems, service accounts, or remote administrative paths. That makes offboarding, session traceability, and least privilege part of the same control set, not separate workstreams.

Key questions

Q: How should security teams control third-party privileged access without opening the whole network?

A: Security teams should broker vendor access to specific applications or sessions instead of granting broad network connectivity. The key is to enforce least privilege at the access path, not just in policy. That means scoped authorization, MFA, logging, and segmentation working together so the vendor can complete the task without gaining unnecessary reach.

Q: Why do vendor accounts create higher audit and offboarding risk than employee accounts?

A: Vendor accounts often exist for a narrower business purpose, but they are frequently managed outside standard joiner-mover-leaver processes. When access is approved quickly and revoked manually, organisations lose visibility into who still has access, where it is active, and whether the relationship has ended. That creates persistent privilege and weak accountability.

Q: What breaks when third-party access uses shared credentials?

A: Shared credentials break attribution, make monitoring less useful, and complicate incident response because logs cannot reliably map actions to a person. They also increase the chance that one contractor’s access becomes another contractor’s implicit trust path. The control failure is not only security, it is governance.

Q: Who is accountable when a vendor retains access after contract end?

A: Accountability sits with the organisation that approved and retained the access, because offboarding is part of access governance, not a separate administrative task. The right frameworks expect access to be removed when the business relationship ends. If it remains active, the organisation owns the exposure even if the vendor never used it again.

Technical breakdown

Why VPN-based vendor access breaks least privilege

VPN access is a network-level trust shortcut, not an identity control. Once a third party lands on the network, segmentation has to do the heavy lifting, and many environments are not designed to constrain access tightly enough after that point. VPAM works differently when it brokers access to specific resources, sessions, or applications instead of handing over broad network reach. That distinction matters because least privilege is only meaningful when scope is enforced at the session and resource level, not just at the perimeter.

Practical implication: replace broad vendor VPN access with task-scoped access paths that expose only the specific application, host, or dataset the vendor needs.

How MFA and unique identities support third-party accountability

Third-party access becomes auditable only when each person can be tied to a distinct identity and a strong authentication event. Shared accounts make it difficult to attribute actions, especially when multiple contractors, suppliers, or support personnel use the same login. That breaks both accountability and incident investigation because the log shows a credential, not a person. Effective VPAM therefore separates identity proofing, authentication, and privileged session access so that administrators can map actions back to an individual rather than a generic vendor account.

Practical implication: require unique vendor identities with MFA and avoid shared administrative credentials for remote support or contract work.

Why session recording is a control, not just a convenience

Recording privileged sessions gives organisations the evidence layer that access grants alone cannot provide. It shows what was touched, what commands were run, and whether the vendor stayed inside the approved task boundary. That evidence is central to detecting data removal, inappropriate file access, or actions that look authorised at login time but are not authorised in practice. In governance terms, session logging turns third-party access from a blind trust exercise into a reviewable control with an audit trail.

Practical implication: make session recording and log review mandatory for all third-party privileged access paths and tie it to incident investigation workflows.

Threat narrative

Attacker objective: The objective is to reach sensitive systems or data through a third-party access path that is difficult to monitor and even harder to revoke cleanly.

1. entry: A third party gains remote access through VPN or another broad connection method that exposes more of the environment than the task requires.
2. escalation: Shared accounts, weak identity binding, or standing privileges let the vendor move beyond the intended scope of access.
3. impact: Insufficient logging and poor offboarding leave the organisation unable to prove what was accessed, by whom, or whether access continued after the contract ended.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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 is a standing risk, not a temporary exception. The article correctly points to contract-end access that remains active, which is a lifecycle failure rather than a tooling issue. The governance problem is simple: third-party access is often provisioned quickly and retired slowly, if at all. That leaves organisations with a privilege state that outlives the business relationship, which is exactly the kind of control gap that the NHI Lifecycle Management Guide is meant to address.

Need-to-know access is only real when it is enforced at the session boundary. A vendor can be told to access only one system, but if the underlying path is a VPN into the broader network, the practical boundary has already been broken. This is where NIST SP 800-207 Zero Trust Architecture matters: the control question is whether the vendor can reach only the approved resource, not whether the organisation wrote that rule somewhere.

Third-party identity is a governance problem, not just an authentication problem. The article emphasises MFA and logging, but the deeper issue is that many organisations still treat external access as an exception to standard identity lifecycle and privilege design. That creates fragmented accountability across IT, security, and vendor management. Practitioners should read this as a call to unify external access governance under one operating model rather than one-off approval paths.

Session evidence is the difference between trust and proof. When third-party activity is recorded, organisations can verify task scope, investigate misuse, and reconcile access with business purpose. That aligns closely with the Ultimate Guide to NHIs , Regulatory and Audit Perspectives because auditability is not an add-on control. It is the mechanism that makes external privileged access defensible.

Third-party access control should be measured by revocation quality, not just approval quality. Many programmes focus on getting access approved, but the harder problem is proving that it was removed everywhere it existed. That includes directories, remote access systems, shared credentials, and any delegated session path. Practitioners should treat revocation completeness as a core governance outcome, not an after-the-fact clean-up task.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• For a broader governance lens, NHI Lifecycle Management Guide helps teams connect access approval, monitoring, and revocation into one lifecycle.

What this signals

Vendor access governance is becoming a lifecycle discipline, not an access-control add-on. As third parties increasingly operate through remote access, shared systems, and delegated administration, security teams need a single view of approval, session control, and revocation. That is the operational shape of NHI Lifecycle Management Guide thinking applied to external users, not a narrow VPN replacement exercise.

The governance gap is often visible long before a breach. A programme that can approve access but cannot prove removal, isolate sessions, or identify which contractor actually performed the work is already underpowered. Teams should expect auditors and incident responders to ask for evidence, not just policy, and should design their third-party controls around that expectation.

Identity blast radius: the smaller the granted access, the easier it is to defend the organisation when a vendor path is abused. That is why task-scoped access, session recording, and enforced revocation matter together. The practical signal is simple: if a contractor can still reach anything useful after the job ends, the blast radius is too large.

For practitioners

• Remove broad VPN access for third parties Route external users through task-scoped privileged access paths that expose only the application, host, or dataset needed for the work. Avoid network-wide entry that makes segmentation responsible for controls it cannot reliably enforce.
• Require unique identities and MFA for every vendor user Bind each contractor or supplier user to an individual identity, then enforce MFA before privileged sessions are created. Do not permit shared logins for support, maintenance, or contract work because attribution and accountability collapse immediately.
• Record and review every privileged session Enable session recording for all third-party administrative access and route logs into normal security review and incident response processes. Use the recordings to verify scope, detect inappropriate access, and support forensic reconstruction if needed.
• Make offboarding a control, not a ticket Tie contract end dates and vendor relationship changes to automatic removal of access from directories, remote access tools, and any shared administrative path. Validate that the account, not just the login, has been fully revoked.

Key takeaways

• Third-party privileged access fails when organisations confuse network connectivity with identity governance.
• The risk is measurable in missing visibility, weak attribution, and access that outlives the contract.
• The control that changes the outcome is lifecycle-managed, session-scoped access with mandatory revocation and review.

Key terms

• Vendor Privileged Access Management: Vendor Privileged Access Management is the control model for giving third parties only the access needed to perform a defined task, then removing it when the work ends. It combines identity proofing, authentication, session control, logging, and offboarding so external access stays narrow and accountable.
• Session Recording: Session recording is the capture of privileged user activity during a remote or administrative session. It provides evidence of what a third party accessed or changed, which is essential when the organisation needs to prove scope, investigate misuse, or reconstruct an incident after the fact.
• Lifecycle Offboarding: Lifecycle offboarding is the process of removing access when a relationship, role, or contract ends. For third parties, it must cover directories, remote access tools, shared credentials, and delegated sessions so that expired business relationships do not leave behind active privilege.
• Identity Blast Radius: Identity blast radius is the amount of damage that a single account, token, or access path can cause if misused. In third-party access programmes, it is reduced by limiting scope, separating identities, and ensuring that access cannot expand beyond the approved task or session boundary.

What's in the full article

Leostream's full article covers the operational detail this post intentionally leaves for the source:

• Practical guidance on using VPAM to isolate third-party access from customer financial records, patient information, and other sensitive resources.
• Control mapping to CIS Controls v8, NIST 800-53, and ISO 27001 for teams that need audit-ready alignment language.
• Examples of how MFA, request-approval workflows, and session logging combine in a vendor access model.
• Vendor-oriented deployment considerations for teams that want to secure remote contractor access without relying on broad VPN connectivity.

👉 The full Leostream article covers access isolation, MFA, logging, and audit alignment for vendor sessions.

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.