How should security teams control third-party vendor access without relying on shared logins or VPNs?

How to replace shared vendor logins with individual accountability

The core shift is from “a vendor” to “a named person acting for a vendor.” Each contractor, support engineer, or partner admin should authenticate as themselves, then receive only the narrow access needed for the task. That model preserves accountability, supports least privilege, and gives security teams a defensible audit trail when access is reviewed or revoked.

That is also where purpose-built vendor access management differs from ad hoc remote access. Instead of handing out a shared account or exposing a broad network path, the control plane should bind access to an individual, a task, and a time window.

For teams designing the pattern, the practical requirement is not just stronger sign-in, but stronger identity governance. The access path should be owned, approved, and time-bound, so the same session can be traced back to one person and one authorisation decision.

Why VPN replacement matters for third-party risk

VPNs tend to expand trust too far for third-party use because they expose a wider internal network than the task actually requires. A vendor access model should shrink that blast radius by brokering access to specific applications or hosts rather than placing the vendor on the network.

That matters because third-party access is often both temporary and high-privilege. When the connection is narrower, a stolen credential or compromised laptop has less room to move laterally, and the organisation can remove access cleanly at the end of the engagement.

Strong session controls also improve supervision. When the environment records who connected, what they touched, and when the session ended, security teams can investigate much faster than they can with a generic VPN tunnel.

What good vendor access controls should include

A good implementation combines identity, authorisation, and session control. The vendor should sign in with MFA, the requester should be individually sponsored or approved, and the resulting session should be limited to the target system or application rather than the full network.

In practice, that means using scoped access, short-lived sessions, and explicit approval workflows. For privileged work, session brokering and recording add an additional control layer because they let security teams observe commands, block unsafe actions, and reconstruct what happened if something goes wrong.

• Use named user accounts for every vendor operator.
• Require MFA at sign-in and re-authenticate for sensitive actions.
• Grant access to the target resource, not the corporate network.
• Set time limits and remove access automatically when the task ends.
• Record and review privileged sessions where administrative action is possible.

That operating model is more sustainable than trying to harden shared logins after the fact. It also makes offboarding, emergency revocation, and periodic access review much cleaner.

Risk and Threat Considerations

Shared logins and broad VPN access create avoidable exposure because one compromise can inherit everyone’s access and make attribution nearly impossible. They also make third-party abuse harder to detect, since unusual activity blends into legitimate vendor traffic.

Failure mechanism: A shared credential, token, or VPN account is stolen, reused, or forwarded, then the attacker inherits the vendor’s effective access without needing to defeat an individual approval chain. Broad network reach can then turn a single foothold into lateral movement.

Impact: The organisation loses accountability, cannot reliably prove who performed a given action, and may expose internal systems far beyond the specific support task. Remediation is slower because teams must revoke shared access paths, not just one person’s session.

Practitioner Guidance

What to prioritise: Start with the highest-risk vendors, especially those that can reach production, administrative consoles, or customer data. Those are the sessions where named-user access and session recording deliver the most value first.

What to verify: Confirm that every vendor session maps to a real individual, an approved request, and a specific target system. If the control cannot answer those three questions quickly, it is still behaving like a shared access model.

Common mistake: Replacing a VPN with another broad remote access path and calling it a fix. The real win comes from narrowing scope, shortening session life, and making each action attributable.

Practitioner takeaway: The objective is not to make vendor access slower, it is to make it specific enough that speed does not come at the cost of auditability, containment, or clean revocation.

Related resources from NHI Mgmt Group

• How should security teams implement just-in-time access for third-party users without relying on VPNs?
• How should security teams control third-party contractor access without relying on traditional VDI or unmanaged laptops?
• How should security teams control third-party access in cloud environments without breaking operations?
• How should security teams restrict third-party access without breaking essential vendor workflows?