Christopher Gates, Director of Product Security, Velentium05.09.23
This month’s topic is a look forward to the coming year in the regulation of medical device cybersecurity, as well as a brief look backward to see how history brought us here.
In 2022, there were two changes to medical device regulation that affect the cybersecurity activities of medical device manufacturers (MDMs) for the foreseeable future.
1. The FDA’s latest version of the “premarket cybersecurity guidance” (officially titled “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions”) in April 2022.1
2. In December 2022, the $1.7 trillion “Consolidated Appropriations Act of 2023” (more commonly referred to as the Omnibus Act) was passed and signed into law on Dec. 29th (for those who like to read large government written documents, refer to page 1,374 – Section 3305 “Ensuring Cybersecurity Of Medical Devices”).2 The amendment to the Food, Drug, and Cosmetic Act expands the scope of the FDA beyond just “safety and efficacy” to include medical device cybersecurity. This amendment is similar to a “watered-down” version of the PATCH Act from late 2022. On March 29, 2023, the FDA gained the legal authority to define and enforce medical device cybersecurity. For many years, the FDA had the implied authority to regulate cybersecurity, but now it is a clear mandate from Congress.
These changes give the FDA extensive legal authority to manage all aspects of medical device cybersecurity.
Let’s first examine the language of the Omnibus Act for what is required for submissions. (It should be noted the title uses the word “requirements,” not “guidelines” or “non-binding recommendations,” etc.).
‘‘(b) CYBERSECURITY REQUIREMENTS.—The sponsor of an application or submission described in subsection (a) shall—
‘‘(1) submit to the Secretary a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures;
‘‘(2) design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure, and make available postmarket updates and patches to the device and related systems to address—
‘‘(A) on a reasonably justified regular cycle, known unacceptable vulnerabilities; and
‘‘(B) as soon as possible out of cycle, critical vulnerabilities that could cause uncontrolled risks;
‘‘(3) provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components; and
‘‘(4) comply with such other requirements as the Secretary may require through regulation to demonstrate reasonable assurance the device and related systems are cybersecure.”
Let’s unpack these requirements to see what they really mean.
Item 1: This shouldn’t come as a surprise to any manufacturer; this has been the stated position of the FDA for several years.
Item 2: A secure “total product lifecycle” has been the mantra for the FDA for the last few years, and since the April 2022 guidance, we have seen the added requirement of a regular cadence of patches for vulnerabilities. This certainly makes sense for devices that are commercial operating system-based, such as Windows, but makes less sense for non-OS based devices, such as “bare metal” designs. Likewise “as soon as possible” updates due to security events are nothing new; however, the vagaries of the timeframe certainly conflict with the 2016 postmarket guidance of 60 days to distribute a fix.3
Item 3: SBOMs are here to stay (no matter how many complaints are hurled by those who are reluctant to create SBOMs). Since the 2018 draft guidance, the FDA has led the way (later picked up by the White House in its Executive Order4) of including SBOMs as part of cybersecurity activities. Much has already been written about SBOMs, and there are certainly a plethora of tools (both open source and commercial) to support the creation, management, distribution, and consumption of SBOMs. Is there room for improvement? Absolutely! There will always be advancements and changes to this and other cybersecurity activities. That isn’t a justification for failing to implement the best practice today.
Item 4: This is the big clause: The FDA has been given open-ended authority to manage medical device cybersecurity. How far will the FDA take this? Well, I think you don’t need to look any further than the April 2022 guidance. Certainly, that document will no longer contain “non-binding recommendations,” but instead “requirements for device manufacturers.” Further, this is just the FDA in its “crawl” phase (of the famous “crawl/walk/run” model), having only been given $5 million with this Act to start to address cybersecurity. The future may include other cybersecurity requirements such as:
The next section in the Omnibus Act addresses “definitions” again, going to the language of the act itself:
‘‘(c) DEFINITION.—In this section, the term ‘cyber device’ means a device that—
‘‘(1) includes software validated, installed, or authorized by the sponsor as a device or in a device;
‘‘(2) has the ability to connect to the internet; and
‘‘(3) contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.”2
This is a pretty broad definition for the types of devices that are subject to this new law. Certainly, phrases like “ability to connect to the internet” seem to imply an Ethernet or Wi-Fi interface, but what about Bluetooth Low Energy connections to a smartphone? Or the third term “technological characteristics…that could be vulnerable to threats”—isn’t that pretty much all “technological characteristics”?
The following sections give the FDA the power to define exactly those kinds of edge conditions and more with these two sections:
‘‘(d) EXEMPTION.—The Secretary may identify devices, or categories or types of devices, that are exempt from meeting the cybersecurity requirements established by this section and regulations promulgated pursuant to this section. The Secretary shall publish in the Federal Register, and update, as appropriate, a list of the devices, or categories or types of devices, so identified by the Secretary.’’2
And then this:
“(c) RULE OF CONSTRUCTION.—Nothing in this section, including the amendments made by this section, shall be construed to affect the Secretary’s authority related to ensuring that there is a reasonable assurance of the safety and effectiveness of devices, which may include ensuring there is a reasonable assurance of the cybersecurity of certain cyber devices, including for devices approved or cleared prior to the date of enactment of this Act.”2
This gives the FDA complete authority to define any aspect of medical device cybersecurity including overriding what is said in the Omnibus Act itself. Since the GAO will be auditing how this is implemented by the FDA, you can be sure they are going to be diligent in doing it in a rigorous fashion.
Some worry that giving the FDA authority to enforce cybersecurity on March 29, 2023, while the premarket guidance won’t be finalized until six months later—September 2023 (at the earliest)—is unfair to manufacturers, but the FDA has been pursuing this goal since 2014 in the original premarket guidance. Six months is very little time for the FDA to make any changes (it works on a different time scale than the rest of us), so a safe assumption is none of the substantive requirements will be materially changed for the final version. Also, the FDA has stated it will be using the review process to inform MDMs of cybersecurity omissions in their submissions to the agency until October 2023, when the required security artifacts will be added to the Refuse To Accept (“RTA”) checklist and, therefore, a submission will not even reach the FDA’s review process before being rejected if there are missing security artifacts in the submission.
Bottom line, read and implement the activities in the April 2022 premarket guidance, and you will be on fairly safe ground in achieving what the FDA wants this year. But remember, this will continue to change and grow for years to come, so also remain flexible in how you approach security in your organization. Finally, get your employees trained in operation technology cybersecurity; it’s long overdue.
The next issue will be a more technical column as we review one new aspect of medical device cybersecurity—“in the field” updating and patching of medical devices. If you think this is a simple process, you don’t understand all the aspects of this topic and next issue’s column will be for you.
References
Christopher Gates is the director of Product Security at Velentium. He has more than 50 years of experience developing and securing medical devices and works with numerous industry-leading device manufacturers. He frequently collaborates with regulatory and standard bodies, including the CSIA, Health Sector Coordinating Council, H-ISAC, Bluetooth SIG, and FDA to present, define, and codify tools, techniques, and processes that enable the creation of secure medical devices. Gates promotes the use of a “secure development lifecycle,” the industry-leading approach that ultimately eases the burden on developers and ensures high-quality products that work as intended to save and improve lives.
In 2022, there were two changes to medical device regulation that affect the cybersecurity activities of medical device manufacturers (MDMs) for the foreseeable future.
1. The FDA’s latest version of the “premarket cybersecurity guidance” (officially titled “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions”) in April 2022.1
2. In December 2022, the $1.7 trillion “Consolidated Appropriations Act of 2023” (more commonly referred to as the Omnibus Act) was passed and signed into law on Dec. 29th (for those who like to read large government written documents, refer to page 1,374 – Section 3305 “Ensuring Cybersecurity Of Medical Devices”).2 The amendment to the Food, Drug, and Cosmetic Act expands the scope of the FDA beyond just “safety and efficacy” to include medical device cybersecurity. This amendment is similar to a “watered-down” version of the PATCH Act from late 2022. On March 29, 2023, the FDA gained the legal authority to define and enforce medical device cybersecurity. For many years, the FDA had the implied authority to regulate cybersecurity, but now it is a clear mandate from Congress.
These changes give the FDA extensive legal authority to manage all aspects of medical device cybersecurity.
Let’s first examine the language of the Omnibus Act for what is required for submissions. (It should be noted the title uses the word “requirements,” not “guidelines” or “non-binding recommendations,” etc.).
‘‘(b) CYBERSECURITY REQUIREMENTS.—The sponsor of an application or submission described in subsection (a) shall—
‘‘(1) submit to the Secretary a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures;
‘‘(2) design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure, and make available postmarket updates and patches to the device and related systems to address—
‘‘(A) on a reasonably justified regular cycle, known unacceptable vulnerabilities; and
‘‘(B) as soon as possible out of cycle, critical vulnerabilities that could cause uncontrolled risks;
‘‘(3) provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components; and
‘‘(4) comply with such other requirements as the Secretary may require through regulation to demonstrate reasonable assurance the device and related systems are cybersecure.”
Let’s unpack these requirements to see what they really mean.
Item 1: This shouldn’t come as a surprise to any manufacturer; this has been the stated position of the FDA for several years.
Item 2: A secure “total product lifecycle” has been the mantra for the FDA for the last few years, and since the April 2022 guidance, we have seen the added requirement of a regular cadence of patches for vulnerabilities. This certainly makes sense for devices that are commercial operating system-based, such as Windows, but makes less sense for non-OS based devices, such as “bare metal” designs. Likewise “as soon as possible” updates due to security events are nothing new; however, the vagaries of the timeframe certainly conflict with the 2016 postmarket guidance of 60 days to distribute a fix.3
Item 3: SBOMs are here to stay (no matter how many complaints are hurled by those who are reluctant to create SBOMs). Since the 2018 draft guidance, the FDA has led the way (later picked up by the White House in its Executive Order4) of including SBOMs as part of cybersecurity activities. Much has already been written about SBOMs, and there are certainly a plethora of tools (both open source and commercial) to support the creation, management, distribution, and consumption of SBOMs. Is there room for improvement? Absolutely! There will always be advancements and changes to this and other cybersecurity activities. That isn’t a justification for failing to implement the best practice today.
Item 4: This is the big clause: The FDA has been given open-ended authority to manage medical device cybersecurity. How far will the FDA take this? Well, I think you don’t need to look any further than the April 2022 guidance. Certainly, that document will no longer contain “non-binding recommendations,” but instead “requirements for device manufacturers.” Further, this is just the FDA in its “crawl” phase (of the famous “crawl/walk/run” model), having only been given $5 million with this Act to start to address cybersecurity. The future may include other cybersecurity requirements such as:
- Limits to be placed on the age of medical devices in use at health delivery organizations
- Certification of medical device security
- Review of all legacy medical devices still in use
- More extensive SBOMs
- The FDA monitoring all of the submitted SBOMs for disclosed vulnerabilities
- Universal methods of updating devices in the field
- Approval being denied for the inclusion of out-of-date or end-of-supported software components
- Pretty much anything else you can think of
The next section in the Omnibus Act addresses “definitions” again, going to the language of the act itself:
‘‘(c) DEFINITION.—In this section, the term ‘cyber device’ means a device that—
‘‘(1) includes software validated, installed, or authorized by the sponsor as a device or in a device;
‘‘(2) has the ability to connect to the internet; and
‘‘(3) contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.”2
This is a pretty broad definition for the types of devices that are subject to this new law. Certainly, phrases like “ability to connect to the internet” seem to imply an Ethernet or Wi-Fi interface, but what about Bluetooth Low Energy connections to a smartphone? Or the third term “technological characteristics…that could be vulnerable to threats”—isn’t that pretty much all “technological characteristics”?
The following sections give the FDA the power to define exactly those kinds of edge conditions and more with these two sections:
‘‘(d) EXEMPTION.—The Secretary may identify devices, or categories or types of devices, that are exempt from meeting the cybersecurity requirements established by this section and regulations promulgated pursuant to this section. The Secretary shall publish in the Federal Register, and update, as appropriate, a list of the devices, or categories or types of devices, so identified by the Secretary.’’2
And then this:
“(c) RULE OF CONSTRUCTION.—Nothing in this section, including the amendments made by this section, shall be construed to affect the Secretary’s authority related to ensuring that there is a reasonable assurance of the safety and effectiveness of devices, which may include ensuring there is a reasonable assurance of the cybersecurity of certain cyber devices, including for devices approved or cleared prior to the date of enactment of this Act.”2
This gives the FDA complete authority to define any aspect of medical device cybersecurity including overriding what is said in the Omnibus Act itself. Since the GAO will be auditing how this is implemented by the FDA, you can be sure they are going to be diligent in doing it in a rigorous fashion.
Some worry that giving the FDA authority to enforce cybersecurity on March 29, 2023, while the premarket guidance won’t be finalized until six months later—September 2023 (at the earliest)—is unfair to manufacturers, but the FDA has been pursuing this goal since 2014 in the original premarket guidance. Six months is very little time for the FDA to make any changes (it works on a different time scale than the rest of us), so a safe assumption is none of the substantive requirements will be materially changed for the final version. Also, the FDA has stated it will be using the review process to inform MDMs of cybersecurity omissions in their submissions to the agency until October 2023, when the required security artifacts will be added to the Refuse To Accept (“RTA”) checklist and, therefore, a submission will not even reach the FDA’s review process before being rejected if there are missing security artifacts in the submission.
Bottom line, read and implement the activities in the April 2022 premarket guidance, and you will be on fairly safe ground in achieving what the FDA wants this year. But remember, this will continue to change and grow for years to come, so also remain flexible in how you approach security in your organization. Finally, get your employees trained in operation technology cybersecurity; it’s long overdue.
The next issue will be a more technical column as we review one new aspect of medical device cybersecurity—“in the field” updating and patching of medical devices. If you think this is a simple process, you don’t understand all the aspects of this topic and next issue’s column will be for you.
References
Christopher Gates is the director of Product Security at Velentium. He has more than 50 years of experience developing and securing medical devices and works with numerous industry-leading device manufacturers. He frequently collaborates with regulatory and standard bodies, including the CSIA, Health Sector Coordinating Council, H-ISAC, Bluetooth SIG, and FDA to present, define, and codify tools, techniques, and processes that enable the creation of secure medical devices. Gates promotes the use of a “secure development lifecycle,” the industry-leading approach that ultimately eases the burden on developers and ensures high-quality products that work as intended to save and improve lives.
