Navigating FDA's Cybersecurity in Medical Devices Guidance

What do the agency's evolving expectations mean for manufacturers?

The U.S. Food and Drug Administration is sharpening its focus on cybersecurity in medical devices. In 2025 and again in 2026, the agency updated its guidance, taking a major step forward in its position on device development and the role of cybersecurity across safety-critical systems in healthcare. 

FDA also recently released its new Compliance Program Manual (#7382.850), which went into effect February 2. The manual includes a section on cybersecurity to support investigators in complying with the quality management system regulation (QMSR) before and during an inspection, signaling a new structured approach to cybersecurity enforcement. 

As manufacturers adapt to the updated cybersecurity guidance and work to confirm new and existing devices are submission- and inspection-ready, understanding the intent and scope of the agency's current thinking and recommendations is paramount. Attacks that encrypt hospital systems, disrupt remote monitoring, or interfere with device updates and other functions can potentially delay diagnoses and treatment, interrupt life-sustaining therapy, and expose patients to potential harm. 

FDA expects cybersecurity to be embedded within manufacturers' quality systems and reflected in premarket submissions when applicable. Devices with data gaps or missing quality system documentation may face requests for additional information, resulting in delays to market. By updating systems and processes for compliance now, manufacturers can not only safeguard patients in connected healthcare environments but prepare for a world of increasingly networked devices, continuous software updates, and advanced capabilities. 

Even if a device was never meant to connect to the internet but includes a wireless communication protocol, manufacturers must still account for potential threats.

Which medical devices are covered by the new cybersecurity guidance?

FDA's guidance applies to all medical devices with cybersecurity considerations. As defined in the agency's cybersecurity in medical devices FAQs, a "cyber device":

• Includes software validated, installed, or authorized by the sponsor as a device or in a device
• Has the ability to connect to the internet
• Contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats

That means that even if a device was never meant to connect to the internet but includes a wireless communication protocol, manufacturers must still account for potential threats. FDA considers any device that has these communication features to be a cyber device:

• Network, server, or cloud service provider connections
• Radio-frequency communications (Wi-Fi, cellular, Bluetooth, Bluetooth Low Energy)
• Magnetic inductive communications
• Hardware connectors capable of connecting to the internet (USB, ethernet, serial port)

While network connectivity is helpful in classifying a medical device as a cyber device, the guidance specifically notes that its scope is not limited to network-enabled devices or other connected capabilities. A device with internal components that may be susceptible to supply chain risks, errors, or attacks targeting physical components once a device is on the market can also be classified as a cyber device. 

What are FDA's security recommendations?

Choose a security framework

FDA outlines several key concepts in its guidance, including using a secure product development framework (SPDF) to identify and address vulnerabilities. An SPDF assesses cybersecurity at every step of product development, from design to production, support, and decommissioning, by integrating cybersecurity with processes like those described in ISO 13485. Alternatively, JSP2 and IEC 81001-5-1 are FDA-recognized consensus standards that include requirements for development frameworks.

An SPDF is similar to what other industries call a security development lifecycle. For example, A Versatile Cybersecurity Development Lifecycle is one open-source example that Exponent applies to automated vehicles and can be extended to other industries. These lifecycles describe cybersecurity practices, such as definitions for security requirements, threat modeling, secure code reviews, penetration testing, and other techniques to help harden a product across its entire lifecycle. 

SPDFs fit within a wider engineering ecosystem of management systems that include software and systems development lifecycles, QMSRs, and others. To get the most from any framework, stakeholders can review existing lifecycles and management systems from the very beginning of the product development lifecycle and evaluate how cybersecurity measures fit into the broader ecosystem. A siloed SPDF rarely delivers consistent, comprehensive impact. 

Conduct rigorous threat modeling and risk analysis

FDA recommends threat modeling and regular vulnerability and risk analysis throughout development and deployment. Threat modeling can be used to identify how a threat actor may compromise or degrade a device, supporting the documentation that FDA recommends premarket submissions include. FDA also states that safety and security for devices should be assessed within the context of the larger systems in which they operate, whether that is hospitals, homes, or networks. A strong threat model incorporates details from the intended operating environment and does not simply focus on how the device functions in isolation. For example, medical device cybersecurity modeling often includes assessing how other devices commonly found in hospitals, clinics, and homes could be used to access and compromise the medical device — like Wi-Fi routers, health monitors, Bluetooth devices, computer systems, phones, etc. 

Use labeling to support product safety 

FDA's updated guidance emphasizes that informing users of security information through labeling may be an important part of design and development activities to help mitigate cybersecurity risks and promote the continued safety and effectiveness of the device over the long term. The guidance further warns that inadequate cybersecurity information in device labeling may cause it to be misbranded under section 502(f) of the Federal Food, Drug, and Cosmetic (FD&C) Act. A "misbranded device" is one that the FDA deems to have misleading labeling or inadequate directions or warnings. Importantly, misbranded devices can be pulled from the market and recalled from public and medical use. FDA may also choose to pursue criminal charges against manufacturers of mislabeled devices.

What security tests does FDA recommend performing?

Manufacturers can conduct a cybersecurity gap analysis on their existing devices based on FDA recommendations to avoid market entry delays and help avoid potential recalls and prepare for them. FDA recommends various security tests and analyses, including: 

• Attack Surface Analysis — Identifying points where threat actors may initiate a device attack and safeguarding them. 
• Fuzz Testing — Applying tool-driven, intelligently randomized inputs to software interfaces to uncover crashes, memory corruption, and other unintended behavior. 
• Closed Box Vulnerability Scanning — External scanning of the product to find known vulnerabilities. 
• Software Composition Analysis — Analysis of software binaries to identify third-party or open-source components and associated vulnerabilities.
• Static & Dynamic Code Analysis — Examining code at rest (static) or as it executes (dynamic) to identify vulnerabilities. FDA also stresses using these techniques to identify hardcoded, default, or easily guessable credentials.
• Penetration Testing — Simulating attacks to discover vulnerabilities under real-world exploitation conditions.

Many of these tests can be automated as part of software development pipelines. It is ideal to automate as much as possible, allowing these tools to push systems to failure and identify vulnerabilities. Incorporating these tests early can help prevent cybersecurity defects from slipping into later phases of the total product lifecycle where they can become more expensive to resolve. If a cybersecurity issue is identified after a device is marketed, manufacturers may utilize a previously authorized predetermined change control plan (PCCP) (e.g., sponsors may follow FDA's guidance on PCCPs for artificial intelligence-enabled medical devices to push updates to their cyber device if a PCCP has been authorized).