Paz Terry: Hi there. Thank you. Today, we're discussing the new FDA cybersecurity requirements for connected medical devices and how this impacts regulatory approval. These requirements went into effect this year, so they're already affecting everyone applying for medical device approval. We'll get into definitions and details shortly.
But first, I'd like to introduce our panelists. First, Dmitry, please introduce yourself.
Dmitry Vyrostkov: Hi, everyone. My name is Dmitry Vyrostkov. I work at DataArt, a technology consulting and custom software development company. My position is Software Security Architect, and I also lead our cybersecurity services. My experience includes security transformation projects where we establish and implement secure software development practices and help companies prepare for security certifications.
Paz Terry: Thank you. Sara?
Sara Jaworska (Juszczyk): Hello, everyone. I am Sara Jaworska (Juszczyk), the Quality and Regulatory Affairs Manager at DataArt. My role is to support legal manufacturers and the DataArt team in all regulatory aspects of projects.
Paz Terry: Thank you, Sara. I'm Paz Terry, co-founder of Cyber Logic Security. We're a cybersecurity compliance and services-focused company. We often work with companies like DataArt on large projects. In this case, we worked with DataArt and Vigilant BioSciences, who are our clients. Dex, please introduce yourself.
Dex Manley: All right. I'm Dex Manley, Senior Director at Vigilant BioSciences. I manage our IT operations and software development. Over the last six months, we worked with Cyber Logic Security and DataArt to deliver our security operations program. It was a very successful program, and I'm excited to be here and contribute to this conversation.
Paz Terry: Thanks, Dex. Let's start with some definitions. The "cyber device" is what we're really talking about—the focus of the FDA. Simply put, it's a device you turn on and connect to a network, whether that's the internet or a local network. Sara, what is the scope of this FDA regulation, and what's the impact?
Sara Jaworska (Juszczyk): The broad impact will help medical device manufacturers. The FDA publishes new guidelines, playbooks, and regulatory documents. Cybersecurity in Medical Devices is the primary guideline currently addressing cybersecurity. The regulation is already in effect.
A cyber device can be any medical device, regardless of form, that is connected to the Internet and may be exposed to cybersecurity risks. The regulation applies to any company anywhere in the world that wants to sell its products on the U.S. market.
It applies to all new products that meet the connectivity condition, regardless of the submission type, and to products exempt from submission. Importantly, it also applies to existing products that undergo significant changes.
Paz Terry: So, if you already have a product on the market and you add new functionality, do you have to get it recertified?
Sara Jaworska (Juszczyk): If you add new functionality, yes. Or if anything else changes in the device's risk profile, the FDA will require additional documentation as part of the submission.
I’d also add that cybersecurity isn’t just about adding specific functions to the product. It’s also about implementing cybersecurity into company operations and post-market continuous monitoring. Integration with existing quality management systems, like ISO 13485 or others, should be considered.
Paz Terry: Understood. So, working with current QA and quality management system processes is the way to do this, right? There’s a high level of compliance and governance required after the fact.
Sara Jaworska (Juszczyk): Exactly. The generated documentation is required at every step.
Paz Terry: Why this new change? Dmitry, can you explain why the FDA enacted these regulations?
Dmitry Vyrostkov: Sure. The FDA implemented these changes to address the critical need for better security in medical devices. As devices become more connected—to the internet, hospital networks, or each other—their vulnerability to cyberattacks increases. While this connectivity improves patient care, it opens up new risks.
For example, in 2023, the FDA issued alerts about Medtronic insulin pumps, which were vulnerable to traffic interception and modification of insulin delivery. Medtronic issued urgent corrections. Another case involved Becton Dickinson infusion pumps, which could be attacked remotely to modify drug formulas, dosages, and infusion rates. Other affected devices include pacemakers, patient monitors, and diagnostic equipment.
This move is about ensuring devices are effective and secure, protecting patients from cyber threats.
Paz Terry: So this is where technology meets humanity—these are devices people depend on to live or improve their quality of life, and they can be attacked. How does the FDA suggest companies address these new requirements?
Dmitry Vyrostkov: The FDA wants companies to include cybersecurity considerations in their device design and development. This includes identifying risks, setting design requirements, and proving that security controls are effective. The FDA recommends applying a secure product development framework covering the entire product lifecycle: design, development, testing, release, and support.
Companies should choose a framework that best fits, such as NIST SP 800-218 (Secure Software Development Framework), the NIST Cybersecurity Framework, the ISO 27000 family, or other medical device-specific frameworks.
Paz Terry: It sounds like security needs to be built in from the beginning. Can you compare NIST 800-218 and ISO 27001 for us?
Dmitry Vyrostkov: Yes. ISO 27001 provides comprehensive guidelines for organization-wide information security management—it's broad and not limited to software development. NIST SP 800-218 focuses on secure software development practices, helping organizations minimize vulnerabilities and address root causes. It may be better suited for companies developing products.
Paz Terry: Understood. What activities do companies need to undertake to gain FDA acceptance?
Dmitry Vyrostkov: The updated guidance is a detailed, 50-page document outlining key principles and specific cybersecurity information required in submissions. Companies must develop a security risk management plan, conduct periodic threat modeling and risk assessments, and provide evidence of these processes in their premarket submission.
They must also provide an up-to-date software bill of materials (SBOM), information on third-party software support, and end-of-life dates. Companies must take a holistic approach to security controls, with documentation covering security design, architecture reviews, and acceptance criteria for each control.
Paz Terry: That’s a long list. SBOMs are important because of hidden third-party components. If we’re not updating those, we create more vulnerabilities.
Let’s hear about your experience, Dex.
Dex Manley: Our product is a lateral flow device reader, similar to a pregnancy or COVID test, but for biomarkers related to oral cancer. It's network-connected to the cloud for certain capabilities. As a small company, we needed help with penetration testing and implementing a security operations program. Initially, we focused on ISO 27001, but found it wasn’t comprehensive enough for FDA requirements.
We learned that SBOMs are much more detailed than ISO’s “software of unknown provenance.” Our device runs on Raspberry Pi OS, and understanding all the components was a long process. The SBOM gives a deeper understanding of what’s in your system and what needs to be fixed.
You can’t just do penetration testing and fix gaps—you need an ongoing security operations program with quarterly, semiannual, and annual activities. It’s a continuous process as long as there is a connected device on the market.
Paz Terry: Thank you. Let’s talk about teams. We had meetings with people in six or seven countries and time zones. DataArt is filled with professionals, and we hit our timelines by being nice and on time. We also had a mid-project shift. Dex, can you talk about that?
Dex Manley: Initially, our focus was FDA submission, but we also wanted to distribute our products worldwide, especially in Europe. Europe has a new regulation called IVDR. With only two months left in the project, we asked if we could also address IVDR. Sara was instrumental in helping us navigate the documentation. The FDA and IVDR regulations overlap by about 80%, but we had to cover the differences. With your help, we managed to submit to both.
Paz Terry: Congratulations. Any final notes or tips to share?
Dex Manley: Start as early as possible. For IVDR, the wait time is about a year. If you want to ship to Europe, start the process right away. With a distributed team, you must be engaged as a stakeholder and maintain high communication. We had weekly meetings and a large team—our internal team, outsourced developers, and your teams at Cyber Logic and DataArt. Collaboration was key. Even with external help, you must review and tailor all documentation to your organization.
We implemented tools like Bearer for automated vulnerability scanning, which found new issues even after initial penetration testing. Security is an ongoing process—start early, maintain communication, and work closely with your team.
Paz Terry: Thank you, Dex. Sara, any tips?
Sara Jaworska (Juszczyk): Engage regulatory support as early as possible. That lets you deal with challenges and risks early and choose the best strategy. Plan for market requirements in advance to avoid delays. This advice is common, but it really adds value.
Paz Terry: Thank you, Sara. Dmitry, any tips?
Dmitry Vyrostkov: Security shouldn’t be an add-on—it should be embedded from the beginning. Educate your team on security concepts, including developers, support, and operations. Embed security design early in the product development process.
Paz Terry: Agreed. Working with professionals helps a lot. Let’s move to questions.
Dmitry, what if your product uses legacy components that are no longer supported?
Dmitry Vyrostkov: Unfortunately, that’s not good news. You need to use supported and maintained components. If you must use legacy components, find mitigation strategies and analyze the risks. Sometimes you may need to migrate to supported alternatives.
Dex Manley: For example, our device runs on Raspberry Pi OS. When version 11 reached end-of-life, we had to plan how to update devices in the field. You need to plan for future obsolescence and how to update devices—whether over the cloud, by USB, or with a technician.
Paz Terry: Thanks. Sara, is it possible to integrate ISO 13485 with NIST?
Sara Jaworska (Juszczyk): Yes, it is possible. We’ve done it successfully, though it may not be as elegant as integrating other standards. Control mappings help align requirements between standards.
Paz Terry: Dmitry, what security testing is required for new submissions?
Dmitry Vyrostkov: The FDA requires extensive security testing, including writing security requirements and acceptance criteria and testing them. This includes functional testing for security features, fuzz testing, static and dynamic code analysis, and software composition analysis. Not all are mandatory, but they are recommended and expected in submissions.
Dex Manley: We had to formalize code reviews and regiment our software development processes, focusing on cybersecurity-specific planning.
Paz Terry: Many of these tests involve a mix of automated and manual processes. We’re not fully automated yet. Do you have any last thoughts?
Dex Manley: Our device is low risk, but even if you think your device is innocuous, it can be used as a zombie device to attack other devices on the network. Even low-risk devices must address cybersecurity.
Paz Terry: Exactly. The Internet of Things means even small devices can be attack vectors. If there are no further questions, I think we’re done for today. Thank you to everyone for joining and to our panelists, Dex, Dmitry, and Sara. It was great to see you all.
