Q&A with the FDA on Cybersecurity Policy
Watch the replay.
Tell us a little about yourself and the recording will unlock right here.
Q&A with the FDA on Cybersecurity Policy
Additional Answers
Further to the questions answered live, the FDA provided these responses to questions asked by attendees of the Grand Rounds session.
How should manufacturers distinguish between a cybersecurity/security assessment and a penetration test, and what are FDA's expectations for each?
FDA distinguishes a cybersecurity assessment as a continuous analytical process to identify and score system-wide risks, whereas a penetration test is a practical, hands-on activity designed to actively discover and exploit vulnerabilities. Essentially, the security assessment provides the analytical framework to identify what the risks are, while the penetration test provides the empirical evidence to prove that your security controls can withstand a real-world attack.
FDA expects both activities to be formally documented in premarket submissions. As described in the premarket cybersecurity guidance, this includes numerous security risk documentation (e.g., Risk Management Report, Threat Model, Cybersecurity Risk Assessment, SBOM and related info, etc.) as described in Section V.A Security Risk Management and a dedicated Penetration Testing Report documenting the scope, methodology, findings, and the independence and expertise of the testers as described in Section V.C Cybersecurity Testing.
To what extent should device-adjacent infrastructure, systems, and services outside the formal V&V boundary be included within the scope of penetration testing?
The FDA expects the scope of cybersecurity assessments and penetration testing to extend beyond the medical device itself to include the entire medical device system encompassing all adjacent infrastructure, connected systems, and services. These external components represent a significant part of the device's attack surface and can directly impact its safety and effectiveness.
Consequently, testing must not be limited to the formal V&V boundary of the device alone. Instead, the testing scope should be informed by a comprehensive threat model of the entire system. Any connected component that could, if compromised, impact the safety or effectiveness of the device (such as cloud backends, update servers, or connected infrastructure) should be considered in-scope for security testing.
What are FDA's expectations for periodic penetration testing outside of post-market patching or major release cycles?
FDA expects medical device manufacturers to conduct cybersecurity testing, which can include penetration testing, on a recurring basis after a device has been released to the market. This expectation is not strictly tied to patching or major release cycles but is instead part of a proactive, ongoing process for managing cybersecurity throughout the product's lifecycle.
The premarket cybersecurity guidance explicitly states the following: "After release, cybersecurity testing should be performed at regular intervals commensurate with the risk (e.g., annually) to ensure that potential vulnerabilities are identified and able to be addressed prior to their ability to be exploited."
Furthermore, the premarket cybersecurity guidance recommends that a manufacturer's "Cybersecurity Management Plan" should include provisions for "Periodic security testing" as part of its strategy to monitor and identify vulnerabilities post-release.
Therefore, a manufacturer should define and justify a schedule for periodic penetration testing as an integral part of their postmarket cybersecurity management processes.
What is FDA's expectation regarding SBOM scope? Should SBOMs include direct application dependencies, transitive dependencies, environment-of-use software and infrastructure components, or some combination of these?
The FDA's expectation is that the SBOM scope should encompass all software components contained within the medical device itself, including both direct and transitive dependencies.
As stated in the FDA premarket cybersecurity guidance, a robust SBOM should include “both the device manufacturer-developed components and third-party components, including purchased/licensed software and open-source software, and the upstream software dependencies that are required/depended upon by proprietary, purchased/licensed, and open-source software.”
This means the SBOM must be comprehensive, detailing every dependency down to the final component that has no further dependencies (a "leaf node"). The rationale is that any component, no matter how deeply nested, can introduce vulnerabilities that may affect the device's safety and security.
While the SBOM focuses on the software in the device, the FDA expects manufacturers to address risks from the environment of use and infrastructure through other documentation, such as threat modeling and security architecture views. In summary, the SBOM itself is scoped to the components being delivered to the end user as part of the medical device.
What FDA cybersecurity guidance documents are currently applicable, and where can the latest versions be accessed?
The applicable FDA guidance documents for premarket and postmarket cybersecurity are provided below:
- Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions
- Postmarket Management of Cybersecurity in Medical Devices
You can also access the guidance documents along with other resources on the FDA Cybersecurity Webpage listed below:
https://www.fda.gov/medical-devices/digital-health-center-excellence/cybersecurity
Medical device cybersecurity continues to evolve as new technologies, emerging threats, and regulatory expectations reshape the industry.
In this Archimedes Grand Rounds webinar, experts from the U.S. Food and Drug Administration (FDA) and Northeastern University discuss cybersecurity policy and its practical implications across the medical device lifecycle.
The conversation covers organizational responsibilities, AI and machine learning, threat modeling, cybersecurity testing, postmarket patching, and best practices for regulatory submissions.
Who you will hear from.
Kevin Fu is a professor at Northeastern University with appointments in Electrical and Computer Engineering, the Khoury College of Computer Sciences, and Bioengineering. He previously served as Acting Director of Medical Device Cybersecurity at the FDA’s Center for Devices and Radiological Health and as Program Director for Cybersecurity in the FDA’s Digital Health Center of Excellence.
He earned his PhD from MIT and is a Sloan Research Fellow and Fellow of IEEE, ACM, and AAAS. MIT Technology Review named him a TR35 Innovator of the Year.
A seasoned cybersecurity executive with extensive experience leading global security programs in healthcare and enterprise environments. Formerly Global CISO at Stryker, where he helped the organization navigate a disruptive cyberattack and before that he held a CISO position at Siemens Healthineers. With over two decades of experience spanning defense, telecommunications, Retail, and healthcare, David specializes in building and managing security operations centers (SOCs), threat intelligence programs, and incident response teams. He is the author of Designing and Building Security Operations Centers and a recognized thought leader in operationalizing cybersecurity at scale. David's work focuses on advancing patient safety by aligning cutting-edge cyber defense with the unique demands of healthcare environments, ensuring resilience against evolving global threats.
Nastassia Tamari leads the FDA division responsible for developing medical device cybersecurity policy, advancing national preparedness, and responding to cybersecurity vulnerabilities and incidents involving medical devices.
Before joining the FDA, she spent more than a decade at a medical device manufacturer, where she built a product security program and led a global team focused on strategic regulatory alignment.
Justin Post advises FDA senior leadership and review teams on medical device cybersecurity policy, guidance, and regulatory implementation. His work supports consistent, science-based oversight throughout the total product lifecycle.
He also leads cross-functional coordination and capacity building, works with other government agencies, and develops training and resources that improve the quality, consistency, and efficiency of regulatory reviews.