Third-Party Remote Access: The Quiet Breach Path Into Hospitals

Dozens of vendors hold standing remote access to hospital systems, most of it installed at commissioning, shared, permanent and unmonitored. Brokering it without stopping support.

GuardsArm Team

Security Experts

November 25, 2025

Third-party remote access

A mid-sized hospital typically has dozens of vendors with remote access to internal systems — the EHR vendor, the imaging provider, laboratory instruments, pharmacy automation, building management, the dictation platform. Most of it was installed during commissioning, uses a shared account, is always on, and nobody is watching it.

It is one of the most reliable initial access paths into healthcare, and it is invisible on most asset inventories because it is a connection rather than a system.

Dozens of vendors

Each with a path in, most installed years ago

Shared credentials

One account used by whichever engineer picks up the ticket

Always on

Standing access that exists whether or not support is in progress

Inventory by evidence

Vendors will not tell you and documentation is incomplete. Find the connections:

Firewall rules permitting inbound from external addresses, and outbound persistent tunnels
Remote access tools installed on servers and clinical workstations — TeamViewer, AnyDesk, LogMeIn, vendor-specific agents
VPN accounts not tied to an employee
Accounts with a vendor name in the directory
Accounts payable — every supplier under a support contract is a candidate
Ask biomedical engineering, who commissioned much of it

Record per connection: vendor, what it reaches, method, who authorises, whether it is always on, whether sessions are logged, and whether a contract covers it.

Outbound tunnels are the ones you miss

Inbound rules are visible in the firewall. A vendor agent that dials out and holds a persistent connection looks like ordinary outbound traffic. Check what is installed on the endpoint, not just what the perimeter permits.

The target model

The vendor still gets support access. What changes is that it exists only while needed.

Concretely:

Named individual accounts, never shared. If three engineers support you, that is three accounts.
MFA enforced, no exceptions for vendors
Just-in-time: access opens on an approved request and closes automatically
Brokered through a jump host rather than direct to the target system
Session recording for anything touching clinical systems or PHI
Scoped: the imaging vendor reaches imaging systems, nothing else

Handling the "our tool or no support" argument

Some vendors insist on their own remote access product as a condition of support. Options, in order of preference:

Position	Approach
Best	Their tool runs inside your brokered session, reaching only the target
Good	Their tool permitted but disabled by default, enabled per request
Acceptable	Their tool always on, but network-restricted to specific hosts and fully logged
Unacceptable	Always on, unrestricted, shared credential, unlogged

Most vendors accept the second or third when asked directly. The first conversation is usually with a support engineer who will say no; the second, at account-management level and near renewal, usually goes differently.

Put it in the contract

Retrofitting is negotiating from weakness. New contracts and renewals should specify: named accounts, MFA, access on request rather than standing, session recording, notification of engineer departures, and scope limited to the supported system. Add it to the procurement template so it arrives by default.

This is the same principle applied to devices in IoMT security, and to identity in contractor identity governance.

Monitoring what you cannot yet broker

Brokering every connection takes months. In the meantime, these are worth alerting on and cost little:

Vendor account authentication outside a support window — if there is no open ticket, ask why someone connected
Access from a new source country or ASN for an established vendor
Lateral movement from a vendor jump point to a system outside their scope
Out-of-hours sessions, which are legitimate but should be visible
A vendor account used after the contract ended, which should be impossible

The first of these is the highest yield. Correlating vendor logons against open support tickets is straightforward and reliably finds connections nobody requested.

Ask vendors to tell you when engineers leave

A named vendor account should be disabled when that engineer moves on, and you will not know unless the contract requires notification. Without it, named accounts drift back toward shared ones as credentials are passed along informally.

Where to start

List every remote access tool installed across your servers and clinical workstations. Not firewall rules — installed software. Most hospitals find at least one they cannot account for, and that single list usually justifies the brokering project on its own.

GuardsArm inventories and re-platforms vendor remote access in clinical environments. Book a scoping call.

Topics

Written by GuardsArm Team

Our team of cybersecurity experts brings decades of combined experience in penetration testing, compliance auditing, and incident response. We're dedicated to helping organizations strengthen their security posture.