Online Exclusives

Cybersecurity for Orthopedic Legacy Devices

Legacy medical devices are susceptible to exploitation, jeopardizing patient safety, given their average life span of 15+ years.

By: Seyed Khorashahi

Principal at LSC Group

By: Joseph Silvia

Chief Executive Officer at Medware Cyber

Photo: shadowart/stock.adobe.com

The rapid advancement of technology used in connected medical devices has greatly improved patient care. However, utilization of advanced technology has also expanded the attack surface and poses an unprecedented cybersecurity challenge that impacts patient safety and operational resilience of the Healthcare Delivery Organizations. In recent years, the healthcare sector, including orthopedic medical device manufacturers and providers, has experienced a growing number of serious cybersecurity incidents. These incidents can have significant consequences, including patient data breaches and disruption of patient care.

Current State of Cybersecurity

A survey conducted by RunSafe Security’s “2025 Medical Device Cybersecurity Index” assessed 605 healthcare executives across the U.S., UK, and Germany involved in medical device purchasing and familiar with organizational cybersecurity protocols. Findings show:

  • 22% of healthcare organizations have experienced cyberattacks that impacted medical devices, with 75% of these incidents affecting patient care.
  • 35% now identify operational technology systems like medical devices as their biggest cybersecurity concern.

Furthermore, the data from the same survey shows:

  • 19% of medical devices affected by cybersecurity incidents were networked surgical equipment.

Legacy Medical Device Vulnerabilities

Legacy medical devices are susceptible to exploitation, jeopardizing patient safety, given their average life span of 15+ years. While cybersecurity threats evolve much faster, the challenges with legacy medical devices include outdated technology, resource constraints, and interoperability issues. Many legacy devices also lack robust security features and face difficulties in updating software. Most legacy devices were created prior to many present-day threats, and the design of their hardware and/or software limits potential mitigations.

FDA Cybersecurity Regulatory Compliance

Regulatory authorities like the U.S. Food and Drug Administration (FDA) have responsibility for assuring the safety, effectiveness, and security of medical devices. This requirement is independent of the device’s time on the market, whether legacy or newly launched. Also, FDA recognizes that medical device security is a shared responsibility among stakeholders throughout the use environment of the medical device system, including health care facilities, patients, health care providers, and manufacturers of medical devices. The primary purpose of cybersecurity is to enforce confidentiality, integrity, and availability—known as the CIA triad. Failure to protect the confidentiality of information will result in HIPAA non-compliance, reputational damage, and potential litigation. Failure to protect the integrity and availability of information will lead to patient safety issues. This article will review several common elements of cybersecurity and unpack how to protect your legacy medical devices, including:

  • Secure Product Development Lifecycle
  • Threat Modeling
  • MITRE playbook and STRIDE Model
  • Security Controls
  • Cybersecurity testing
  • Post-market cybersecurity risk management
  • Software Bill of Materials

Secure Product Development Lifecycle

ANSI/ISA 62443-4-1 Security for industrial automation and control systems Part 4-1: Product security development life-cycle requirements is an FDA-recognized consensus standard. Key practices within the standard include security management, specification of security requirements, secure design principles, and continuous improvement strategies. Organizations with legacy devices are encouraged to adopt a defense-in-depth approach, which involves multi-layered security defense measures to protect against various threats.

Threat Modeling and Risk Assessment

Threat modeling is a process to identify threats and vulnerabilities across the medical device echo system. This includes defining risk controls to prevent, mitigate, monitor, or respond to the effects of threats throughout the lifecycle of the medical device. The FDA recommends threat models should:

  • Identify medical device system risks and mitigations, as well as inform the pre- and post-mitigation risks considered as part of the cybersecurity risk assessment.
  • State any assumptions about the medical device system or environment of use (e.g., hospital networks are inherently hostile, therefore manufacturers are recommended to assume that an adversary controls the network with the ability to alter, drop, and replay packets).
  • Capture cybersecurity risks introduced through the supply chain, manufacturing, deployment, interoperation with other devices, maintenance/update activities, and decommission activities that might otherwise be overlooked in a traditional safety risk assessment process.

MITRE Playbook and STRIDE Model

The MITRE Playbook for Threat Modeling Medical Devices was originally designed by the Medical Device Innovation Consortium (MDIC) and is used for modeling medical devices within regulatory standards. This Playbook was created in collaboration with FDA, select industry thought leaders, and industry participants. It is a broad vision of the responsibilities needed for incident response, security protocol, product development, and other cyber hygiene programs.

MITRE playbook is a structured method for implementing threat-informed defense strategies across the cybersecurity lifecycle comprised of:

  • Design: Model threats using ATT&CK.
  • Develop: Build controls aligned to attacker techniques.
  • Deploy: Validate controls with CALDERA or red teams.
  • Defend: Monitor with ATT&CK-mapped detections.

The following four questions form the core of Adam Shostack’s approach to threat modeling, as introduced in his book: Threat Modeling: Designing for Security (published in 2014) and later adopted into MITRE playbook.

  • What are we working on?—Create a visual model of what the system does and how it interacts with the outside environment.
  • What can go wrong?—Assess system vulnerabilities by analyzing the visual model.
  • What are we going to do about it?—Mitigate identified risks to an acceptable level.
  • Did we do a good job?—Verify effectiveness of risk mitigation.

The STRIDE model is a second framework that can support medical device software developers with threat enumeration. Six concepts make up the STRIDE acronym, each of which is critical to medical device cybersecurity:

  • Spoofing
  • Tampering
  • Repudiation
  • Information Disclosure
  • Denial of Service
  • Elevation of Privilege

