In December 2022, the United States Food and Drug Administration [FDA] signed the Consolidated Appropriations Act 2023 [‘Omnibus’] into law. Section 3305 of the Omnibus – titled ‘Ensuring Cybersecurity of Medical Devices’ – amended the Federal Food, Drug, and Cosmetic Act [FD&C Act] by adding section 524B: ‘Ensuring Cybersecurity of Devices’.
This amendment, which came into effect on March 29th, 2023 – 90 days after the enactment of the Omnibus – established a new refuse-to-accept policy for cyber devices. The new policy requires the sponsor of a premarket submission for a cyber device to submit a plan for monitoring, identifying, and addressing any post-market cybersecurity vulnerabilities and exploits.
The introduction of this amendment is the culmination of the FDA’s efforts to encourage mitigation of cybersecurity threats to the functionality of Internet of Things [IoT]-powered medical devices, and their users. Prior to this, the FDA’s recommendations with regards to the cybersecurity of medical devices were not codified into law, and as such bore little in the way of authority. Now, however, with the refuse-to-accept policy enshrined in law, any devices that fail to meet the requirements will be deemed unacceptable and won’t make it to market as a result.
An element of Section 524B that has alarmed some original equipment manufacturers [OEMs] is the requirement to monitor, identify and address vulnerabilities in open-source software [OSS] used within medical devices. This requirement, it was argued, would be tantamount to ‘outlawing’ open-source development, given the perception that managing vulnerabilities in the software is practically impossible. While it’s true that keeping on top of vulnerabilities in OSS may be relatively onerous for OEMs, it’s an exaggeration to suggest that the FDA has set an unachievable task.
After all, IoT medical devices present exciting possibilities for the future of healthcare and could hold the key to revealing life-saving breakthroughs. Because open-source development forms such a vital part of device functionality – enabling OEMs to work around software issues with ease – the FDA’s aim isn’t to stifle innovation.
Quite the opposite actually; this ruling is designed to strike a balance between agile development of innovative medical technology and the need for robust device cybersecurity to maintain patient and medical practitioners’ trust in new technologies.
The cost of cyber attacks on medical devices
Recent headlines help illustrate why it is so crucial for devices to be protected from cyberattacks. In June 2023, it was reported that freedom of information [FOI] requests to 150 NHS trusts, in the UK, had revealed that millions of medical devices in UK hospitals, many of which rely on open-source software, were completely unprotected against hackers. In many cases, these devices were either found to be reliant on out-of-date software, or completely unmonitored.
By hacking into medical devices, bad actors can essentially enter a hospital’s systems through the backdoor, leaving them free to wreak havoc in a whole host of ways. For example, hackers can try to steal sensitive data from organizations, including personal information about patients and their health, which they can then hold to ransom for vast sums of money. Perhaps and even more worrying scenario is the potential to influence the data the device is reporting leading to the patient receiving the wrong treatment regimen. With each of these security breaches, patient trust is further eroded, stifling uptake and engagement with potentially groundbreaking medical innovations.
Critical incidents of this kind have occurred in North America and other parts of the world, where security experts have been pulled in to deal with the aftermath. Indeed, in 2021, 108 ransomware attacks were reported across more than 2,000 U.S. medical organizations, impacting 19.76 million patient records, and costing an estimated $7.8 billion in downtime. This downtime is not just expensive; it can also threaten patients’ lives, given the disruption that outages can cause to vital medical equipment, such as life-support machines. As such, the cost of cyberattacks on the healthcare sector can’t only be measured by financial loss, but also by the very real loss of life that attacks can leave in their wake.
So, while open-source development undoubtedly enables OEMs to innovate on an unprecedented scale when it comes to medical technologies, this ability must be tempered with an awareness around its potential vulnerabilities from a cybersecurity perspective. The goal then of the FDA ruling is not to undermine open-source development, but rather to strengthen the offerings of OEMs by ensuring they have robust security measures in place, bolstering the trust in such technologies amongst key stakeholders.
Trust is key
It’s clear that medical devices which are unprotected from cyberattacks have the potential to inflict significant reputational damage on the OEMs who make them. This alone should give manufacturers cause enough to take their cybersecurity responsibilities seriously. Put simply, the effectiveness of their devices is heavily dependent on the establishment of trust. Not only do medical organizations need to trust devices if they are to use them, but so too must the patients who the technology is used to monitor and treat. Personal data is imperative for improving health outcomes and patient experience, but if patients can’t trust that their data is secure, they are far less likely to want to share it.
By ensuring that robust security is in place – and that data is protected – OEMs can start to build trust with consumers and improve data sharing as a result. After all, patients are much more likely to provide their data if they believe it will be properly protected, and used to enhance the quality of the healthcare they receive.
There is no better way for OEMs to demonstrate the effectiveness of their security than by adhering to legislation like that put forward by the FDA. Not only is compliance essential for OEMs getting their products to market, but it provides consumers with an assurance that manufacturers will proactively monitor, identify, and address any vulnerabilities that occur within the device. This, in turn, helps build trust in the use of IoT in the medical industry, and enables OEMs to continue driving innovation through OSS, without feeling that their efforts in doing so are being stifled.
How Trustonic can help OEMs protect medical devices
We appreciate that ensuring compliance can be a complex process for OEMs, especially if they are having to meet cybersecurity regulations in various different markets around the world. However, Trustonic has the expertise to help guide manufacturers in achieving compliance. After all, the ruling by the FDA has been influenced by similar cybersecurity regulations introduced in the automotive industry – such as UNECE WP.29 – which we have helped automakers to adhere to.
Our Trusted Execution Environment [TEE] has already helped OEMs to ensure that their devices are ‘secure by design’. This is because the TEE allows for critical code and data to be isolated from the less secure parts of the device. The TEE’s ability to offer isolated safe execution of authorized security software – known as Trusted Applications [TA] – enables it to provide end-to-end security by enforcing protection, confidentiality, integrity, and data access rights.
The solution provides a level of protection against software attacks, generated in the Rich Operating System [OS] environment, and assists in the control of access rights and house sensitive applications, which need to be isolated from the Rich OS. Indeed, our TEE is already used in hundreds of millions of devices running the Linux OS, providing these OEMs with the ability to leverage OSS for innovation, while backing it up with world-class secure world technology.
As such, by integrating our TEE into their products, OEMs can not only make sure that they are compliant with cybersecurity regulations, but also that they and consumers can have high levels of trust that devices are secure.
