PAM5 min read

Third-party access: when your security depends on someone else’s

The consultant who finished six months ago still has VPN access. The support vendor logs in with a shared account, and nobody on your side can see who is using it. Third-party access has become one of the most exploited ways in – because it is rarely anyone’s responsibility.

The problem

The access that comes with the contracts

Every organisation of a certain size has external parties inside its systems: consultants on projects, managed service providers with remote access, support agreements that let the vendor log in and troubleshoot. The access is created when the agreement is signed – quickly and pragmatically, because the work needs to start.

But where your own employees have a manager, an employment relationship and an offboarding process that closes their access, the vendor’s access follows the lifetime of the contract in theory and nothing in practice. Consultants change at the vendor without you being told. The project ends, but the VPN profile lives on. And one of the best-known data breaches in history started exactly there: the attackers got into the US retailer Target through the refrigeration contractor’s access.

The risk

The typical gaps

Shared accounts: the vendor has one account used by an unknown number of their employees – you have no idea who, and often neither does the vendor.
Access that is too broad: the VPN connection reaches the entire network even though the task requires a single system.
No expiry: the access is created without an end date and outlives the project, the contract and sometimes the vendor itself.
No owner on your side: no internal person is responsible for confirming that the access is still needed.
No traceability: when something goes wrong, nobody can document who was logged in and what was done.

The same disciplines as for your own staff – and then some

The ground rules are familiar: every external person has their own account, every access has an internal owner and an expiry date, and the access covers only the systems the task requires. Recertification at fixed intervals ensures the owner actively confirms the need – and that access without an owner or without activity gets closed.

For privileged vendor access, typically operations and support, just-in-time should be the standard: the vendor requests access for the specific task, receives it for a limited period, and the session is logged or recorded. That protects you, and it gives the vendor documentation of what they actually did.

The requirements also come from outside: both NIS2 and DORA set explicit requirements for governing vendor access, and your customers increasingly ask you the same questions you should be asking your vendors.

Where should you start?

With a list of your external parties and their access – it rarely exists up front. Review VPN profiles, remote access solutions and accounts that do not belong to your own employees, and ask for each one: who owns it, when was it last used, and why does it exist?

Close the dead access immediately, put expiry dates and owners on the rest, and introduce individual accounts where accounts are shared today. It is one of the places where a few weeks of work removes the most risk.