The Maturity Paradigm

In healthcare we have an insatiable appetite to adopt new technology

Should we be worried

About state-sponsored attacks against hospitals?

Security and the Board Need to Speak the Same Language

How security leaders speak to thier C-Suite and Board can make all the difference

Who'd want to be a CISO?

Challenging job, but increasingly well paid

Medical Tourism - Growing in Popularity

Safe, fun, and much, MUCH more cost-effecitive

The Changing Face of the Security Leader

The role is changing, but what does the future hold?

Cyber Risk Insurance Won't Save Your Reputation

Be careful what you purchase and for what reason

New FDA Rules Go Into Effect


Yesterday the FDA gave notice that as of Oct 1st it will “refuse to accept” medical devices and related systems unless they meet its new cybersecurity requirements which went into effect March 29th, 2023. These requirements are embodied in new FDA final guidance on its Refuse to Accept (RTA) policy relating to cybersecurity in medical devices, specifically for “Cyber Devices” as defined in the newly-amended FD&C Act (Section 524B).

These powers come out of the Protecting and Transforming Cyber Health Care (PATCH) Act of 2022 and the provisions which were funded under the Consolidated Appropriations Act of 2023 signed into law on Dec. 29. Given the passage of both acts last year, and growing demands for improved medical device cybersecurity going back at least a decade, this should come as no surprise to manufacturers.

Indeed, pre-market FDA security guidance prior to the new law has stipulated increased security requirements, though many manufacturers have not yet implemented this guidance. Under the new powers, improvements in the cybersecurity and ongoing support of medical devices is now mandatory.

This means that if you’re a company building a medical “cyber device”, it is now a requirement that you build your device to be secure by design, develop strategies to monitor and maintain the security of that device post-market and for the life of the device, generate and maintain a software bill of materials, and generate the requisite documentation proving you’ve done so as part of your FDA regulatory submission.


A New Era in Medical Device Security

The days of build, sell, and forget, are now over. While some manufacturers were better than others about cybersecurity and ongoing patch support, others were plainly borderline negligent. The refusal to patch known highly vulnerable medical devices resulted in the FDA issuing its first ever medical device recall in 2017 following the very public disclosure of critical security vulnerabilities from the hacking of a St Jude Medical cardiac defibrillator. St Jude Medical had a long history of refusing to patch its insecure medical devices, and shortly after the disclosure, the company was sold to Abbott Labs reportedly at a big discount.

Submissions to FDA need to include a software bill of materials, which must contain all commercial, open-source, and off-the-shelf software components, while complying with other FDA requirements “to demonstrate reasonable assurance that the device and related systems are cybersecure.” This allows healthcare provider security teams to immediately understand and react to their exposures when CVEs are published for individual software components rather than wait for medical device manufacturers to assess and publish their own vulnerability disclosures.

Device manufacturers will need to submit plans to monitor, identify and address in a "reasonable timeframe" any determined post-market cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosures and plans. “While the language here is vague and not specific, it’s a big improvement over current arbitrary disclosure practices” claimed Timur Ozekcin, CEO of Cylera.

Developers must now design and maintain procedures able to show, with reasonable assurance, “that the device and related systems are cybersecure” and create post-market updates and patches to the device and connected systems that address “on a reasonably justified regular cycle, known vulnerabilities,” according to the guidance.

If discovered out-of-cycle, the manufacturer must also make public “critical vulnerabilities that could cause uncontrolled risks,” as soon as possible. “This appears to be weaker requirements than the originally proposed 30-day patch availability requirement, as is common for other software when critical vulnerabilities are discovered, but it’s a lot better than the current situation,” added Ozekcin.

“These changes mark a much-needed improvement to the security of connected medical devices, but they don’t cover the millions of legacy devices currently in use in our hospitals and clinics. Unless the FDA introduces rules to address these legacy devices then it may take many years before the security of the healthcare industry is significantly impacted,” claimed Richard Staynings, Chief Security Strategist with Cylera. “Medical devices have an expected lifespan of between 8 and 20 years in some cases, so the security of these systems will more than likely be an issue till 2043 and that’s too long,” he added.

While not all connected medical devices will develop security vulnerabilities, many will over the course of their lifetime and amortization schedule. What is needed is a way to better identify medical and other healthcare IoT connected devices, understand their risks and accurately profile devices so that software defined networking (SDN) tools like network access control (NAC) can be used to segment and isolate potentially at-risk systems. AI based tools like Cylera MedCommand now automate this entire process leading to seamless orchestration of security policy across the healthcare network.

For more information on how Cylera solves the problem of cyber-securing legacy medical devices, please contact us to request an overview and demo. 

This story was first posted here