The threat hiding in plain sight
Every security team dreads the phishing call. Awareness training, simulated attacks, email filtering the industry has invested billions in combating the rogue link in the inbox. And yet, in practice, the breach that keeps CISOs up at night rarely begins with a rogue email. It begins with an HVAC technician who finished a job eighteen months ago and whose VPN credentials were never revoked.
Third-party vendor access is one of the most underaudited attack surfaces in healthcare IT. Vendors need in to troubleshoot building systems, update medical device firmware, perform routine maintenance on lab information systems, or support clinical software remotely. IT obliges, provisions access, and the ticket closes. What rarely happens next is the deprovisioning.
The result is a slow accumulation of dormant accounts each one a potential entry point attached to systems that haven’t been actively monitored in months or years. In an industry where a single breach can compromise patient safety, expose protected health information, and trigger federal investigations, this is not an acceptable risk posture. And yet it remains one of the most common findings in vendor risk assessments across mid-sized health networks.
Why vendor access is uniquely dangerous
Unlike an employee account, vendor access is almost always provisioned under pressure. A critical system is down. A biomedical device is offline. A lab interface has stopped transmitting results. The vendor technician is on the phone, the clock is running, and speed wins over process every time.
What follows is predictable: the account gets broader permissions than the task actually requires. It is often tied to a shared team credential one username and password used by every technician at that vendor company rather than an individual. No expiry date is set because no one knows exactly how long the work will take, and it feels easier to clean it up later. Later never comes.
When that vendor’s own systems are compromised through their phishing, their breach, their disgruntled former employee attackers inherit whatever trust the hospital extended. In a flat or poorly segmented network, that inherited trust can reach patient records, clinical devices, billing systems, and backup infrastructure in minutes. The attacker does not need to exploit a single vulnerability. They simply log in.
This is the model that ransomware groups have refined over the past several years. Rather than burning zero-days on hardened perimeters, they target the supply chain. They compromise a small HVAC contractor, a medical imaging support company, or a regional EHR reseller organizations with far fewer security resources and use those footholds to pivot into the hospitals those vendors serve. The hospital’s firewall never triggers. The SIEM never fires an alert. The attacker is, from the network’s perspective, a trusted user doing their job.
The anatomy of a vendor-borne breach
Understanding how these incidents unfold helps clarify why standard detective controls so often fail to catch them in time.
It begins with the vendor compromise often months before the hospital is affected. The vendor’s own credentials are stolen, their systems infected with an infostealer, or their remote access solution exploited. The attacker now has a list of targets: every organization that vendor has credentials into.
They then conduct reconnaissance. Using the vendor’s credentials, they log into the hospital’s VPN or remote desktop environment during off-hours. Because the account has legitimate historical activity, anomaly detection based on user behavior is unlikely to fire. They move quietly, mapping the network, identifying high-value systems, and locating backup infrastructure.
Only then often weeks later do they deploy ransomware, exfiltrate data, or both. By the time the hospital’s security team realizes something is wrong, the attacker has had ample time to ensure that backups are encrypted, that persistence mechanisms are in place, and that the negotiating position is as weak as possible.
The entire intrusion path ran through a forgotten vendor account that no one thought to disable.
Three controls that close the gap
None of the following require cutting-edge tooling or six-figure platform investments. They require policy, enforcement, and a willingness to make vendor access slightly less convenient in exchange for significantly less risk.
Control 01 — Just-in-time access
Vendor accounts should not exist in a persistent, enabled state. The model should be inverted entirely: accounts are off by default, and access is provisioned on request for a defined window typically two to four hours for a routine support session, longer for scheduled maintenance with documented justification.
When the window expires, the account is automatically disabled. No manual cleanup required, no reliance on a technician remembering to close the ticket, no drift between what is provisioned and what is actually needed. Modern PAM (Privileged Access Management) platforms support this natively, and several offer workflow integrations that allow vendors to request access via a ticketing system, require internal approval, and receive time-boxed credentials without IT having to intervene manually.
For organizations not yet running a PAM solution, even a simple scheduled script that disables accounts older than 30 days with no recent activity is a significant improvement over the status quo.
Control 02 — Individual MFA, not shared
Multi-factor authentication tied to a shared company phone is barely a control at all. If five technicians at a vendor company all know the PIN to the shared authenticator, MFA provides almost no additional assurance it simply means that any one of them, or anyone who has compromised their shared device, can authenticate.
Every vendor account must be authenticated via an individual token or authenticator app, bound to a named person at the vendor organization. When that person leaves the vendor, their MFA token is revoked along with their access. Vendor contracts should explicitly require this, and access provisioning should not proceed until individual MFA enrollment is confirmed.
This also creates accountability. When an audit asks “who accessed this system at 2am on a Tuesday,” the answer should be a name, not “the vendor team.”
Control 03 — Network segmentation by function
The single most impactful architectural control is ensuring that vendor access is scoped to only the systems and network segments that vendor legitimately needs to reach and nothing else.
The HVAC vendor reaches the building automation VLAN. The lab system vendor reaches the LIS environment. The medical imaging support team reaches the PACS network. None of them should have a route to the EHR, the domain controller, the backup server, or the administrative network. If a vendor account is compromised, the blast radius should be limited to the segment they were authorized to access not the entire hospital infrastructure.
Achieving this requires a network segmentation audit, likely some firewall rule cleanup, and clear documentation of which vendors need access to which systems. It is not glamorous work. It is, however, among the highest-leverage security investments a mid-sized health network can make.
What a vendor access review program looks like
Implementing the three controls above is a start, but sustaining them requires a repeatable process. A vendor access review program does not need to be complex it needs to be consistent.
At minimum, conduct a full audit of all active vendor accounts quarterly. For each account, verify that the vendor relationship is still active, that there is a named individual associated with the credential, that MFA is enrolled, and that the access scope matches the current scope of the vendor’s work. Any account that cannot be verified against an active contract and a named contact should be disabled immediately and investigated.
Trigger additional reviews at every contract renewal, every vendor personnel change that is communicated to you, and every time a vendor reports a security incident of their own. The last point is particularly important: vendors are not always forthcoming about their own breaches, but when they do disclose, the window between their disclosure and an attacker attempting to use harvested credentials can be very short.
Finally, include vendor access requirements in every vendor contract and every RFP. Security controls should be a procurement requirement, not an afterthought negotiated after go-live.
The bottom line
Healthcare organizations spend heavily on endpoint detection, email security, and perimeter defenses. Those investments matter and should continue. But a threat actor who can authenticate as a trusted vendor bypasses most of those controls entirely because from the network’s perspective, they are not a threat. They are a familiar face.
Closing the vendor access gap is not glamorous work. There are no dashboards to demo to the board, no press releases about next-generation AI threat detection. There is only the slow, disciplined work of knowing who has access to your systems, ensuring that access is appropriately scoped and time-limited, and removing it the moment it is no longer needed.
That work may not be exciting. But for mid-sized health networks operating with constrained security budgets and outsized compliance obligations, it may be the single most effective thing you can do to reduce the likelihood of a ransomware event this year.