Securing a Fleet of Connected Devices in Hospitals

Part of our Hospital network, IoMT, and connected medical device security series. For the full overview, start with IEC 80001-1: Hospital Network Risk Management Explained.

A single connected infusion pump or vital-signs monitor is a small security problem. Three thousand of them, deployed across forty hospitals, provisioned over six years by different staff with different network configurations, is a different problem entirely. The devices that get compromised in real incidents are rarely the ones with a design flaw; they are the ones onboarded with a default certificate nobody rotated, or left on a flat network because segmentation was assumed rather than verified. Fleet-scale security fails at the seams between manufacturer and hospital responsibility, not usually inside either party's own controls.

Why This Matters

The FDA's final guidance Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, issued February 3, 2026, continues the chain that began with the September 2023 premarket guidance and the June 2025 update, and it treats fleet-scale postmarket management as part of the total product lifecycle, not an afterthought. For connected accessory and monitoring devices sold in the hundreds or thousands of units, that means your submission has to describe how you provision, patch, and eventually decommission the fleet, not just how the individual device resists attack on a bench.

CISA's 2026 Minimum Elements for a Software Bill of Materials now supersede the NTIA's 2021 framework, and hospital procurement teams increasingly cross-reference your SBOM against MDS2 disclosures during purchasing review, not just at initial evaluation. AAMI SW96 (recognized as 13-131) and TIR97 (13-112) both expect postmarket controls scaled to actual deployment size. A device that is secure in isolation but has no realistic plan for certificate rotation or patch delivery across a real fleet does not meet that expectation, regardless of how clean its individual threat model looks.

How do you provision and onboard thousands of devices securely?

Secure provisioning means every device gets a unique cryptographic identity at manufacturing time, not a shared default that gets "personalized" during hospital install. Manufacturers who leave identity assignment to the field almost always end up with some devices still carrying the factory default, because on-site provisioning gets rushed and skipped under deployment pressure. Identity, including a device certificate or equivalent credential, needs to be injected during manufacturing and verifiable during onboarding, so a hospital can confirm the device is genuine before it ever joins the network.

How do you manage certificates and keys across a device fleet?

Certificate and key management has to be treated as an ongoing operational program with a defined rotation schedule, not a one-time PKI decision made at product launch. Devices that ship with certificates valid for the device's entire expected service life avoid one problem and create another: a compromised key stays valid for years with no path to revoke and reissue it. The realistic middle ground is certificates with a defined validity window and an automated renewal mechanism that does not require a service visit.

Manufacturers need a certificate authority strategy that survives their own organizational changes: what happens to device trust if the manufacturer changes its signing infrastructure, gets acquired, or discontinues a product line. A fleet with no answer to that question is a fleet that eventually loses the ability to trust its own devices.

Who owns network segmentation, the hospital or the manufacturer?

Network segmentation is implemented by the hospital, but the manufacturer owns telling the hospital exactly what the device needs to reach and nothing more. A device manufacturer cannot configure a hospital's VLANs or firewall rules, but a device that ships without a clear network requirements document forces IT staff to guess, and guessing usually produces an overly permissive rule set. The manufacturer's job is a documented, minimal set of required ports, protocols, and destinations that the hospital's network team can implement as a segmentation policy with confidence.

The hospital's IT and biomed teams cannot segment what they do not know exists on the network, which is why an accurate device inventory feeding into the hospital's asset management is as important as the segmentation rule itself.

What does MDS2 actually need to say?

MDS2 is the disclosure document hospitals use to assess a device's risk profile during procurement and renewal, and it only works if the answers are specific rather than defensively vague. A form that answers "encryption used: yes" without specifying algorithm, key length, or scope gives a hospital security team nothing to evaluate. Hospitals increasingly cross-check MDS2 answers against the SBOM and against what the pentest report actually found, so inconsistency between those documents raises more questions than an honest gap would.

Our MDS2 and JSP2 post and role of MDS2 post go deeper on filling the form out in a way that actually holds up under a hospital security review.

How do you deliver patches across a fleet without disrupting care?

Patch delivery at fleet scale has to account for intermittent device connectivity and hospital-controlled maintenance windows, not assume every unit is reachable on demand. A device that requires a physical visit to apply a security patch will realistically go unpatched for a large share of the fleet, since biomed staff cannot service every unit on release day. The design goal is a signed, staged update mechanism that a device can pull and apply during a hospital-defined window, with rollback if the update fails.

See also: Embedded Cybersecurity Challenges MedTech, Radiology Information System: What It Is and How It Works, and NFC and Medical Device Cybersecurity.

Reporting matters as much as delivery. Hospitals need a way to see which devices in their fleet are on which firmware version, so a security team can answer "are we exposed to this CVE" without manually inventorying every unit.

How should end-of-support be communicated to hospitals?

End-of-support communication has to reach the hospital's security and procurement teams directly and early, not rely on a notice buried in a support portal. Hospitals plan capital budgets years in advance, and a device reaching end of support with no advance notice forces an unplanned replacement or, more commonly, continued use of an unsupported device with no compensating controls in place. Manufacturers should give hospitals a firm end-of-support date at launch when possible, and update it proactively rather than waiting for a customer to ask.

A realistic end-of-support communication includes what stops (security patches, vulnerability monitoring) and what a hospital should do in the interim, such as additional network isolation, since simply telling a hospital to "upgrade" ignores capital budget cycles that can run several years.

What do shared clinical accounts mean for device design?

Shared clinical logins are a workflow reality on hospital units, and device authentication design has to account for them rather than assume individual login will happen. A nurse moving between patients every few minutes will not log out and back in for each interaction, no matter what policy says, and a device that only supports a single shared credential loses all ability to attribute an action to a person. The practical fix is designing for fast, low-friction identity, such as badge tap or proximity authentication layered on top of a device-level credential, rather than insisting on password-based individual login that clinical workflow will simply route around.

Audit logging should be designed assuming shared accounts exist, capturing device and session context even when individual attribution is imperfect, rather than treating incomplete attribution as a reason to skip logging altogether.

How Blue Goat Cyber Approaches This

We evaluate fleet devices differently from single-unit devices, because the failure modes are different: provisioning gaps, certificate lifecycle blind spots, and patch delivery mechanisms that look fine in a lab and fail against real hospital connectivity. Our team tests the full deployment lifecycle, from manufacturing-time identity injection through onboarding, patch delivery, and decommissioning, not just the device's static attack surface.

For MDS2 and SBOM work, we help manufacturers write disclosures that will hold up when a hospital security team cross-references them against pentest findings, because inconsistency there damages trust faster than an honest limitation does. We also help manufacturers document the network requirements hospitals need to segment correctly, since a device that ships without that documentation puts the burden of guessing on hospital IT. If the FDA raises cybersecurity deficiencies after our submission work, we resolve them at no additional cost.

Frequently Asked Questions

How many devices need to be compromised before a fleet-wide problem becomes a hospital-wide one?

Whose job is it to segment our device from the rest of the hospital network?

Do we need individual logins on every device to be secure?

What happens if we can't patch every device in a fleet on the same schedule?

How far in advance should we tell hospitals about end of support?

Does MDS2 replace the need for a penetration test?

CTA

If your fleet's provisioning, certificate management, or patch delivery plan only works on paper, a hospital security review or a real incident will find the gap before we do unless we find it first. Contact us to have your fleet security architecture and MDS2 disclosure reviewed together.