Incorporating the STRIDE Model into the medical device development process can provide software developers with a systematic approach to threat enumeration, ultimately leading to more secure and resilient devices that safeguard patient safety and data.

Microsoft also developed a model for risk assessment called DREAD. The DREAD name comes from the initials of the five categories listed below:

  • Damage: How bad would an attack be?
  • Reproducibility: How easy is it to reproduce the attack?
  • Exploitability: How much work is it to launch the attack?
  • Affected users: How many people will be impacted?
  • Discoverability: How easy is it to discover the threat?

Following is an example template for summarization of the threat modeling utilizing STRIDE and DREAD:

Security Controls

The following are all the risk controls recommended by FDA:

  • Authentication—Verify the user identity (i.e., User ID/Password combination).
  • Authorization—Determine what the user can do once authenticated.
  • Cryptography—Ensure secure communication.
  • Code, Data, Execution Integrity—Ensure that code, data, and executable code have not been tampered or corrupted.
  • Confidentiality—Ensure confidentiality of any data whose disclosure could lead to patient harm.
  • Event Detection and Logging—Detect and log incidents to enable forensic discovery.
  • Resiliency and Recovery—Protect critical functionality when the device has been partially compromised.
  • Firmware and Software Updates—Provide a secure mechanism for validated software/firmware updates.
  • Compensating Control—Risk control is external to the device design and provided by the user to improve cyber protection.

Cybersecurity Testing

Cybersecurity testing is the method utilized to ensure effectiveness of risk mitigations and implementation of security requirements. This includes:

Security Requirements: Provide objective evidence that all security requirements of the device have been implemented successfully.

Threat Mitigation: Provide objective evidence that all cybersecurity risk controls effectively mitigate the identified risks.

SAST: Static application security testing analyzes source code to detect security vulnerabilities. Perforce Klocwork SAST is an example of a widely used static analysis tool that performs a symbolic execution of the source code to identify defects and security vulnerabilities.

DAST: Dynamic application security testing simulates real-world attacks to examine system responses in production environments. CheckMarx DAST is an example of a tool that helps identify runtime vulnerabilities.

Penetration Testing (Pen Testing): A simulated system penetration test performed by independent internal or external tester(s) to discover and exploit security vulnerabilities in the device.

Postmarket Cybersecurity Risk Management

Cyber enabled device Manufacturers are required to create a postmarket cybersecurity risk management process. This process monitors cyber signals to ensure all devices input, action, and output to ensure the safety and effectiveness of the device. The postmarket cybersecurity risk management process is paramount to keeping legacy devices secure. An example of this input/action/process model includes:

Input—Cybersecurity signals

  • Monitor for changing risks
  • Coordinated Vulnerability Disclosure
  • Agency Alerts & Advisories
  • Scanning
  • Sampling & testing
  • SBOM CVE Monitoring
  • Supplier notification

Action—Triggered by cybersecurity signals

  • Active monitoring
  • Triage
  • Root Cause Analysis
  • Communicate
  • Remediate
  • Collect process metrics for improvement

Output—Pro-active & transparent enhanced cybersecurity

  • End user communication (Vulnerability, Exploitation, Remediation)
  • Regulators (Reportable incidents, Recalls, Privacy Breach)

Software Bill of Materials

The definition of an SBOM, as written in the U.S. Executive Order (EO) 14028, is a “formal record” containing the details and dependencies of various components used in building medical device software. This applies to both Software as a Medical Device (SaMD) and Software in a Medical Device (SiMD). The SBOM includes open source, Consumer off-the-shelf (COTS), and custom (bespoke) software components and is created when the software is released. SBOMs are crucial for improving transparency, cybersecurity, and reinforcing supply chain security. The vulnerability information can potentially be found on the National Vulnerability Database (NVD). SBOMs are living documents throughout the lifespan of the product and updated as information becomes available. Accurate documentation of SBOMs will be beneficial for Healthcare Delivery Organizations, Medical Device Manufacturers, and regulatory bodies by enhancing security.

Final Thoughts

Due to difficulty in applying updates to outdated products, Legacy medical devices pose many cybersecurity challenges to meet FDA’s expectations to protect confidentiality, integrity, and availability. The FDA guidance documents apply to both newly launched and legacy medical devices to ensure safety and effectiveness of these products in their environment of use. Performing threat modeling, utilizing cybersecurity testing techniques, and monitoring all play a crucial role in achieving a more effective security posture for legacy devices. The Software Bill of Materials (SBOM) also plays a key role in helping medical device manufacturers and health delivery organizations to identify and address cybersecurity threats more effectively. Health Delivery Organizations (HDOs) have often used compensating controls such as firewall rules for intrusion prevention systems. Additionally, HDO’s utilize the isolation of legacy medical devices from critical l systems to prevent unauthorized access. By using these security monitoring tools, the detection of suspicious activities is possible.


Seyed Khorashahi is principal at LSC Group, a medical device consulting firm based in Boulder, Colo. LSC Group supports life science industry clients who need cradle-to-grave regulatory compliance expertise.

Joseph Silvia is chief executive officer at Medware Cyber, a cybersecurity firm based in Boston, Mass. Medware Cyber specializes in security throughout the entire medical device lifecycle, from design and development to disposal.

Keep Up With Our Content. Subscribe To Orthopedic Design & Technology Newsletters

Topics