PATCH Act: How to Comply in 2023 & Beyond

What is the Patch Act? 

H.R. 7084, also known as the “PATCH Act of 2022,” outlines a framework for minimal cybersecurity focus within medical devices. The Patch Act (Protecting and Transforming Healthcare Act) has been in development for several years, and a key section grants the FDA long-awaited authority to strengthen its cybersecurity guidance for medical device premarket submissions and post market security management. While the Act and FDA Guidance reflect best practices, the diverse landscape of medical device systems and software ecosystems poses challenges for effective implementation. In particular, the requirement for a Software Bill of Materials, or SBOM, while well-intentioned, isn’t particularly useful to regulators or to users. In fact, the guidance can even make it easier for hackers to exploit known vulnerabilities to compromise patient safety.

When does the Patch Act of 2022 become mandatory?

The Patch Act comes into force on October 1, 2023. The act specifies creation, tracking, and submission of the following: 

• Product monitoring plan
• Product cyber-anomaly response plan
• Coordinated messaging of cyber vulnerabilities
• Product software releases on a ‘reasonably justified regular cycle’
• Software Bill of Materials (SBOM)
• Ability to release a critical vulnerability patch ‘as soon as possible’
• Collect and maintain additional information in the future

What are the Major Patch Act Dates?

• October 1, 2023: The Patch Act comes into effect. The FDA expects that sponsors of such cyber devices will have had sufficient time to prepare premarket submissions that contain information required by section 524B of the FD&C Act, and the FDA may Refuse to Accept (RTA) premarket submissions that do not. 
• March 29, 2023 - October 1, 2023: During this period, the FDA's general approach is to refrain from issuing "refuse to accept" (RTA) determinations for premarket submissions of cyber devices submitted before October 1, 2023, recognizing these months as a type of flexible period for preparing for the new requirements. Instead, the FDA will adopt a collaborative stance during this time by engaging with the premarket submissions’ sponsors through interactive processes and deficiency reviews to determine whether a cyber device is approved. 
• March 29, 2023: The new cybersecurity prerequisites are not relevant to an application or proposal that has been presented to the FDA before this date. However, if a cyber device previously granted authorization implements new alterations that require FDA evaluation, the new legislation rules would be applicable to the updated premarket proposal. 
• December 29, 2022: The Consolidated Appropriations Act, 2023 ("Omnibus") was signed into law. Section 3305 of the Omnibus — "Ensuring Cybersecurity of Medical Devices" —amended the Federal Food, Drug, and Cosmetic Act (FD&C Act) by adding section 524B, Ensuring Cybersecurity of Devices. The Omnibus states that the amendments to the FD&C Act shall take effect 90 days after the enactment of this Act on March 29, 2023.

How does the Patch Act work with Substantial Equivalence? 

In evaluating substantial equivalence under the section for a Cyber Device (defined below), the FDA will be able to:

1. Determine that the cybersecurity information presented for the Cyber Device within its relevant premarket application, particularly in the context of its usage environment, is insufficient. 
2. Issue a non-substantial equivalence determination based on this insufficiency finding.

Patch Act compliance & auditing in 2023 

What products meet the “Cyber Device” definition?

According to the Patch Act, the term “Cyber Device” means a device that either (A) incorporates software; or (B) is designed to establish an internet connection. 

This definition emerges due to the changing nature of safety critical systems, such as medical devices. Medical devices range from implantables, such as pacemakers and prosthetics, to proton beam accelerators and biological testing to mobile health apps, and more. They are used in a variety of environments, including implanted within the body, in healthcare facilities, at home, as wearables and in urban, rural, remote and even military combat settings. In addition, medical devices can be standalone or interconnected using the cloud and other network systems. Historically, devices were made with little third party software, but today most devices rely on some percentage of Off-the-Shelf (OTS) software and open source software – which may not have been specifically designed for safety critical systems.

Ultimately the purpose of this legislation is to provide a framework for reducing patient risk. If we examine each of the outlined requirements through this lens the scope of each requirement comes into focus.

Patch Act Requirements

Software bill of materials (SBOM)

Open source software provides access to a vast library of pre-existing code and tools that can be used to accelerate development and reduce the time and cost of creation. By leveraging open source software, developers can benefit from the collective expertise of the open source community, which can help solve complex problems and improve the quality of the final product. Reliance on this ever-evolving code supply chain has the potential to introduce vulnerabilities into your final shipping product. 

