As of January 2023, the FDA has revised its regulations to expand cybersecurity requirements throughout the medical software development lifecycle. Manufacturers of medical software have additional flexibility in selecting a cybersecurity framework appropriate for the medical device software. Based on our experience, the NIST (National Institute of Standards and Technology) Secure Software Development Framework provides robust guidelines to conform to these new rules.
Even as medical devices play a vital role in transforming patient care, they transfer risks into the healthcare setting they originated, including new exposures and vulnerabilities for malicious intrusions and interferences with patient care.
The US Department of Health and Human Services reported 541 data breaches in 2023 alone, while a report from the FBI indicates that the prevalence of ransomware attacks on healthcare institutions increased two-fold from 2021 to 2023.
Cybercriminals frequently attack hospitals, clinics, and medical devices, obtaining patient records that they can then cryptolock or ransom. It leads to delayed treatment or substandard care, sometimes with dire consequences for patient safety. Recent studies from late 2023 suggest prominent mortality increases following cyberattacks on hospitals.
For example, in late 2023, the FDA declared that Medtronic’s MiniMed 600 Series Insulin Pumps contained exploits that could errantly administer insulin; even more concerning, ZOLL Medicorp revealed that its LifeVest wearable cardioverter defibrillator had a security flaw that lifted the personal data – addresses, Social Security Numbers and birthdates – of more than 1 million of its users.
Identifying Vulnerability Hotspots
A 2023 analysis showed a sharp rise in healthcare product vulnerabilities, up 53 per cent year-over-year, with 993 flaws in 966 healthcare products, rising from the previous year’s total of 650 vulnerabilities across 521 products. The number of high- or critical-severity flaws is high: 160 are weaponised – that is, someone has a proof of concept of how an attacker could strike through the flaw.
These security gaps were identified in Class II medical devices, including moderately risky equipment like anaesthesia monitors, infusion pumps, and CT scanners. Exactly 292 vulnerabilities were found in 367 of them. Class I locked down 25 vulnerabilities against 41 other gadgets, more straightforward equipment with a much lower risk. Class III adduced the tiniest share of them all, two bugs out of 20 gadgets: high-risk devices and implants necessary for a person to live and sometimes literally hold life in balance.
Even more disquieting, the survey found that 64% of the discovered vulnerabilities were software-based. While this percentage is enormous, only 2.13% of the medical devices with software components featured in their manuals mention cybersecurity precautions. This is where medical device documentation comes into play: hazards can be prevented with proper cybersecurity attention.
New FDA Regulations Improve Cybersecurity for Medical Devices
On 29 December 2022, the Federal FD&C Act (Food, Drug, and Cosmetic) was controversial and updated with the passing of the Consolidated Appropriations Act, 2023, with so-called ‘Section 524B’ dedicated to the cybersecurity of medical devices. And on 26 September 2023, the FDA followed this with new cybersecurity guidance for medical devices.
This new guidance replaces the 2014 premarket-section devices guidance and goes ‘well beyond’ this previous guidance to comprehensively address cyber risks and vulnerabilities affecting currently marketed devices with cybersecurity features. Where the earlier guidance mainly incorporated best practices for voluntary transparency from manufacturers, the newly added rule requires it. Pre-market submissions must now include ‘information on how to mitigate … cybersecurity hazards’. Furthermore, the amendment encourages manufacturers to ‘follow a cybersecurity framework systematically’ over the lifecycle of their medical device software.
Scope of the New FDA Cybersecurity Regulation
Most recently, section 524B of the Federal FD C Act defined ‘cyber devices’ as any medical device – either a new device or one designed initially—that can communicate with other devices or systems and contains any software components subject to cybersecurity risks. Based on the FDA’s guidance, any medical device capable of network connection becomes a cyber device.
This rule applies to manufacturers wishing to bring new iterations or types of these cyber devices to market and to all manufacturers who want to introduce medical devices into the US. The net effect is an all-encompassing approach to securing all such devices coming on the market.
Essential Aspects of the New FDA Cybersecurity Regulations
These recent amendments have granted the FDA statutory authority over medical devices concerning cybersecurity, and this change drastically increases the ability of the FDA to require robust cybersecurity standards in medical devices. The FDA could only accept premarket submissions meeting the detailed cybersecurity requirements in the Premarket Cybersecurity Guidance of Section 524B. The following are the necessary elements for premarket submissions under the new rule:
Cybersecurity Risk Management Report
The report must include a threat model of all possible vulnerabilities and security threats to the device, a cybersecurity risk assessment of the likelihood and severity of individual identified risks, and a Software Bill of Materials (SBoM) containing the complete set of software components (open-source, third-party, in-house developed) that are comprised within the medical device software.
Architectural Diagrams and Views
Diagrams showing the device configuration for premarket submission and its interfaces with other systems, networks, and external components are critical. Detailed diagrams and documentation describing the boundaries of a system and potential targets of an attack play an essential role in post-market monitoring. Diagrams will also help determine the possible scope of attacks. Documentation should describe how interactions between components could give rise to risks not encountered in other systems and any plans for patching the device to protect against known vulnerabilities, including how existing security mechanisms fare under different attack scenarios.
Oversight Requirements
Before devices are sold, the manufacturer must conduct security tests that prove risk controls are compelling. Such tests must include abuse cases, malformed inputs, and penetration tests, with independent proof of tester knowledge. Labels must contain information on cybersecurity risk in the Informed Consent Forms to inform end-users.
Cybersecurity Management Plan
Detailed cybersecurity management plan for the product that addresses risks throughout its lifecycle. This plan should include strategies for monitoring the device for known vulnerabilities and specify the frequency of these checks. Address vulnerabilities listed in the CISA catalogue by outlining specific remediation strategies. Additionally, establish a timeline for releasing patches. The plan should also cover procedures for vulnerability disclosure and the release of updates or patches.
Regulators have designed heightened regulatory standards to promote cybersecurity in medical devices and enhance the protection of personal health information against increasing digital threats. These standards ensure that medical devices can be used more safely. Manufacturers must meet these standards not only to satisfy regulators but also because failing to do so will threaten the safety of patients and undermine trust in the product.
Implementing Security Throughout the Device Lifecycle
At the heart of the FDA’s updated guidance is an updated security framework called the Secure Product Development Framework (SPDF). This framework includes explicit instructions that security be designed and constantly maintained throughout a medical device's whole lifecycle. SPDF requires modern manufacturers to consider security at the earliest stages of a product’s lifecycle, from the design and development of a particular device to responsible retirement or decommissioning.
The fundamental goal of the SPDF is that cybersecurity is an essential consideration from the beginning of medical device software development, not a late addition. In general, the framework’s recommended practices ought to produce software that helps achieve at least five security objectives:
-
Tamper-proof operation: operations must be protected against tampering, limiting access to data and control to authorised users and systems.
-
Maintaining the Device's availability: It aspires to make the device available and provide service even against attempts at denial of service.
-
Promote Data Confidentiality: This refers to preventing others from accessing sensitive patient data to adhere to privacy legislation and maintain patient trust.
-
Supporting Timely Updates: It ensures devices can be remotely updated or patched to remedy newly discovered vulnerabilities.
To this end, the new FDA guidance spells out specific security controls such as robust authentication, strong cryptography, event logging, and rigorous code and data integrity checks. For instance, the guidance stipulates that manufacturers must authenticate data in transit and, at rest, authenticate communication endpoints and maintain the integrity of execution states and software binaries.
The SPDF is not intended to be controlling. Instead, it empowers manufacturers to use other approaches and frameworks so long as they comply with the new premarket submission requirements. It will encourage manufacturers to leverage their existing, effective processes to reduce cyber risks on medical devices and enable these processes to interface effectively with this new package of security requirements. Manufacturers won’t need to upend their established management systems or addiction-treatment modalities completely: they can continue ‘what works’ while reducing cyber risks.
Initiating Compliance with a Secure SDLC
The new FDA regulations simplify compliance in the design and development phase, as defined by the Secure Product Development Framework (SPDF). The SPDF's hallmark is attention to implementing cyber risk and security controls across the entire SDLC.
Of the frameworks that treat these security risks within the SDLC in an effective manner, the most rigorous speaks to the entire medical software lifecycle and supplements the FDA’s SPDF by introducing a practical methodology for developing secure medical devices. The NIST Secure Software Development Framework (SSDF) (NIST SP 800-218) is a highly proscriptive standard based on NIST’s years of experience in the industry. It’s capable of addressing every component of the product development lifecycle, incorporating security into this process from the initial planning and design phase to implementation and even maintenance by building security into the entire lifecycle. It represents the holy grail of security requirements – a rigorous approach manufacturers can use to follow prescriptive practices and ensure their product is secure enough to market.
Aligning NIST SSDF with FDA’s Cybersecurity Requirements
The FDA's strategy, in particular, creates security by embedding it throughout the Software Development Life Cycle (SDLC), which is also an essential premise of the NIST Secure Software Development Framework (SSDF): the FDA-SPDF and NIST-SSDF emphasise a security-centric approach starting from design through development, all the way to deployment and potential decommissioning.
Mapping SSDF Elements to FDA Security Mandates
Secure Development Environment
The FDA's emphasis on ensuring a ‘secure development environment’ and clearly defined, documented security roles tie into the NIST Prepare the Organization (PO) practices PO.1, PO.2, and PO.5, which detail how the SSDF defines security requirements, names a security contact, and protects the software development environment.
Continuous Monitoring and Updates
The FDA’s requirements for post-market surveillance, maintaining up-to-date security logs, and the rapid development of patches directly match the NIST SSDF’s RV sections RV1, RV2, RV3, and RV4, which describe what happens after finding vulnerabilities. Plus, malware possesses ugly side effects, undermining the idea of personal responsibility and government oversight. It’s a vicious cycle: the more we automate medical and surgical procedures, the more we rely on bionic body parts and pacemakers, and the more we open the door to drive-by breaches and security incidents. Malware can evade detection and spread through the human body via implanted devices. Such malware could do so with little to no visible indications despite infecting vital systems such as the heart or brain – either by altering signals processed by those implants or directly controlling their operations.
Application of Security Controls
A few of the specific security controls the FDA recommends align exactly with NIST SSDF. For example, the cryptographic measures and integrity checks that can mitigate cybersecurity threats called out in SSDF’s Protect Software (PS) map to FDA’s PS.2, and the monitoring and detection of events along with logging to manage the cybersecurity threat align with the FDA’s requirements in RV.1. And the FDA’s requirement for secure authentication methods align with SSDF requirements in PO.1 (the assessment of security requirements) and PS.3 (control over data element and data movement, ensuring all data entered, egressed or changed during the operation of software are protected).
The NIST SSDF is an existing, well-established, and broadly recognised industry standard that lays the groundwork for creating secure software needed for operations. Since FDA final regulations now endorse a complete cybersecurity framework to protect medical device software through its lifecycle, adopting the NIST SSDF supports manufacturers seeking FDA approval by enabling compliance and improving a medical device’s security posture within the dynamic cybersecurity landscape.
Future Directions for Improving Medical Device Security
The writing on the wall is that patient care will only move further into a digital, connected future. Medtech manufacturers that refuse to produce secure medical device software are missing an opportunity to get their devices to market at the FDA’s request and earn patients’ trust and healthcare professionals’ confidence so that patients can fully take advantage of potentially life-changing medical treatments.
This level of security and trust can be accomplished if the manufacturer has a fully secure SDLC process and aligns with the FDA’s SPDF. Secure-by-design medical devices will require security to be baked into every device aspect – from the initial concept, development, delivery, and operation throughout the entire life cycle. It will enable the prevention of issues before they arise. As the future of healthcare becomes digital, by adopting rigorous security in the whole development lifecycle, manufacturers can deliver safe, secure, and effective devices that transform medicine and enrich patient care.