The firewall vendor’s engineer needs to reach one appliance on Thursday. The accounting package’s support team needs to look at one database next month. Neither of them needs your network, but the easiest thing to hand out is a VPN account, so that is what they get, and it is still active a year later.
Why a VPN account is more than the job needs
A VPN is built to make a remote machine behave as if it were on your network. That is the right design for an employee who uses file shares, printers and half a dozen internal tools. It is the wrong shape for a contractor who needs one system for two hours.
There is also the VPN server itself. CISA’s alert on VPN hardening says that “remote-access VPN servers allow off-site users to tunnel into protected networks,” and that this makes “these entry points vulnerable to exploitation by malicious cyber actors.” A VPN does not remove your exposure. It concentrates it on one device that has to be patched and watched.
None of this means a VPN is forbidden. It means the vendor question is really two questions: how much can they reach, and how much new exposure do you create to let them in?
What good vendor access looks like
The security guidance does not name a single product. It does agree on the properties.
- One resource, not a network. NIST SP 800-207 says zero trust “focuses on protecting resources (assets, services, workflows, network accounts, etc.), not network segments,” and assumes no implicit trust based on network location.
- Check first, then connect. In the same document, “authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established.”
- MFA on every vendor account. CISA’s advisory on managed service providers says contracts “should also require MFA to be enforced on all MSP accounts used to access customer environments.”
- Least privilege, applied on both sides. The same advisory says customers should ensure the provider applies the principle “to both provider and customer network environments.”
- Visibility. Customers should verify “via audits, that MSP accounts are being used for appropriate purposes and activities.”
- An end date. Customers should “disable MSP accounts that are no longer managing infrastructure.”
That advisory is written about managed service providers, but the reasoning carries over to any outside party with a login to your systems: a vendor with a standing account is a second front door that you do not control.
Four ways to do it
| Approach | Vendor reaches | What you still have to defend | Fits when |
|---|---|---|---|
| Gateway or published application (for example RD Gateway) | One application or desktop | A public gateway: patching, certificates, MFA | Windows desktops and apps |
| Identity-aware access service (zero trust network access) | Individual applications, per session | The service’s policy, and the vendor’s identity | Web apps and many internal tools |
| Broker with no inbound listener | One server or database, per approved session | The broker, the approval workflow and session logs | SSH, RDP and database administration |
| VPN with a restricted account | Whatever the account’s rules allow | The VPN server, firewall rules for that account | The vendor already needs network-level reach |
Two notes on the table. First, Microsoft is explicit that RD Gateway “enables secure, encrypted connections to Remote Desktop Services (RDS) resources over the internet” and that users can access internal resources “without the need for a VPN”. Microsoft also says the role “is supposed to be public”, so the exposure moves to the gateway rather than disappearing. Second, the “Fits when” column is our judgement, not a standard. Check it against your own systems.
A checklist before you grant anything
- Name the system and the task. If you cannot describe the access in one sentence (“restart the billing service on app01”), it is too broad.
- Find out what is already open. CISA asks organizations to check whether “integrators, managed security services providers (MSSPs), vendors, or other third parties have remote access to your systems or networks.” Start there.
- Close ports you cannot justify. CISA’s guidance is to “close or restrict access to ports that do not have a documented operational need.” A vendor’s convenience is not a documented need.
- Require MFA on the vendor’s account, and put the requirement in the contract.
- Set an expiry when you grant access, not afterwards.
- Log what the vendor does, and decide who reads the log. A recording nobody reviews protects no one.
- Review on a schedule. CISA says both providers and customers “should periodically review their internet attack surface and take steps to limit it.”
Where SSHepherd fits
If the vendor needs to administer a server, a database or a file-transfer endpoint, SSHepherd® is built for exactly that shape of access. It closes the listening port on the server. The server and the person connecting each go outbound to a broker, which joins them for authorised identities only. Sessions can be monitored, recorded and ended on demand, and a server can be protected in about ten minutes without changing your network design. It is a fit for server administration, not for giving someone a browser-based tool or a file share. For that, look at an identity-aware access service. Details are on the SSHepherd page and the Linux SSH use case.
The bottom line
A vendor needs a door to one room for a fixed time, not a key to the building. Pick a method that scopes access to a single system, put MFA and an approval step on it, record the session, and set the expiry on the day you grant it.