The requirement to supply an SBOM is more than just a listing of what code sources are in use, it’s also tracking the versions, vulnerabilities, and risk evaluations for all code sources. From a risk standpoint, it’s important to know that the libraries in use are vulnerability free or that identified vulnerabilities are not within your specific code path. 

An effective SBOM tracks all software sources and associated cybersecurity risk and mitigations of said sources. In addition, since you’re typically operating in a validated environment your SBOM needs to link to applicable test cases that verify any assertions. 

Product monitoring plan

For connected device vulnerabilities:

If a product has an online or ‘connected’ capability then the interfaces facing the traversal media (IE: bluetooth, internet, etc) are obvious attack surfaces. If a device has the ability to transmit telemetry back to the organization, it should do so with a strong focus toward anomalous behavior. This is your organization's opportunity to catch behavior ‘in the wild’ and hopefully before it becomes threatening. 

For offline device vulnerabilities: 

Just because a device isn’t connected to the internet doesn't mean it can ignore the potential for cybersecurity threats. Is there a potential device configuration that can cause harm or malfunction? What could an undocumented jumper configuration do? There’s a judgment call here as to how far outside intended use a threat should be considered but products should be able to self-detect and report to the user when an error state is entered. 

Of these vulnerability groups, online monitoring immediately conjures images of WarGames style control rooms monitoring fleets of devices, and the associated expense. I wouldn’t discourage anyone from building such a configuration but monitoring can also be as simple as a serverless api and database. This is your organization's opportunity to catch aberrant behavior and correct it before impact. It’s vital. I can see the future case being made that if your device is online already, is the lack of fractional amount of additional effort to monitor negligent? 

Offline monitoring is more “traditional” in that reports from the field need to come in and be tracked. There are established processes for this and this is not a new concept introduced in this bill. 

Cyber response plan

That PATCH act “asks,” if a vulnerability is discovered, who and what actions would be necessary to assess and document risk? How would this be communicated with clients and what timeframe for remediation? 

Almost all organizations have a cyber security response plan for corporate assets. This requirement extends such plans to individual products/devices. Just as in the corporate asset version, are there time-dependent remediations that need to occur within hours, and how does such an assessment happen? For better or worse, cyber incident response is an established field with numerous guides and training available. Applicability to a specific product both narrows the risk and scope. 

Coordinated disclosure

The PATCH act specifically calls for planning on how to communicate vulnerabilities to appropriate parties. Typically this is a subsection of an incident response plan and would be a coordinated effort amongst many internal groups. The key item with disclosure is the coordination of messages over time and that they reach the necessary parties. Think of a future date when an auditor may review all previous disclosures at once; are the messages consistent, accurate, and forthcoming even with the benefit of hindsight? 

Software releases

The act calls for software updates on a ‘justified regular cycle,’ as well as the capability to do an ASAP ‘out of cycle’ update. 

The first question that comes to mind is “what is a reasonable cycle time?” The answer is product specific, but the goal here is to mitigate the risk of a cyber vulnerability and risks introduced by a non-standardized release process. By having a regular release cycle that can carry the appropriate vulnerability corrections, the process itself can be monitored for effectiveness. 

In regards to an ASAP out-of-cycle release, in my opinion, all organizations should have the minimal capability to generate a narrowly-scoped patch in less than 30 days. (Distribution and application not included). This includes all necessary validation and tracking. Commercial (non-validated) software patch releases can measure from minutes to days to address identified critical vulnerabilities. There’s necessary additional overhead for a validated system but one needs to consider the liability of any extended period of time. 

Ensuring Cybersecurity in Pre- and Post-Market Surveillance

To ensure cybersecurity throughout the entire lifecycle of a cyber device, anyone submitting a premarket application for such a device must include information to confirm that the cyber device aligns with determined cybersecurity standards aimed at reasonably assuring its safety and effectiveness. At the very least, these cybersecurity standards include:

• Manufacturers of cyber devices must establish a plan to effectively monitor, detect, and address cybersecurity vulnerabilities and potential exploits within a reasonable timeframe after the device's introduction to the market.
• Manufacturers are obligated to:
  — Develop a plan and procedures for Coordinated Vulnerability Disclosure, which should be integrated into submissions to the FDA.
  — Maintain additional information specified by the Secretary, as required through processes such as Federal Register orders, to ensure the cyber device's safety and effectiveness.
• Manufacturers must create, develop, and maintain processes and protocols for providing updates and patches for the cyber device and associated systems throughout its existence. These processes must address:
  — Known vulnerabilities on a reasonable and justifiable regular basis.
  — Critical vulnerabilities, which could pose uncontrolled risks, as soon as possible, even if outside of regular cycles.

