Vendor Access and Standing Connections
Suppliers install their own tools and keep their own doors. What to ask for instead, and what to do about what is already there.
Equipment vendors, software suppliers and outsourced providers all arrange remote access to support what they sold. Those arrangements are rarely inventoried and almost never reviewed.
The support work behind “Vendor Access and Standing Connections” is often spread across tickets, projects and handoffs. Teams researching key person dependency can use reducing key-person dependency risk to connect time and project context with that work, while the remote-support platform remains the source of truth for technical actions and session access.
What gets installed
The vendor's own support agent, connecting outbound to their infrastructure.
For an independent reference related to “Vendor Access and Standing Connections”, consult the NCSC security guidance; it provides a useful external check on security, privacy and operating assumptions before a process is adopted.
A dedicated appliance or jump host, supplied by them.
A persistent connection established at commissioning and never examined.
Or a firewall rule opened for an engineer years ago.
Why it is hard to see
Outbound connections do not look like exposure.
The access was arranged by whoever bought the equipment, not by whoever runs security.
And it sits with the system it supports: in a plant room, a clinical area, a production line, where nobody doing access reviews is looking.
The questions to ask of each vendor
How do you connect, and to what?
Who at your organisation can use it, and how do you control that?
Is it available continuously or on request?
What do you log, and will you share it?
And who actually performs the support — you, or a subcontractor?
What to ask for instead
Access through your gateway, with accounts you issue.
Enabled on request, expiring automatically.
Supervised where the system is sensitive.
Logged where you can read it.
Several vendors will agree to this if asked and none will offer it, which is the practical point.
The operational-technology case
Industrial, building and medical systems frequently come with vendor access as a condition of the support contract.
These are the connections with the greatest consequence and the least oversight.
Treat them as the priority of any review, rather than the corporate ones which are usually better controlled.
Finding what exists
Ask every system owner who supports their system and how that support connects.
Not the network team, who will not know.
This is a conversation exercise rather than a scanning one, and it reliably finds connections nobody had recorded.
At contract renewal
The moment of leverage.
Specify the access model in the contract: your gateway, your accounts, time-bounded, logged, notification of their staff changes, removal at termination.
Retrofitting mid-term is harder and sometimes impossible.
What to do about what is already there
Inventory first, then prioritise by consequence.
Remove what is dormant.
Negotiate what is needed.
And accept, explicitly and in writing, what cannot be changed, which is better than leaving it undocumented.
What to check
Do you have a list of vendor connections into your environment?
Which systems have vendor access as a contract condition?
Is any of it time-bounded?
And do you know who actually connects when a vendor supports you?