Notifications
Clear all
Topic starter
08/07/2026 7:00 pm
TL;DR: Third-party privileged access remains risky when vendors mishandle credentials, overstay their access, or operate without auditable session controls, according to Leostream’s summary of Small World Big Data’s analysis. Traditional VPN-based access no longer fits privileged external access, and VPAM shifts the control point to explicit, monitored, least-privilege access.
NHIMG editorial — based on content published by Leostream: Fully Securing Third-Party IT Vendor Access
By the numbers:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
Questions worth separating out
Q: How should security teams govern third-party privileged access without relying on VPN trust?
A: Use identity-aware access flows that constrain vendors to the minimum resources needed, require internal approval, and record the session for later review.
Q: Why does third-party privileged access create the same risk pattern as standing NHI privilege?
A: Both problems appear when access is granted without tight scope and then allowed to persist beyond the task that justified it.
Q: What do security teams get wrong about remote access for vendors and contractors?
A: They often treat connectivity as if it were authorisation.
Practitioner guidance
- Replace VPN-based vendor access for privileged use cases Move third-party admins and contractors onto governed access flows that issue narrow, task-specific access and keep the organisation in control of the session.
- Require internal approval ownership for every external session Make your security or IAM team, not the vendor, approve access requests, define scope, and own revocation for each privileged engagement.
- Record and review all privileged vendor sessions Capture logs, command history where possible, and full session evidence so that external activity is auditable after the fact and usable for incident response.
What's in the full report
Leostream's full analysis covers the operational detail this post intentionally leaves for the source:
- The report's feature-by-feature VPAM requirements for session control, approvals, and auditability.
- The vendor framing around how the service supports temporary third-party access without requiring software on contractor devices.
- The full set of analyst criteria used to judge whether a remote access model is acceptable for privileged external work.
- The deployment discussion for running the service alone or alongside the broader remote desktop platform.
👉 Read Leostream's analysis of third-party privileged access and VPAM →
Third-party privileged access: is VPN still the wrong model?
Explore further
08/07/2026 7:23 pm
VPN access was designed for connectivity, not for delegated privilege governance. That assumption fails when a third party needs temporary access to sensitive systems but the organisation still treats network reach as an acceptable proxy for authorisation. The implication is that privileged third-party access has to be governed as an identity problem, not a transport problem.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who should own approval and revocation for external privileged sessions?
A: The organisation should own both approval and revocation, usually through IAM, PAM, or security operations, because accountability has to stay inside the control boundary. Vendors should request access, but they should not control the scope, lifecycle, or audit trail of their own privileged sessions.
👉 Read our full editorial: Third-party vendor access needs zero-trust VPAM, not VPN trust
