Medical devices have made a valuable contribution to enhancing patient care. However, they have also exposed healthcare organizations to new risks and created new pathways for attackers to gain unauthorized access to sensitive patient data or to manipulate care delivery processes.
In 2023 alone, 541 data breaches were reported to the U.S. Department of Health and Human Services[1] and an FBI report indicates that the number of ransomware attacks on healthcare facilities has doubled between 2021 and 2023.[2]
Healthcare organizations are a lucrative target for threat actors. Gaining access to patient data enables attackers to encrypt or hold this data to ransom, delaying critical treatment, and jeopardizing patient safety and care delivery. A late 2023 study shows that mortality rates rise when healthcare organizations suffer cyberattacks.[3]
For instance, in late 2023, the FDA found Medtronic’s MiniMed 600 Series Insulin Pumps to be susceptible to an exploit that could be leveraged to deliver too much or too little insulin to a patient.[4] Yet another medical device company ZOLL Medical revealed that a vulnerability in its LifeVest cardioverter defibrillator exposed addresses, Social Security Numbers, and birthdates of over 1mn users.[5]
Where are the weak links?
A 2023 survey indicates that 993 vulnerabilities were found across 966 healthcare products, representing a 53% YoY increase.[6] Of these, 160 vulnerabilities are weaponized – meaning that working PoCs exist that demonstrate how attackers can exploit them. Most vulnerabilities were found in Class II devices (medical devices with a moderate risk, e.g. anesthesia monitoring, infusion pumps, and CT scanners) – 292 across 367 products, as compared to 25 vulnerabilities across 41 products, affecting Class I devices (low-risk devices that are simple in design and have minimal potential to cause harm to the user), and 2 vulnerabilities across 20 products affecting Class III medical devices (high-risk devices that are intended to sustain or support life, or are implants that are critical to the body’s functioning).[7]
But more importantly, the survey found that 64% of overall vulnerabilities are software vulnerabilities[8] – and yet, only 2.13% of medical devices with a software component have cybersecurity content in their manuals.[9]
Enter new FDA regulations on cybersecurity of medical devices
On December 29, 2022, the Consolidated Appropriations Act, 2023 added Section 524B to the Federal FD&C (Food, Drug, and Cosmetic) Act, focused on cybersecurity of medical devices. Subsequently, on September 26, 2023, the FDA released guidance on cybersecurity in medical devices.
The new guidance supersedes the 2014 guidelines for premarket submissions and takes a thorough approach to mitigating cyber risks and security gaps affecting medical devices today. Whereas the previous guidelines encouraged transparency, the new guidelines mandate it by specifying detailed documentation requirements in pre-market submissions. Moreover, the amendment suggests that manufacturers systemically address cyber risks across the medical device software life cycle by adopting a cybersecurity framework.
Which devices does the new regulation apply to?
The new amendment applies to what are defined as cyber devices under section 524B. These are essentially medical devices that can connect to the internet and include a software element that could be vulnerable to cyber threats. It must be noted that any device that could connect to a network will be classified as a cyber device by the FDA’s definition.
The new regulation will affect manufacturers that plan to introduce a new version or variant of a cyber device. All manufacturers that plan to introduce their products in the US markets will also be required to conform to the new FDA requirements.
The new regulation will affect all manufacturers planning to introduce their products in the US markets as well as those that are planning to roll out a new version or variant of a cyber device.
Key highlights of the new regulations
With the latest amendments, the FDA now has statutory authority to enforce cybersecurity measures in medical devices.
This means that the FDA can refuse to accept submissions that fail to meet the cybersecurity requirements detailed in the Premarket Cybersecurity Guidance of Section 524B. Here are some of the key premarket submission requirements:
- A cybersecurity risk management report: This includes a threat model that explains all the potential vulnerabilities or security risks that could affect a product. In addition, a cybersecurity risk assessment should identify the likelihood of occurrence and severity of each risk. The cybersecurity risk management report should also enclose a Software Bill of Materials (SBoM) – an inventory of all open-source, 3rd party, and self-developed software components that constitute medical device software.
- Architecture views and diagrams: Premarket submission documentation should include diagrams that explain how a system is configured, how it connects with external systems and networks, and how external components interact with the device. This helps identify system boundaries and the radius of impact in the event of a compromise. In addition, manufacturers should also document how interactions between multiple components may create unique risks. Lastly, updateability and security views address how a device can be patched to protect it against known vulnerabilities, and whether the existing security controls are effective in various scenarios.
- Testing and labeling requirements: Beyond functional tests, manufacturers are now required to conduct security tests that demonstrate the application of adequate risk control measures. In addition, it is necessary to implement processes that enable software validation and risk analysis. Submissions should also include results for abuse cases, malformed inputs, and penetration tests. Some of these tests should also document the independence and expertise of the testers involved. Lastly, labeling requirements now mandate the inclusion of cyber risks in Informed Consent Forms.
- Cybersecurity management plan: This pertains to how device manufacturers plan to tackle cyber risks across the product life cycle. Manufacturers must detail the methods and frequency at which they will monitor and identify vulnerabilities in their products, how they plan to address vulnerabilities listed in the CISA known vulnerabilities catalog, and the timeline for releasing patches to address them. Vulnerability disclosure and update/patch release processes should also be included in the cybersecurity management plan.
Ensuring security across the device lifecycle
At the heart of FDA’s new guidance is the Secure Product Development Framework (SPDF), which aims to ensure security-by-design by mitigating risks across the product life cycle. Secure Product Development Framework requires medical device manufacturers to embed cybersecurity considerations across all phases of the product life cycle, from design and development to support and decommissioning.
The key purpose of SPDF is to ensure that cybersecurity considerations are not an afterthought in the medical device software development process. With the prescribed practices, it aims to:
- Facilitate tamper-proof operation of the device by ensuring only authorized users and devices can gain access to data and controls,
- Maintain availability and functionality of devices in the face of attempts to disrupt accessibility and serviceability,
- Protect the confidentiality of sensitive patient data to comply with privacy laws maintain patient trust, and
- Ensure that devices can be updated or patched securely to respond to vulnerabilities.
The new FDA guidance provides specific recommendations on how to achieve these objectives with various security controls like authentication, cryptography, event logging, code, and data integrity, among others. In the case of authentication, for example, manufacturers must be able to ensure the authenticity of data at rest and in transit, authentication of communication endpoints, integrity of execution state, and software binaries.
It must be noted that SPDF is not a rigid framework. Instead, it offers manufacturers the flexibility to adopt alternative approaches and frameworks that will help them meet the new premarket submission requirements. Rather than reinventing the wheel, it encourages manufacturers to continue using existing processes that are effective in mitigating cyber risks.
Staying compliant from the get-go: start with a secure SDLC
To sum it up, SPDF makes it easier for medical device manufacturers to comply with the premarket submission requirements outlined in the new FDA regulations. The gist of the SPDF is that cyber risk considerations and security controls should be incorporated into the entire SDLC.
One of the most comprehensive frameworks that addresses security risks across the software development life cycle is the NIST Secure Software Development Framework (SSDF), or NIST SP 800-218. Based on our experience, NIST SSDF provides an excellent approach to secure the medical software life cycle and aligns well with the FDA’s SPDF.
How NIST SSDF maps to FDA’s new cybersecurity requirements
FDA’s vision of integrating security across the SDLC resonates with the very foundations of the NIST SSDF. Like the FDA SPDF, which advocates secure practices from design and development to support and decommissioning, SSDF’s overarching structure calls for the integration of security practices from design to post-market updates.
Here’s how the elements of NIST SSDF map to FDA’s specific security requirements:
Looking for Custom Healthcare Software Development Services?
Contact Us- FDA’s emphasis on creating a secure development environment, and designating security roles and responsibilities from the get-go, maps to NIST Prepare the Organization (PO) 1, 2, and 5. PO.1, PO.2, and PO.5 outline key tasks, implementation examples, and references for defining security requirements, designating security personnel, and implementing secure environments for software development.
- FDA mandates continuous monitoring, maintaining up-to-date records of security issues, and timely development of updates and patches. This maps to Respond to Vulnerabilities (RV) 1, 2, 3, and 4 in NIST SSDF – which correspond to the identification, assessment, and addressing of vulnerabilities, and confirming application of updates, respectively.
- More specific recommendations on security controls in the FDA guidance also align well with the prescribed practices in NIST SSDF. For instance, the application of cryptographic measures and running integrity checks are covered under PS.2 (Protect Software) in NIST SSDF. Similarly, RV.1 in NIST SSDF emphasizes the importance of event detection and logging tools to detect and respond to potential cybersecurity threats. Similarly, FDA’s mandate for applying strong authentication methods map to PO.1 (Defining Security Requirements), and PS.3 (Protect All Forms of Data).
NIST SSDF is a mature framework that is already being used by thousands of organizations to develop secure software for mission-critical applications. With the latest FDA regulations mandating the adoption of a comprehensive cybersecurity framework to secure the medical device software life cycle, manufacturers will be well-positioned to get FDA approvals by adopting the NIST SSDF.
Next steps
The future of patient care is unarguably connected and digitally enabled. In this future, medical device manufacturers cannot afford to leave their medical device software inadequately secured. With secure and connected medical devices, medical device manufacturers can win not only FDA approval but also patient and practitioners’ trust and make life-altering interventions accessible en masse. To make this a reality, manufacturers need to adopt a secure SDLC, which aligns well with the FDA’s SPDF.
Develop compliant medical device software with DataArt
DataArt has helped medical device companies effectively navigate the new FDA requirements by implementing the NIST SSDF to secure medical device software development, preventing costly rejections and delays in bringing a medical device to market. In addition to developing compliant medical device software, DataArt experts can also guide medical device companies’ in-house development teams through the requirements of the new regulation to ensure their software meets all necessary FDA requirements.
Interested to learn more?
Connect with Daniel Piekarz on LinkedIn.