What industries are most impacted by the Patch Act?

The MedTech industries will be most affected by the Patch Act come October 1st. However, a more comprehensive list includes: 

• Medical Device Manufacturers: Manufacturers of medical devices, especially those incorporating software and having internet connectivity, are directly impacted. They need to comply with new requirements for cybersecurity measures, including monitoring vulnerabilities, developing disclosure plans, providing software bill of materials (SBOM), and issuing timely updates.
• Healthcare Providers and Systems: Healthcare providers using medical devices that fall under the definition of "cyber device" will need to ensure that they have proper processes in place to manage and apply necessary cybersecurity updates and patches. This is particularly relevant in healthcare facilities, where these devices are in use.
• Healthcare IT Professionals: IT professionals working in healthcare organizations will likely be responsible for ensuring that medical devices' cybersecurity requirements are implemented effectively. They may need to coordinate with manufacturers, apply updates, and maintain security measures.

In particular, any cyber devices in these industries that fall under the following premarket submission categories: section 510(k), 513, 515(c), 515(f), or 520(m).

How to ensure postmarket cybersecurity vulnerabilities are monitored

Manufacturers can follow these general guidelines to ensure best practices when handling the latest FDA requirements:

1. Vulnerability Tracking System: Implement a robust system to track and manage cybersecurity vulnerabilities and risks. This system, which should use regulatory vulnerability scans, should allow for efficient identification, assessment, and prioritization of vulnerabilities, as well as methods for implementing changes quickly and effectively. 
2. Post-market Surveillance and Incident Response Plan: Create an incident response plan that outlines how the company will respond to identified vulnerabilities or breaches in development and post-market surveillance. Define roles, responsibilities, communication channels, and steps to mitigate risks promptly that are reported from inside the organization or outside from users. 
3. Patch Management: Establish a systematic process for developing, testing, and deploying patches and updates to address vulnerabilities. Prioritize critical vulnerabilities for immediate patching in a reasonable amount of time, and regularly review and test the effectiveness of your vulnerability management processes. This includes testing patches in a controlled environment before deploying them to production devices.
4. Documentation and Traceability: Maintain comprehensive documentation of all vulnerability management activities, including vulnerability scans, assessments, patch deployments, and incident responses for ideal traceability.
5. Audit and Compliance Checks: Regularly conduct internal audits and compliance checks to ensure that your vulnerability management processes align with the requirements of the Patch Act. Implement continuous monitoring and data analytics to identify potential anomalies or suspicious activities in devices' network traffic, behavior, or usage patterns.

Remember that the specifics of implementing these steps may vary depending on the nature of your medical devices, the associated risks, and the regulatory environment. However, despite this reminder, most R&D and Quality teams will find these practices overwhelming due to the iterative and fast-changing software environments. On top of maintaining best practices and attention to detail within the software lifecycle, it is also essential to stay up-to-date with the latest guidance and regulations related to medical device cybersecurity—and implement these latest recommendations into your team’s SOPs. 

Tools for Patch Act compliance and FDA audits

While the implementation of the PATCH Act will undoubtedly alter your company's software process, it shouldn’t grind your development cycles to a halt. By approaching these new requirements with care and consideration, you can enhance user safety and mitigate risk proactively, thereby avoiding potentially disastrous scenarios down the line and avoiding any rejections from the FDA based on your cybersecurity processes. 

Luckily, tools are starting to catch up with regulatory demands, but it is up to your team to determine what is needed to succeed. If the necessary regulatory tasks are already overwhelming your team, taking time away from development, and delaying product releases, there are automated options to support teams seeking to follow their SOPs in an effective way. 

Ketryx, a connected lifecycle management tool, offers a comprehensive platform that can assist teams in complying with the Patch Act by streamlining their software development processes and integrating with modern development tools like Jira, Github, and AWS. Ketryx offers all of the following:

• FDA-Grade Cybersecurity 
• Automated and traceable software lifecycle 
• Pre-built GxP Development Infrastructure
• Continuous Configuration Management
• Automated traceability and documentation
• Change Control Management
• Post-Market Surveillance

Want to learn more about the FDA and the latest regulations? Check out our eBook Inside the FDA Regulatory Process in the Ketryx Learning Center, or explore our blog posts ”Why the FDA’s Most Common Warning Letter Might Surprise You” and “The FDA drops a Cybersecurity Compliance SBOM in 2023.” 

‍Want to get started with Ketryx? Schedule a demo with our team today and keep your regulated software compliant!