Implementing the FDA's 2023 Requirements for Medical Device Cybersecurity

Among the upsurge in cyberattacks on the healthcare industry in the last couple of years, medical devices are increasingly being targeted. And with patients’ wellbeing, or even their lives, hanging in the balance, the stakes are uniquely high.

The FDA's 2023 legislation, H.R. 2617 Section 524B, introduces stringent cybersecurity requirements for product security of medical devices. If you are a medical device manufacturer or healthcare provider, or if you handle sensitive patient data, it’s highly likely your organization will be impacted by this regulation in some way.

To help organizations understand the importance of this legislation and take appropriate action, Bishop Fox’s Senior Solutions Architect Matt Twells hosted a webcast, Pacemakers to Pacesetters: What the FDA’s 2023 Cybersecurity Requirements Really Mean and Putting Them Into Practice at Scale. This webcast offers recommendations to help organizations build a robust cybersecurity plan, address vulnerabilities, manage supply chain risks, and decipher how to anticipate future trends.

Watch the webcast on demand to dig into the details, or keep reading for a summary of the highlights.

What is HR.2617, Section 524B, and Why Was It Introduced?

H.R. 2617 Section 524B focuses specifically on cybersecurity requirements for medical devices and is part of the Consolidated Appropriations Act of 2023, which became effective on March 29, 2023.

Most significantly, this legislation extends manufacturers’ responsibility beyond simply getting a device to market. Manufacturers must now continuously monitor their devices throughout the entire lifecycle and promptly issue updates and patches to fix security vulnerabilities.

The regulation’s definition of “cyber device” is deliberately broad to capture a wide range of devices, including many not traditionally considered “smart.” If your device can connect to a network of any kind — which most modern medical devices can — to share patients’ medical information and receive software updates, then this regulation almost certainly applies to your organization.

From a cybersecurity perspective, medical devices are increasingly treated as any other IoT (Internet of Things) devices. As well as having a network connection, many medical devices now use commercial off-the-shelf hardware and communicate via Bluetooth or WiFi — unlike the unconnected, largely standalone medical devices of old.

The FDA’s New Expectations for Medical Device Security

Section 524B introduces four new, major expectations that medical device manufacturers need to comply with:

• Continuous monitoring: Ongoing, real-time surveillance of a device’s security posture even after FDA approval and market launch.
• Software Bill of Materials (SBOM): A living document containing an inventory of all software components used in the development and implementation of a medical device, including any known vulnerabilities.
• Coordinated Vulnerability Disclosure (CVD): An official policy and process for reporting and evaluating vulnerabilities when discovered, with an emphasis on collaboration between manufacturers and the vulnerability research community.
• Lifecycle approach: Demonstrable security controls and monitoring in place throughout the entire product lifecycle, from design to decommissioning.

The biggest and most immediate penalty for non-compliance with HR.2617 Section 524B is the FDA issuing a Refusal to Accept (RTA). An RTA means the device is ineligible for evaluation for FDA approval, without which you cannot market your device. In the US, selling a medical device legally requires FDA approval, which verifies that it meets safety, efficacy, and quality regulatory standards. Further denting your bottom line, you may also incur financial penalties for non-compliance.

But in the long run, the biggest cost is probably reputational. If a customer loses trust in a manufacturer due to a non-compliant device, their reluctance to buy will extend to the manufacturer’s entire portfolio of devices.

Operationalizing the FDA’s New Expectations Under HR.2617, Section 524B

So, what does compliance with this regulation mean in practice?

As always, a robust cybersecurity plan is key. You’ll almost certainly need to create some degree of new processes and policies while assigning updated roles and responsibilities to relevant stakeholders. While you can’t ensure perfect compliance immediately, you can show evidence of taking steps in the right direction, which carries weight with auditors.

Here are some practical steps organizations can start taking:

Continuous Monitoring

Implementing continuous monitoring of your devices requires some effort to set up, but once in place, it will provide enormous benefits across your organization for the overall security posture.

Key steps include:

• Establish a baseline. What does normal device activity look like? You need this knowledge to quickly spot anything out of the ordinary.
• Conduct a criticality analysis. Which assets, systems, and software are genuinely mission-critical for your device? This tells you where to prioritize your efforts.
• Use the right tool for the right job. Security audits, code reviews, penetration tests, and vulnerability assessments all support your monitoring obligations in various capacities. Know how each tool fits into the bigger security puzzle.
• Sharpen your triage process. Triaging helps ensure that you are filtering and prioritizing the alerts and information you’ve identified as most important for your device and your organization’s security. Define the types of information that can be deprioritized as well.

Software Bill of Materials

Typically, this should be one of the easier parts of the regulation to comply with because of the tools available to help you build an SBOM. 

For each device, you need to:

• Decide which type of SBOM is needed: one based on design documents, source code analysis, third party analysis, or other SBOMs post-deployment.
• Create an inventory of all the software and components in use on your device.
• Choose an industry-standard format for your SBOM, to ensure interoperability. E.g. SPDX, CycloneDX, and SWID.
• Use an automated tool to create your SBOM. (Multiple options include Kubernetes bom, the Maven DevOps tool’s CycloneDX plugin, Microsoft’s SBOM tool Syft).

Coordinated Vulnerability Disclosure

As well as ensuring regulatory compliance, a documented process for discovering and disclosing vulnerabilities will also significantly improve your organization’s cybersecurity posture.

Key steps to set up a CVD process include:

• Establish a CVD mechanism. Make it as simple as possible to increase the likelihood of people using it. E.g. a Microsoft Forms page or dedicated email inbox.
• Decide roles and responsibilities for managing the process and investigating reported vulnerabilities.
• Set clear expectations and workflow. Specify the processes, timelines, formatting, and any rewards involved.
• Evaluate CVD submissions fairly and communicate clearly. Everyone who reports a vulnerability should be treated the same.
• Document and use lessons learned to improve the CVD process.

Lifecycle approach

One of the biggest paradigm shifts from this regulatory change is the defining of medical device security as a lifecycle event, from development to decommissioning.

So you need to consider: How will people use my device? How can anyone involved at any step of the device’s lifecycle misuse one of the tools or components?

You’ll need a whole range of tools, processes, and policies for different lifecycle stages: from threat modeling and risk assessments during design, to continuous monitoring and patching while in use, to securely disposing of end-of-life devices.

Key steps to operationalizing a lifecycle approach include:

1. Identify the assets you want to protect, both tangible and intangible.
2. Map the attack surface.
3. Define the main threat actors.
4. Identify potential ways an adversary could successfully attack your device.
5. Conduct a vulnerability assessment.
6. Evaluate risks and prioritize based on your established triage process.
7. Identify mitigation strategies.
8. Assign responsibilities to security, development, and legal teams for acting on the threat model.

Looking Ahead: The GAO Report

The Government Accountability Office (GAO) has issued a report to accompany H.R. 2617, identifying challenges in cybersecurity for medical devices. If you’re not sure where to start by complying with H.R. 2617 Section 524B, the GAO report is a great starting point, as it contains a wealth of useful information for anyone tasked with compliance.

The Far-Reaching Benefits of Compliance

Although operationalizing the FDA’s new expectations under H.R. 2617 Section 524B will take time and effort to meet, your organization will reap the benefits far beyond regulatory compliance alone.

Having better visibility into what's happening throughout the device’s lifecycle means you can provide a better quality of service to your customers as well as strengthen your organization’s overall security posture.

Catch the full webcast here to access the in-depth discussion of practical steps your organization can take towards complying with H.R. 2617 Section 524B.