Struggling with cybersecurity planning, execution, and postmarket surveillance? Asking yourself, “what does FDA expect?  If it is any consolation, most medical device manufacturers are right there with you! But we have noticed that many struggles likely could have been avoided.

The good news is that cybersecurity is on your radar – likely that is why you are reading this article! That’s a good thing.

However, not so good are some common pitfalls to avoid, including:

• Inadequate risk management.
• Starting cybersecurity-related work too late.
• Focusing cybersecurity attention on the device only.
• Not considering physical security and effects on cybersecurity.
• Assuming penetration testing is only for certain situations.
• Inadequate post-market preparation and attention.
• Not updating the Quality Management System for cybersecurity and regulatory expectations.

Let’s take a brief look at each of those examples.

Inadequate risk management

You may be thinking: wait … why is this here when we are discussing cybersecurity? That’s the same reaction we usually get when we discuss this with clients.

A solid risk management process and considerations are foundational for solid cybersecurity. Identifying and assessing safety and effectiveness risks is a key to understanding how cybersecurity issues might affect safety and effectiveness.

The interrelationship between risk management and cybersecurity is clear in consensus standard ANSI/AAMI SW96:2023 Standard for medical device security—Security risk management for device manufacturers (https://array.aami.org/doi/book/10.2345/9781570208621) figure 2. The security risk management process (including cybersecurity) and the safety risk management process are parallel AND interacting.

Tailor both processes to the device and risk environment and then execute.

Starting cybersecurity-related work too late

An earlier post, Why Software Keeps Failing, also applies to cybersecurity. In that post, we noted that

For risk management to be effective, it needs to start at the beginning of the project and continue throughout. Risk management should potentially influence architecture and design instead of maybe merely adding one or more risk controls. Risk management should certainly not be “reverse engineered” at project end to satisfy submission needs, as we have seen more consistently than would be hoped.

You can substitute “cybersecurity” or even “security” for “risk management,” and the above still applies. An inherently high risk security architecture and design cannot normally be fixed by adding a few controls later.

Focusing cybersecurity attention on the device only

Cybersecurity should focus on the overall environment, just as safety and security risk should consider beyond the device only. Review the intended use environment for cybersecurity impacts either to or from other systems. The other systems may be intentionally connected where the device is part of a larger system, or not connected and still need assessment.

Regulatory authorities have been very clear about manufacturers being very clear about the interoperability environment of a device and assessing other systems in the intended use environment.

Not considering physical security and effects on cybersecurity

We rarely see physical security considered. For instance, what are the cybersecurity effects if:

• The device (if hardware and software) or computing platform are stolen?
• There is physical damage?
• The device (if hardware and software) or computing platform can easily be opened and software and/or data accessed?

In short, what can be intentionally or unintentionally physically done to the device or platform that could affect cybersecurity depending on the nature of the device, software, and data?

Assuming penetration testing is only for certain situations

A common assumption is that penetration testing is only for Internet user interfaces or, in some cases, user interface(s) on a device. Not so.

Consider penetration testing for any functioning interface, whether used by the device or not. This includes electronic interfaces that are not user interfaces, like a USB or power port.

The U.S. Food and Drug Administration (FDA) has made it clear that penetration testing is expected for all penetration possibilities. It is incumbent on the manufacture to either conduct penetration testing or clearly demonstrate why it is not applicable (e.g., a USB port has been physically disconnected in the device from any electrical connections, including grounds).

Furthermore, the FDA expects to see the penetration testing done by people who are experts at such testing and with sufficient experience. They also have preferred thus far to see someone independent from the core device team do the testing. Therefore, someone on your team who may be able to do penetration testing may not be considered adequate/appropriate. Also, the FDA may not consider either internal people or outside consultants who are independent of the core team sufficiently “expert” if penetration testing expertise is not evident.

Inadequate post-market preparation and attention

Manufacturers are expected to monitor device operations post-release and take appropriate actions (e.g., US regulations 21 CFR 803, 21 CFR 820.100). Cybersecurity is no different (e.g., FDA guidance documents Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (especially section VI.B),  Postmarket Management of Cybersecurity in Medical Devices).

What IS different is the possible frequency of necessary device changes. Cybersecurity issues may occur more frequently than other types of field issues or planned release cycles. Manufacturers should consider how to handle cybersecurity-focused device changes, especially software updates, that may be needed at any time.

Not updating submissions and the Quality Management System for cybersecurity and regulatory expectations

Cybersecurity standards and guidance documents identify deliverables for pre-market submissions and for pre-market and post-market activities based on device and intended use environment characteristics.

With pre-market submissions, we have seen that many of the stipulated deliverables are either not included or there is no explanation why the deliverables are not applicable and therefore omitted. Don’t start a submission already in the “penalty box” … pay attention to submission expectations and address them proactively.

Beyond submissions, manufacturers often don’t update the Quality Management System for cybersecurity. This means even if teams accomplish cybersecurity work for a device, by definition they aren’t following the currently approved quality process. This is a potential audit issue as well as a potential problem with teams devising and following their own approaches to cybersecurity.

Need assistance?

SoftwareCPR can help you with cybersecurity issues and risks. For 25 years, we have helped clients with medical device software development and operation, along with navigating regulations and standards in general.

We can help you with:

• Popular training courses, including for cybersecurity, are listed at https://www.softwarecpr.com/training/, and customized training is available.
• If you need tailored consulting assistance for your specific situation, contact us at https://www.softwarecpr.com/leave-a-message/
• Updates on regulatory, software, and other pertinent matters via our mailing list; join at https://www.softwarecpr.com/join-mailing-list/