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.

Cybersecurity within the eSTAR framework has undergone significant transformation over the past several years. What began as a brief reference to the FDA’s guidance on cybersecurity has evolved into one of the most extensive and documentation-intensive sections of the submission. It is now highly structured, auditable, and increasingly aligned with international regulatory requirements.

At Harbor Labs, we are in constant collaboration with medical device manufacturers to support their regulatory submissions, helping our clients navigate changes to the eSTAR system and develop the corresponding cybersecurity documentation packages. Whether you are a regulatory professional preparing a 510(k) submission, an engineer responsible for cybersecurity documentation, or an executive assessing the impact on development timelines, the following document serves as a comprehensive reference for the history and evolution of eSTAR.

Note on Template Variants
The FDA maintains separate eSTAR templates for non-in vitro diagnostic (nIVD) and in vitro diagnostic (IVD) devices. The cybersecurity sections in both templates are identical; therefore, all updates described below apply equally to each.

Changes by version as of April 1, 2026:

Evolution by Version

Pre-v5.0
The cybersecurity section was initially introduced in version 0.3 (May 2019). In version 1.0 (November 2021), it was restructured to align with the International Medical Device Regulators Forum (IMDRF) submission framework, standardizing the organization of cybersecurity documentation across global regulatory bodies. In version 3.0 (March 2023), the help text was updated following congressional authorization granting the FDA authority to require cybersecurity documentation in premarket submissions.

Across these early versions, submitters were required to identify device attributes such as network connectivity, wireless communication capabilities, and external interfaces (e.g., USB ports), as well as to document cybersecurity risk management processes and associated plans.

v5.0 (December 2023)
Version 5.0 introduced a comprehensive cybersecurity guidance content framework. By this stage, the cybersecurity section expanded to include a fully structured documentation set spanning multiple pages, including:

• Risks question on unmitigated multi-patient harm or serious adverse events
• Security risk management report
• Threat model, including methodology and four required architectural views (global system, multi-patient harm, updateability/patchability, and security use case)
• Cybersecurity risk assessment using exploitability in place of probability for likelihood determination
• Software Bill of Materials (SBOM), including support levels and end-of-support dates for each component
• Safety and security vulnerability assessments
• Assessment of unresolved anomalies
• Cybersecurity metrics
• Security controls documentation with cross-referenced citations across eight categories
• Architectural views
• Cybersecurity testing documentation and reports
• Cybersecurity labeling references
• Cybersecurity management plan, including defined patching timelines

v5.1 (January 2024)
The wireless function security question was removed from the Wireless Technology section due to redundancy with cybersecurity content.

v5.2 (March 2024)
No changes to cybersecurity requirements.

v5.3 (June 2024)
The Environment of Use subsection within the Wireless Technology section was removed, as it duplicated information already addressed in the cybersecurity section.

v5.4 (November 2024)
Three updates were implemented:

• Clarification that alternative approaches to FDA recommendations are acceptable if appropriately justified
• Removal of the question regarding unmitigated harm, as this evaluation is now reserved for FDA reviewers
• Revision of the Cybersecurity Management Plan help text to directly reference applicable guidance

v5.5 (February 2025)
No changes to cybersecurity requirements.

v5.6 (July 2025)
A streamlined workflow was introduced for device modifications. A single decision point determines the applicable documentation pathway:

• Cybersecurity impacted (or new device): Full documentation required, including threat modeling, risk assessment, SBOM, vulnerability assessments, architectural documentation, cybersecurity testing, security controls, and a cybersecurity management plan
• Cybersecurity unaffected: Reduced documentation set, including SBOM with component support status, vulnerability assessments, identification of uncontrolled risks, and a cybersecurity management plan

v6.0 (October 2025)
De Novo submissions were required to be submitted via eSTAR, making comprehensive cybersecurity documentation mandatory for novel device classifications. Additionally, Health Canada guidance text was incorporated throughout the template, facilitating parallel regulatory submissions.

v6.1 & v6.2 (February 2026)
No changes to cybersecurity requirements.

Outlook

What was once a limited set of cybersecurity inputs has evolved into a comprehensive framework consisting of numerous required elements, including multiple attachments, structured questionnaires, and interdependent documentation artifacts spanning threat modeling, risk assessment, SBOM development, and security controls implementation.

The FDA has indicated that eSTAR will continue to expand to additional submission types, and cybersecurity requirements are expected to grow accordingly. Postmarket cybersecurity enforcement is also advancing, and future iterations of eSTAR will likely incorporate these expectations.

Manufacturers that align their cybersecurity programs with the current framework will be better positioned to adapt to future regulatory developments. Conversely, delayed adoption may result in increased effort and complexity over time.

