TL;DR: Third-party privileged access programs still fail when VPN access, shared accounts, weak MFA, and poor logging are used instead of scoped, auditable controls, according to Leostream. The real issue is not whether vendors can connect, but whether identity, session, and offboarding governance can contain the access they receive.
NHIMG editorial — based on content published by Leostream: Securing third-party vendor access with privileged access management
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Leostream's guidance on securing third-party vendor access with VPAM →
Vendor privileged access management: what IAM teams need to know?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Third-party privileged access still depends on identity controls