Medical device cybersecurity is often analyzed in the context of regulations, manufacturer commitments, and industry frameworks. But conversations with hospital IT and IT risk teams can reveal a much more grounded reality. Healthcare organizations still feel it necessary to compensate for fundamental gaps in device security.

At Harbor Labs, we recently had the opportunity to speak with IT and cybersecurity leaders at a major national hospital system. The discussion provided a candid look into how hospitals truly evaluate medical device risk, and why trust between healthcare providers and device manufacturers remains limited.

Here are several key insights from that conversation.

Hospitals Start from a Position of Distrust

One of the most striking themes was the lack of trust hospital IT teams have in medical device cybersecurity. Security leaders pointed to numerous examples of devices still running Windows XP or similarly outdated operating systems in production environments. These systems often cannot be patched or upgraded without vendor involvement, which may mean that a product is end-of-life or even that the vendor transfers the risk of updates to the hospital, leaving hospitals responsible for managing the risk.

Instead of relying on device security controls, hospitals frequently compensate through network-level defenses. Common mitigation strategies include:

• VLAN segmentation
• Strict firewall rules and routing policies
• Isolation of medical devices by department and away from clinical networks
• Controlled device-to-network communication paths

In other words, many hospitals assume that medical devices themselves cannot be trusted, so they focus on containing potential damage.

IT Security Often Enters the Process Late

Another insight was where cybersecurity fits in the procurement lifecycle. Contrary to what many vendors assume, hospital IT and security teams are not always involved in early sales conversations. The typical purchasing workflow evolves as follows:

1. Clinical department identifies a need for a device
2. Medical device manufacturer marketing teams engage clinicians
3. A live demo takes place
4. The clinical department makes a purchasing decision
5. Procurement reaches out to IT Risk to assess the device

Only at that point does the cybersecurity evaluation begin. Not until this stage does the IT risk team typically request documentation such as the MDS2 (Manufacturer Disclosure Statement for Medical Device Security) and evaluate the device against core cybersecurity principles.

A Good MDS2 Makes a Huge Difference

The IT risk team emphasized how valuable a well-prepared MDS2 can be. They shared an example of a particularly strong submission from a major manufacturer. The document was roughly 40 pages long and included:

• Network architecture diagrams
• Port and protocol lists
• Service dependencies
• Detailed system behavior descriptions

This level of detail allows hospital security teams to quickly understand:

• How the device interacts with the network
• What infrastructure it requires
• What security risks it may introduce

By contrast, they also showed an MDS2 that was only three pages long. When documentation is that sparse, IT teams are forced to hunt through product manuals, vendor websites, and scattered documentation just to piece together the device’s security posture. The difference between the two approaches can significantly affect the speed and outcome of a procurement review.

We link a GE Ultrasound Scanner and Hologic Breast Biopsy Guidance System MDS2 forms that, while not a part of our conversation with the national hospital, provide context on how the MDS2 has changed over time and what content they have by default. Specifically, the GE MDS2 is from 2017, is six pages long, and does not include international standards alignment. The Hologic MDS2 is from 2020 and includes an SBOM.

Neither MDS2 includes architecture or design details that would support hospital and risk IT deployment, configuration, or management of the device. Additionally, the included SBOM in the Hologic MDS2 is many years out of date, no longer reflecting the latest software stack, and therefore provides outdated and inaccurate vulnerability visibility (i.e., software components with new and recent CVEs).

Hospitals Rarely Test Devices Themselves

One surprising finding was that many hospitals do not perform active cybersecurity testing on medical devices once deployed. This isn’t due to a lack of interest, but because of the risk. With some systems, even basic vulnerability scans have caused medical devices to fail. For hospitals running critical clinical equipment, that type of failure is unacceptable. As a result, many IT teams avoid scanning or penetration testing devices altogether, relying instead on vendor assurances and documentation.

A Three-Way Disconnect Exists

There was also a strong perception that medical device cybersecurity sits in a disconnect between the three stakeholders, manufacturers, regulators, and hospitals. From the hospital’s perspective, decades of insecure devices have created skepticism about regulatory oversight.

Examples cited included:

• Devices that cannot be patched
• Ambiguous responsibility for updates
• Lack of visibility into system behavior
• Limited support for modern security practices

Because of this history, some hospital security teams remain cautious about assuming that regulatory compliance equates to real-world security, especially when applied to their specific clinical enterprises.

Vendors Sometimes Shift Risk to Hospitals

The hospital’s Deputy CISO shared several anecdotes about manufacturers that technically allow system updates, but place the operational risk on the hospital. In some cases, vendors told hospitals: “You can update the system if you want, but if anything breaks, it’s your responsibility.” For hospitals running life-critical equipment, that effectively discourages updates altogether.

Incident Response Capabilities Are Often Limited

Another major concern involved incident response readiness, a core principle of the NIST Cybersecurity Framework. In one example, a manufacturer alerted the hospital to a known vulnerability affecting devices currently in operational use. The vendor asked the hospital to manually pull logs machine by machine to determine whether they had been affected. Two major issues emerged:

• The devices did not centralize logs
• The vendor did not allow integration with SIEM tools

Even more problematic, the devices only retained five days of logs despite the vulnerability being known for more than 30 days. This made meaningful forensic analysis nearly impossible.

SBOMs Exist — But Are Rarely Used

Finally, the conversation touched on Software Bills of Materials (SBOMs). The hospital team noted that they have occasionally received SBOMs from manufacturers, but they do not currently have a structured process for ingesting or monitoring them.

This highlights a broader industry challenge. While SBOMs are becoming increasingly more common and a central feature to post-market vulnerability management, many healthcare organizations still lack the tooling and workflows needed to operationalize them.

The Bigger Takeaway

The conversation made one thing clear: hospitals are still operating in a defensive posture when it comes to medical devices. Because they cannot always rely on device-level security, they compensate with:

• Network segmentation
• Procurement reviews
• Documentation analysis
• Operational workarounds

Until device security becomes more transparent, testable, and operationally manageable, that dynamic is unlikely to change. For manufacturers, the lesson is simple. Clear documentation, realistic security practices, and operational transparency go a long way toward building trust with hospital security teams.