Harbor Labs has been a leader in medical device cybersecurity since prior to the introduction of cybersecurity requirements within eSTAR. We have supported manufacturers across a wide range of device classes in developing complete cybersecurity documentation packages that meet FDA expectations without the need for additional information requests. Our eSTAR Cybersecurity Checklist maps each requirement to specific deliverables, ensuring completeness and efficiency. For organizations preparing upcoming submissions, further information is available at: https://www.harborlabs.com/contact

Harbor Labs is proud to have supported the U.S. Department of Justice in its False Claims Act litigation against Kaiser Permanente. This work reflects our longstanding commitment to strengthening compliance, integrity, and cybersecurity across complex healthcare IT environments. Originally awarded in 2022, this engagement builds on Harbor Labs’ extensive history supporting DOJ and HHS healthcare IT and cybersecurity investigations. For this contract, Dr. Luis Vargas, Director of Medical Cybersecurity at Harbor Labs, served as the principal technical investigator, with Chief Scientist Dr. Mike Rushanan acting as the testifying expert. Congratulations to everyone involved in bringing this vital matter to a conclusion, and for contributing to stronger compliance, integrity, and trust across healthcare. We are honored to contribute technical expertise that reinforces trust in healthcare systems and supports the public interest.
Link to press release

It could be reasonably argued that the medical device cybersecurity industry was born in August of 2015, when the FDA issued its first ever cybersecurity alert for a medical device. The device that triggered that alert was the Symbiq drug infusion pump by the erstwhile manufacturer Hospira. The pump was reported to be vulnerable to a buffer overflow attack, which if successfully executed could give an attacker root access to the device, allowing the clinical functions of the pump to be altered or stopped entirely. It was the FDA response to this vulnerability and the tremendous publicity it received that abruptly transformed the medical device industry, establishing cybersecurity as a new, critical component of medical device safety. And it was this alert that would launch both a new set of regulatory standards and the medical device cybersecurity industry as we know it today.

At the time of this event, Harbor Labs was led by Dr. Avi Rubin, who in addition to serving as Chief Scientist was also the Director of the Health and Medical Security (HMS) Lab at Johns Hopkins University. Dr. Rubin had recently testified before US Congress on medical cybersecurity, and as a direct result of his testimony at these hearings Hospira selected Harbor Labs to analyze the Symbiq vulnerability and develop a remediation plan.

The effort was led by Dr. Mike Rushanan, who had himself received his PhD through the JHU HMS lab under Dr. Rubin, and today serves as the Harbor Labs Chief Scientist. Dr. Rushanan and the Harbor Labs staff were able to recreate the attack that produced the buffer overflow, writing their own custom input injector and shellcode. Then, working with the manufacturer, Harbor Labs developed the security patch needed to eliminate the vulnerability. The device was soon thereafter approved to resume clinical sales.

The publicity and market impact the Symbiq episode would have on Harbor Labs would shape the future of the company. With the distinction of being the cybersecurity consultants that rescued a medical device from a critical vulnerability and returned it to the market, Harbor Labs was put at the forefront of the burgeoning medical cybersecurity consulting industry. Over the coming years, Harbor Labs would benefit from this pioneering reputation, partnering with many of the medical device industry’s most prominent manufacturers on their cyber policies and regulatory submissions, and working with regulators to help shape the constantly evolving regulatory landscape. It was that critical roll played by Harbor Labs as the medical device industry was first forming in 2015 that would put the company on the trajectory to the market-leading position we enjoy in the industry today.

The Internet of Things has long delivered on the promise of connecting everyday products such as smart thermostats, appliances, cars, and more.

But as the human body has come to occupy a central place in that connected landscape through fitness trackers, insulin pumps, pacemakers, and other wearable devices, the perils of cybersecurity have escalated.

Wirelessly infiltrating such medical devices to inflict harm has occupied many a fictional thriller—from the TV show Homeland to the novel Kill Decision—as well as real life policy debates such as the vulnerability of former Vice President Dick Cheney’s pacemaker. In 2019, the U.S. Food and Drug Administration took the historic step of recalling a specific type of insulin pump because of potential cybersecurity risks.

Still, medical device manufacturers have continued to push products toward the market before they have implemented fully integrated cybersecurity measures, focusing more on making sure the products are safe for patients rather than from outside hacking threats.

Now, a new course offered by the Johns Hopkins Whiting School of Engineering, Medical Device Cybersecurity, is preparing students for the revised approval process mandated by the FDA, which has ramped up requirements for cybersecurity measures throughout the medical device design process.

“Protecting these devices from cyber threats is not just a technical challenge—it’s a matter of patient safety,” states the syllabus for the class, taught by Dr. Michael Rushanan, a lecturer in the Department of Computer Science who earned his PhD from JHU in 2016. “A security breach in medical devices like pacemakers and insulin pumps can have life-threatening consequences.”

The class provides an in-depth review of FDA cybersecurity guidance and the processes needed to meet those relatively nascent government requirements—from the initial design and development steps through device deployment.

