The control model breaks because a VPN only proves connectivity, not entitlement to privileged actions. Third-party vendors can reach too much, stay connected too long, and perform work that is difficult to scope or audit. Privileged access needs resource-level authorization, session oversight, and organisation-owned control, not just encrypted network transport.
When VPN connectivity is confused with third-party authorization
A VPN authenticates a network path, but it does not define what a vendor may do once connected. The real break is treating transport as permission: network reach then becomes a proxy for trust, so the third party can often see too much, touch too much, and stay inside too long without the organisation expressing that access in business terms.
That mismatch matters because privileged work is rarely a simple “can connect, therefore can act” problem. Third-party access usually needs a narrower entitlement model, stronger session controls, and ownership that stays with the organisation rather than the vendor’s endpoint, laptop, or support process.
What control assumptions fail first
Two assumptions fail early. First, the VPN boundary is not the same as an authorization boundary, so a connected user may still lack the right to reach a specific application, dataset, or admin function. Second, the connection itself often outlives the task, which makes standing access, dormant sessions, and broad lateral reach more likely than most teams expect.
When access is organised around the network instead of the resource, reviewers lose the ability to answer basic questions: who can reach what, for how long, under which ticket, and with what approval? That is why identity and access governance has to sit above the transport layer, and why third-party access should be tied to named entitlements rather than generic remote connectivity. IAM and IGA Basics provides the underlying distinction between authentication, authorization, provisioning and access review.
Resource scoping matters just as much as session scoping. A vendor who needs one system for one hour should not inherit a path that can be reused against adjacent systems, backup consoles, support tooling or shared admin paths. That is the control gap that makes “ordinary VPN access” unsafe for third parties.
How third-party access should be governed instead
Third-party access works better when the organisation owns the policy, the entitlement, the expiration, and the review cycle. A vendor should receive only the minimum resource-level access needed for the task, with explicit time limits and a clear sponsor inside the business who can approve, renew or revoke it.
This is where federation, least privilege, and time-bounded access become more important than a reusable tunnel. A good design limits the blast radius of a compromised vendor account, reduces the chance of privilege creep, and gives operations teams a defensible record of who was allowed to do what. Third-Party, B2B and Contractor Access Guide focuses on sponsorship, federation, least privilege, time limits and reviews for exactly this reason.
Remote access architecture also needs to separate ordinary connectivity from privileged administration. If the same mechanism is used for file retrieval, support troubleshooting, and administrative action, then auditability and containment both suffer. Remote Access Identity Guide is useful here because it frames VPNs, ZTNA, device posture, and dormant account retirement as part of one access design problem rather than a perimeter problem.
Why this shows up as a security and operations failure
When vendors use ordinary VPN access, incidents often start as a scope problem and end as an investigation problem. The organisation may know a vendor was connected, but not which resources were touched, which commands were run, or whether the activity was consistent with the approved job. That makes containment slower and forensic confidence weaker.
Identity-linked access improves that picture because it can be tied to specific accounts, specific resources, and specific session records. That is also why third-party credential abuse and token misuse are so common in real incidents: once a generic remote path exists, stolen credentials or a reused session can be enough to expand access well beyond the original purpose. Scania insurance portal breach 2025 shows how third-party reach plus stolen credentials can turn a narrow access path into broader data exposure.
For practitioners, the practical warning sign is simple: if the access model cannot answer “which resource, which action, which time window, which owner,” then the VPN is doing too much of the security work. At that point, the control is already too coarse to protect privileged third-party activity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Third-party access needs resource-level privilege limits, not broad network reach. |
| AC-17 — Remote Access | The question centers on remote access being treated as the control, rather than the authorization boundary. | |
| IA-5 — Authenticator Management | VPN-style access often relies on credentials whose lifecycle must be managed for vendors. | |
| Recommendation — Restrict vendor access to the minimum resource scope and action set required. Control remote third-party access with policy, scope limits, and monitoring. Manage vendor credentials with rotation, revocation, and lifecycle discipline. | ||
| NIST Zero Trust (SP 800-207) | PR.AA-05 — Least Privilege Access | Zero Trust directly addresses the gap between connectivity and entitlement. |
| Recommendation — Enforce least-privilege access decisions before granting vendor reach. | ||
Practitioner Guidance
What to prioritise: Replace shared remote connectivity assumptions with named, task-specific entitlements for each vendor role. If a third party needs admin-like actions, treat that as privileged access design, not standard remote access.
What to verify: Confirm that every vendor session has an owner, a scope, and an expiry, and that review evidence exists for renewal or revocation. If you cannot produce that record quickly, the access model is too loose to trust.
Common mistake: Teams keep the VPN and add a few compensating controls, then assume the problem is solved. The better test is whether the organisation can restrict one vendor to one resource and one purpose without relying on network reach as the main guardrail.
Practitioner takeaway: Third-party access should be designed as governed authorization with session oversight, not as generic remote connectivity that happens to be encrypted.
Related resources from NHI Mgmt Group
- What breaks when third-party access is treated like ordinary employee access?
- What breaks when access requests are handled like ordinary support tickets?
- What breaks when third-party privileged access relies on VPN and shared accounts?
- What breaks when AI platform access is managed like ordinary user access?