The Hacker Did Not Break In. Your Vendor Logged Them In.

That remote support account was created to make maintenance easier. It may also be the cleanest path ransomware operators have into your hospital.

At 1:47 in the morning, a technician logs into the hospital network using a legitimate vendor account. The username is recognized, the remote access software is approved, and the connection comes from infrastructure nobody on the night shift has been told to question. There is no dramatic firewall alert announcing that criminals have arrived. No employee opens a suspicious attachment. No attacker needs to smash through the front door because leadership already paid a vendor to install a private entrance around the side of the building.

The technician is not a technician, of course. The vendor's credentials were stolen, its remote management platform was compromised, or one of its systems was left unpatched. The intruder begins quietly, examining servers, testing privileges, harvesting credentials, and identifying systems that will create the most pain when they disappear. By sunrise, the electronic health record is unavailable, laboratory interfaces are failing, pharmacy workflows are slowing, and executives are asking how the attacker got past the hospital's security controls. The answer is humiliatingly simple: the attacker arrived through an access path the hospital trusted so completely that nobody was watching it.

Healthcare organizations depend on outside companies for almost everything. Vendors maintain imaging equipment, laboratory systems, pharmacy platforms, medical devices, building controls, billing applications, dictation software, security cameras, network equipment, backup systems, and electronic health record integrations. Many of those companies need remote access to perform maintenance, install updates, troubleshoot failures, and provide emergency support. The operational need is real, but so is the danger. Every vendor connection expands the hospital's attack surface, and every permanently enabled account gives criminals another identity they can steal.

Executives often confuse a signed contract with a completed security review. The vendor passed procurement, supplied a certificate of insurance, completed a questionnaire, signed a business associate agreement, and promised to follow "industry best practices." Everyone felt better, and the account was created. Three years later, the vendor still has access, the original project manager has left the hospital, the contract has been amended twice, and nobody can clearly explain which systems the account can reach. That is not third-party risk management. That is institutionalized optimism with a password.

The danger is not theoretical. In June 2025, CISA warned that ransomware actors had exploited unpatched instances of SimpleHelp remote monitoring and management software to compromise customers of a utility billing software provider. The attackers did not need to individually breach every customer through a separate phishing campaign. They exploited software designed to provide trusted remote support, then used that position to reach downstream organizations. CISA advised organizations using remote management software to assess the risk, patch vulnerable systems, hunt for unauthorized activity, and ask third-party vendors what security controls they had implemented.

That attack pattern should terrify healthcare CEOs because remote management tools are built to behave like an administrator. They can execute commands, install software, transfer files, change configurations, and operate across large numbers of systems. Those capabilities are extremely useful when the person using them is fixing a clinical application. They are equally useful when the person using them is deploying ransomware. The tool does not know whether the person clicking the button works for the vendor or bought the vendor's credentials in a criminal marketplace.

CISA's ransomware guidance specifically tells organizations to prioritize reviews of publicly accessible remote monitoring and management accounts, including third-party access granted to managed service providers. Joint guidance from CISA, the NSA, FBI, and international partners has also warned that malicious actors target managed service providers because compromising one provider can expose multiple customer environments. The guidance calls for MFA on provider accounts, monitoring of provider activity, controlled remote access, segregation, and clearer security responsibilities between providers and customers. These are not exotic security measures reserved for national intelligence agencies. They are the minimum price of allowing another company to operate inside your network.

Yet vendor access is frequently exempted from the controls imposed on hospital employees. Employees use named accounts, but the vendor shares one generic login across its support team. Employees must use MFA, but the legacy application cannot support it, so the vendor receives an exception. Employees lose access when they leave, but the hospital has no reliable way to know when a vendor technician changes jobs. Employees are monitored through endpoint and identity systems, while the vendor connects through an appliance installed years ago in a departmental equipment closet. The hospital has created a privileged class of outside users and then chosen to know less about them than it knows about its own staff.

HHS states that healthcare organizations should clearly identify users and maintain audit trails that monitor access to data, applications, systems, and endpoints. Its healthcare cybersecurity goals call for MFA on remote access where technically possible, prompt revocation of credentials for departing employees and contractors, and controls capable of recording and reviewing system activity. HHS also emphasizes that cybersecurity policies should clearly define what employees, contractors, and third-party vendors are authorized to access. A vendor account that cannot be uniquely attributed, monitored, restricted, and quickly disabled conflicts with the basic direction healthcare regulators and security authorities have been repeating for years.

The CEO does not need to know how a remote monitoring agent executes PowerShell. The CEO does need to ask why a vendor can reach production systems at 2:00 a.m. without a hospital employee approving the session. The CEO should ask whether vendor access is permanently enabled or activated only when support is required. Leadership should know whether each vendor uses a named identity, phishing-resistant MFA, a managed device, and an access path restricted to the exact systems covered by the contract. If nobody in the room can answer those questions, the organization does not have vendor access under control.

Contracts will not save the hospital during the attack. The vendor may have promised prompt notification, reasonable security, annual testing, and cooperation during an incident. Those provisions matter later, when lawyers begin assigning blame and calculating damages. They do not stop ransomware from moving between servers while the clinical team is switching to paper. A financial remedy recovered two years after litigation will not reopen the emergency department tonight.

Healthcare executives should also stop assuming that regulatory accountability ends at the vendor's door. In April 2026, HHS announced settlements arising from four ransomware investigations that collectively affected more than 427,000 individuals. One of the entities was Consociate Health, a third-party administrator and HIPAA business associate whose attack affected approximately 136,539 people. HHS found failures involving risk analysis and required corrective actions, monitoring, and financial settlements. A vendor's failure can expose patient information, disrupt operations, trigger reporting obligations, and pull every connected organization into an expensive investigation.

The correct question is not whether the vendor is trusted. Trust is why the connection exists, not why it should escape scrutiny. Vendor access should be temporary whenever possible, limited to approved systems, protected by strong MFA, routed through controlled access infrastructure, recorded, monitored, and automatically terminated when the work is complete. Privileged sessions should be attributable to an individual human being, not a company name. Exceptions should expire instead of quietly becoming permanent architecture.

The hospital should maintain a complete inventory of vendor accounts, remote tools, service accounts, appliances, cloud connections, and support tunnels. Every entry should have a business owner, technical owner, approved purpose, access scope, expiration date, and documented method for emergency termination. Security teams should test whether the hospital can disable a vendor's access without waiting for that vendor to answer the phone. Tabletop exercises should include a scenario in which a trusted provider becomes the attack path, because the middle of a ransomware event is a terrible time to discover that nobody knows which account belongs to whom.

Executives should insist on evidence instead of reassurance. Ask for the number of active vendor accounts, the number protected by phishing-resistant MFA, the number that have not been used in ninety days, and the number with administrative privileges. Ask how many third-party remote access tools are installed and whether security monitoring can distinguish approved vendor activity from criminal activity using the same software. Ask which vendors can reach clinical systems and whether those connections are segmented from the broader network. A board that receives only a percentage labeled "vendors assessed" is being shown activity, not risk.

When the ransomware investigation is complete, the first malicious event may look perfectly legitimate. The logs may show a recognized remote access tool, a valid account, and a successful authentication. The attacker may not exploit the hospital's firewall or defeat its endpoint protection. They may simply use the access the hospital created, approved, and forgot to monitor. The most dangerous person in the network may be wearing a vendor's digital badge. Your vendor may be trusted. Their account should never be.