Supply-Chain Attacks Through Medical-Device Vendors
A few years ago, a cardiac monitor vendor pushed a firmware update to thousands of devices in hospitals across the country. The update was signed and tested and approved. It fixed a minor display bug. It also opened a backdoor that let an attacker pivot from the device network into the hospital's Active Directory. The breach was discovered months later during a routine audit, not by the vendor's security team.
That's the supply-chain attack model applied to medical devices. It's the same playbook as SolarWinds and Kaseya. When the target is a cardiac monitor, the failure mode is a clinical tool that can no longer be trusted. That's a different problem than a data leak.
How Medical-Device Supply-Chain Attacks Work
The attack follows a predictable pattern. An adversary compromises the vendor's build pipeline or software distribution system. The next firmware update that goes out to every monitor, defibrillator, or EMR gateway carries malicious code signed with the vendor's legitimate certificate. The device accepts it without question because the signature checks out.
The SolarWinds breach worked the same way, with attackers inserting code into the Orion build system so every customer who downloaded the update got the backdoor. The Kaseya attack used the same vector through the VSA remote management platform. In both cases, the victims did everything right by applying updates from a trusted vendor. The trust was the problem.
> The most dangerous attack is the one you invite in yourself. A signed update from a trusted vendor bypasses every perimeter control you have.
For EMS agencies, the exposure runs through two main paths. The first is device firmware. Cardiac monitors and ventilators and defibrillators all receive signed firmware updates. A compromised update can install persistent malware that survives OS reinstalls and evades standard network scanning because the device runs a proprietary operating environment.
The second path is the middleware that connects devices to the ePCR. Many agencies use a gateway appliance that pulls vitals from the monitor and pushes them into the patient record. If that gateway software is compromised, an attacker can move laterally from the medical device VLAN into the agency's administrative network. The gateway is the bridge. Once it's crossed, the CAD system, the payroll server, and the dispatch center are all reachable.
What to Expect From Your Vendor When a Vulnerability Is Found
Medical device manufacturers move slower than pure software companies. There's a reason for that. Some firmware changes require FDA review or notification depending on the scope of the change, and the regulatory process can add weeks or months to the disclosure timeline. The result is a predictable cadence that IT directors need to understand.
When a researcher finds a vulnerability, the notification chain goes like this: researcher to vendor, vendor to CISA and FDA, then vendor to customer. The customer is last in line. You will typically receive a vague "security update" notice first with no CVE number and no detail about what was actually fixed. The detailed disclosure comes weeks later, after the vendor has coordinated with regulators.
Some vendors try to roll out patches quietly through automatic updates. This is a problem for two reasons. First, you don't know what changed. Second, you can't verify that the patch was actually applied across your fleet if the update mechanism is opaque. You need a way to confirm firmware versions manually on a sample of devices.
The disclosure timeline you should expect for a critical vulnerability is roughly 90 to 120 days from discovery to public disclosure. That's the window you have to assess your exposure and plan your response. If your vendor can't commit to a faster timeline in your contract, that's a negotiating point for the next renewal.
Why Patching Medical Devices Is Hard
Here's the hard part: a patch that fixes a security vulnerability can also break clinical workflows. Firmware updates sometimes change the API handshake between the monitor and the ePCR, and a security fix that stops vitals from flowing into the patient record increases documentation errors and clinician burnout. A patch that causes a monitor to reboot unexpectedly during a call is a patient safety failure.
This creates a real tension between the security team wanting the patch applied immediately and the clinical team wanting to validate it first. Both are right. The problem is that a cardiac monitor can't be taken offline for a maintenance window the way a file server can. Pulling devices from service reduces fleet capacity. If you have forty rigs and you need to pull ten for patching, you're running at seventy-five percent.
Skipping the patch is not the answer. Validate on a non-production unit before fleet-wide deployment. If you don't have a spare monitor to test on, that's a budget conversation you need to have with your administration. A single test unit is cheaper than a breach.
Network Segmentation Is Your Primary Defense
If a vendor's update is compromised, you can't stop the malicious code from reaching your devices. What you can do is contain it. Network segmentation is the most effective defense against supply-chain attacks in the medical device space.
Medical devices should live on a dedicated VLAN with strictly controlled egress and ingress. The monitor should be able to talk to the ePCR gateway and nothing else. It should not be able to reach the CAD server, the payroll system, or the internet. If the device is compromised, the attack is contained to that VLAN. It cannot see the rest of your network.
This is the same principle that applies to vendor subprocessor risk. You don't control what your vendor's vendor does, but you do control your network boundaries. Make them count.
Segmentation also makes firmware verification easier. If you know exactly which devices are on the medical VLAN and what they should be talking to, you can spot anomalies like a monitor that suddenly starts sending traffic to an external IP. Segmentation makes that traffic visible.
The Analog Fallback
Every agency needs a documented procedure for running without EMR integration. If the gateway is compromised or the patch breaks the handshake, crews need to be able to chart on paper and enter the data later. This is not a theoretical exercise. It happens.
The fallback plan should include printed run forms, a process for data entry after the incident is resolved, and training that keeps the skill current. If your crews haven't done paper charting in two years, the first time they need it will be a disaster. Run a drill.
Frequently Asked Questions
Why is a supply-chain attack more dangerous than a standard hack?
Because it exploits a trusted relationship. The malware arrives as a legitimate signed update from a vendor you already trust. It bypasses perimeter defenses and is installed automatically by the device or the update system. You don't have to make a mistake for the attack to succeed. You just have to be a customer of the wrong vendor.
Should I update medical device firmware immediately when a patch is released?
No. Validate the patch on a non-production unit first. Check that the EMR integration still works and that the device functions correctly under load. A patch that crashes a monitor during a patient encounter is a patient safety failure. Once validated, deploy on a schedule that minimizes clinical impact.
How can I protect my agency if the vendor is the one who is compromised?
Network segmentation. Medical devices on an isolated VLAN with strictly controlled communication paths. If the device is compromised, the attack stops at the VLAN boundary. You should also verify firmware versions manually across a sample of your fleet to confirm updates were actually applied.
What disclosure timeline should I expect from a medical device vendor?
For a critical vulnerability, expect 90 to 120 days from discovery to public disclosure. You will likely receive a vague security notice first, followed by a detailed CVE report weeks later. Push for faster timelines in your vendor contracts.
What do I do if a patch breaks my EMR integration?
Activate your analog fallback. Crews chart on paper until the integration is restored. Document the issue and report it to the vendor. Do not roll back the security patch without understanding the risk. If the vulnerability is actively exploited, the security patch stays and you work around the integration break.
Closing
Supply-chain attacks through medical-device vendors are not hypothetical. They are the logical extension of an attack model that has already proven effective against SolarWinds and Kaseya and others. The EMS and public-safety space is not immune. The same dynamics apply. Trusted vendors, signed updates, and a clinical environment where downtime has real consequences.
The strategy is straightforward: segment the network, validate patches before deploying, keep the paper charts current, and push your vendors for better disclosure timelines. You can't control what happens in their build pipeline, but you can control what happens in yours.
-- Steven
Need help with your agency’s cybersecurity? Get in touch