The course teaches real-world case studies and provides practical exercises and simulations—including a final project that requires students to build actual medical devices equipped with air-tight cybersecurity measures.

“We want the students to go into the field knowing how critical it is to apply cybersecurity risk management from the design stage,” said Rushanan, chief scientist at Harbor Labs, the firm founded by retired Johns Hopkins professor Avi Rubin. “If you don’t, device manufactures are going to continue to have a ton of problems at the end of the process that can cost them hundreds of thousands of dollars to fix.”

Rubin, who started the Johns Hopkins Health and Medical Security Lab, said manufacturers have become more aware of security issues than they used to be thanks to new comprehensive FDA regulations. But, he added, the class is a first for teaching that new landscape—from understanding the regulatory landscape to incorporating those requirements into the design process.

“This is a first-of-its-kind course on the cybersecurity of medical devices with a focus on the specific issues and challenges inherent in that environment,” Rubin said. “The high level of regulation and the cyber-physical nature of devices that interact directly with humans, along with the privacy sensitivity of health data represent a unique set of challenges. This course provides students with hands-on experience working specifically on medical device security. It will give students a launchpad into careers related to medical and healthcare security.”

The students presented the products they developed with cybersecurity measures fully enmeshed in the designs on May 12. They included:

ThermaTrack:

Provides real-time tracking of a patient’s body temperature and can alert caregivers when it detects abnormal variations. The data is stored securely on the AWS cloud where it can be accessed through a web and mobile application.

Cardio Crisis:

ECG monitors heart activity through a sensor placed on the body and which is connected to a high-speed processor that transmits the data via Bluetooth to a smartphone application. It can detect cardiac irregularities in real time, allowing for quick responses by medical personnel.

PulseLite:

Creates, analyzes, and displays echocardiographic data collected on a patient’s body and provides remote monitoring to alert emergency contacts when abnormalities such as heart attacks are detected.

HappyKittySleepyKitty:

Monitors sleep patterns and stress levels in individuals with PTSD and anxiety. The device tracks physiological indicators that correlate with stress spikes and sleep disturbances, providing real-time feedback and artificial intelligence-driven suggestions for interventions that can improve the users’ well-being.

NeuroMotion:

Tracks movement and other medical data for patients suffering from Parkinson’s disease to determine if treatment is beneficial. It helps patients track their progress and optimize treatment plans that can assist with better recovery and positive mental health outcomes.

Original Article by Doug Donovan, Johns Hopkins University
Image credit: Will Kirk, Johns Hopkins University

Harbor Labs Chief Scientist Dr. Mike Rushanan served as the Principal Investigator for the paper Compliance v. Completeness: A Case Study on SBOMs in Consideration of FDA Premarket Cybersecurity Guidance, to be presented at the upcoming HealthSec 2025 Conference this December in Honolulu, HI.

The paper examines the FDA’s premarket cybersecurity guidance on the use of a Software Bill of Materials (SBOM) in medical device submissions, and how it is possible for a SBOM to be compliant but still incomplete. This assertion is supported by a recent Harbor Labs case study highlighting an anonymized medical device SBOM that met regulatory submission standards, but omitted deeply embedded third-party components and dependencies hidden by software development tooling. The extended SBOM revealed additional vulnerabilities, exposing the blind spots of the original SBOM. The study also found that excluding hardware components, or the HBOM, introduced additional unseen vulnerabilities, leaving devices exposed to risks such as microarchitectural attacks.

The findings reinforce an important distinction: building a SBOM solely for regulatory compliance does not always guarantee effective cybersecurity risk management. Manufacturers are encouraged to build BOMs that incorporate both transitive software dependencies and hardware components in order to maximize the effectiveness of vulnerability monitoring and postmarket surveillance.

Harbor Labs Chief Scientist Dr. Mike Rushanan served as the Principal Investigator for the paper The SBOM Transparency v. Exposure Dilemma: A Case Study on Adversarial Access to Public SBOMs in Healthcare. This is the second of his two papers to be presented at the upcoming HealthSec 2025 Conference this December in Honolulu, HI.

The FDA recommends that manufacturers publicly disclose a continuously updated Software Bill of Materials (SBOM) to support shared responsibility in cybersecurity risk management, vulnerability assessment, and mitigation. While this is a sound and proven security principle, caution should also be exercised in the public release of SBOMs without first evaluating the potential risks introduced by adversarial access.

To support this point, this paper examines a case study using a de-identified, FDA-compliant SBOM derived from a real-world medical device. Using a large language model (LLM), known vulnerabilities (CVEs) were extracted from the SBOM and an attack blueprint was automatically generated. The attack was then validated in a controlled containerized environment, demonstrating that even a minimally detailed SBOM can reduce adversary effort and streamline exploitation planning. The paper concludes with a recommendation that distinctions be made between the SBOM content provided to regulators, clinical end users, and the general public in order to limit unnecessary exposures.