Implantable medical device cybersecurity: what FDA asks and what changes

It's unlikely patients with pacemakers or other implanted devices give much thought to cybersecurity.

That focus is reserved for manufacturers of implanted medical devices who constantly think about it. In reality, for manufacturers, cybersecurity is a concern that starts during device development and continues long after implantation.

Implantable medical device cybersecurity can be a matter of life or death for anyone with a pacemaker, implantable cardioverter-defibrillators (ICDs), and neurostimulators. You can just imagine how cyber threats might affect the safety, performance, or availability of implantable medical devices. And cyber risks also extend to external programmers, wireless connections, and remote monitoring systems that support these devices.

And what if there is a known cyber threat? An implant can't simply be unplugged or replaced after a vulnerability is discovered.

So, it's easy to see why FDA reviewers are particularly attentive to security measures required by manufacturers of implantable medical devices.

In this article we will go over what manufacturers can do to identify and manage risks associated with implantable medical devices. You will also learn about what makes implantable devices a totally different kind of animal, the cybersecurity threats manufacturers need to consider, and the testing and documentation FDA expects to see.

What makes implantable medical device cybersecurity different?

Most connected medical devices can be taken offline for maintenance or replaced when something goes wrong. That's not so easy when the device is inside someone's body.

Implantable devices also have to balance cybersecurity protections with clinical performance, limited battery power, and the need to operate reliably for years. Manufacturers must account for these constraints when designing security controls and planning for future vulnerabilities.

The device operates inside the patient

Consider a pacemaker. Once implanted, it may remain in place for years, continuously monitoring the patient's heart and delivering therapy when needed.

Manufacturers can't simply retrieve the device whenever a software vulnerability is discovered. Even routine maintenance can require special equipment or a clinical appointment.

There's also the issue of limited resources. Many implants have strict limits on battery capacity, memory, and processing power. Security controls must work within those limits without interfering with the device's intended clinical functions.

This makes cybersecurity an important consideration early in development, when manufacturers still have the flexibility to design protections into the device.

Wireless communication creates additional risks

Wireless technology allows clinicians to communicate with implanted devices without surgery. Depending on the device, they may retrieve diagnostic information, adjust settings, or monitor a patient's condition remotely.

But every communication pathway introduces potential security concerns.

For manufacturers, wireless implant security means evaluating who can communicate with the device, how those connections are authenticated, and whether transmitted information is adequately protected.

The assessment should also consider what happens if someone attempts an unauthorized connection or interferes with legitimate communications.

And the implant isn't the only concern. External programmers, home monitors, and other connected equipment may introduce vulnerabilities that affect the larger medical device system.

Security updates require special planning

Updating software on a laptop is usually straightforward. Updating the firmware in an implanted medical device can be considerably more complicated.

Manufacturers must consider what happens if an update fails, a wireless connection drops, or the device loses power during the process.

Could the device continue providing essential therapy? Is there a way to recover from an unsuccessful update? Does the update process introduce new vulnerabilities?

These questions need answers before the device reaches patients.

FDA's premarket cybersecurity guidance recommends designing medical devices for secure and timely updates throughout their lifecycle.

For implantable devices, that means developing an update process that protects against unauthorized changes while accounting for the device's clinical functions and operational limitations.

Common cybersecurity threats to implantable devices

Implantable medical devices face many of the same cybersecurity threats as other connected technologies. The difference is what could happen if an attack succeeds.

A compromised device might expose sensitive patient information, interrupt remote monitoring, or affect how therapy is delivered. The consequences depend on the device, the vulnerability, and the protections already in place.

Manufacturers need to evaluate these possibilities without assuming that every vulnerability creates an immediate danger to patients.

Unauthorized access to device communications

Many implantable devices communicate wirelessly with external equipment. That creates a potential entry point for someone attempting to access the device without permission.

Weak authentication, insecure communication protocols, or poorly protected commands could allow an attacker to intercept information or attempt unauthorized changes to device settings.

For example, pacemaker cybersecurity involves protecting communications between the implant and its programmer. A vulnerability in that connection could create an opportunity for unauthorized access or interference with device settings.

Manufacturers should examine these communication pathways during threat modeling and test whether security controls prevent unauthorized access.

Compromised programmers and remote monitors

An implant may have strong built-in protections and still face cybersecurity risks through the equipment that supports it.

Clinical programmers, home monitoring units, and connected applications may contain software vulnerabilities or use communication methods that attackers could exploit.

That's why programmer and remote monitor security deserves attention during the manufacturer's cybersecurity risk assessment.

Consider a compromised clinical programmer. Depending on its capabilities and the implant's protections, an attacker might attempt to send unauthorized commands or access sensitive device information.

Manufacturers need to evaluate the security of these supporting systems, not just the implant itself.

Software vulnerabilities and outdated components

Implantable medical devices may remain in use for years. During that time, software components can develop known vulnerabilities, lose vendor support, or become difficult to update.

The problem isn't limited to software running inside the implant. External programmers, monitoring equipment, and connected infrastructure may also depend on third-party components.

A vulnerability in one of those components could create a pathway into the larger system.

Manufacturers should maintain an accurate inventory of relevant software components, monitor newly disclosed vulnerabilities, and determine whether identified weaknesses could affect device safety or effectiveness.

Disrupted monitoring or therapy

Not every cybersecurity incident involves someone gaining control of a device. Sometimes the concern is whether the device or its supporting systems remain available when patients and clinicians need them.

An attack that disrupts wireless communications could prevent a remote monitor from transmitting information. A compromised programmer might become unavailable when a clinician needs to check or adjust device settings.

In more serious scenarios, a vulnerability could affect the delivery of therapy itself.

The key is understanding the possible clinical consequences. Manufacturers should evaluate how a cybersecurity failure could affect essential device functions, whether existing safeguards would limit the harm, and what recovery options would be available.

What FDA expects for implantable device cybersecurity

FDA doesn't have a separate set of cybersecurity rules just for implantable devices. Instead, manufacturers must apply the relevant requirements and guidance to the risks associated with their particular device.

For implantables, that means looking beyond the device itself. Wireless connections, clinical programmers, remote monitors, and supporting software may all affect patient safety.

FDA cybersecurity guidance and implantable devices

The February 2026 FDA cybersecurity guidance recommends that manufacturers address cybersecurity throughout device design, development, and maintenance.

For implantable devices, that includes identifying potential threats, implementing appropriate security controls, and testing whether those controls work as intended.

FDA also recommends documenting the device's security architecture and explaining how manufacturers plan to manage vulnerabilities after the device reaches the market.

The goal is to give reviewers enough information to understand the device's cybersecurity risks and how the manufacturer has addressed them.

When an implantable device qualifies as a Section 524B cyber device

Not every implantable medical device automatically falls under Section 524B of the Federal Food, Drug, and Cosmetic Act.

To qualify as a Section 524B cyber device, a product must meet three statutory criteria:

• Include software validated, installed, or authorized by the manufacturer.
• Have the ability to connect to the internet.
• Contain technological characteristics that could make it vulnerable to cybersecurity threats.

For devices meeting that definition and submitted through covered premarket pathways, Section 524B requires manufacturers to provide specific cybersecurity information.

This includes plans for monitoring and addressing vulnerabilities, processes for providing updates and patches, and a software bill of materials (SBOM).

Manufacturers should evaluate how the implant and its associated equipment connect to other systems when determining whether Section 524B applies.

Threat modeling and cybersecurity risk assessment

FDA recommends threat modeling to help manufacturers identify where an attacker might exploit weaknesses in a medical device system.

For an implantable device, that assessment should consider the implant, its wireless interfaces, clinical programmers, remote monitoring equipment, and relevant supporting infrastructure.

Manufacturers should document potential attack paths, evaluate exploitability, and determine whether a successful attack could lead to patient harm.

That last point is especially important. A vulnerability that exposes diagnostic information presents different risks from one that could interfere with essential therapy.

The cybersecurity risk assessment should explain how identified risks are addressed and how the remaining risks are managed.

Security architecture and documentation

FDA reviewers need more than a statement that an implantable device is secure. They need technical documentation showing how the system works and where its security controls operate.

The FDA guidance recommends several security architecture views, including information about system connections, security boundaries, and potential effects on multiple patients.

For implantable devices, these views can help explain how the implant communicates with programmers, remote monitors, and other supporting systems.

Manufacturers should also document security controls, testing results, and the relationship between identified threats and the measures used to address them.

Clear documentation makes it easier for reviewers to follow the manufacturer's cybersecurity reasoning and identify any gaps that still need attention.

How cybersecurity testing changes for implantable devices

Testing an implantable device isn't quite the same as testing a connected medical device that sits on a hospital cart.

Manufacturers must evaluate the implant's security without creating conditions that could compromise its clinical functions. They also need to test the external equipment and communication pathways that make up the complete system.

Testing wireless communications and external interfaces

Wireless connections are a good place to start. Manufacturers should test whether unauthorized users can communicate with the implant, intercept sensitive information, or send commands the device shouldn't accept.

That means evaluating authentication, encryption, communication protocols, and the controls protecting device settings.

Testing should also examine what happens when communications are interrupted or unexpected data reaches the device.

The objective is to identify weaknesses before someone can exploit them, while confirming that security controls don't interfere with normal device operation.

Testing programmers and remote monitoring systems

A secure implant doesn't guarantee a secure system.

Clinical programmers and remote monitoring equipment may have vulnerabilities that create opportunities for unauthorized access, data exposure, or disrupted communications.

Manufacturers should evaluate these components individually and test how they interact with the implant.

For example, could a compromised programmer send commands the implant shouldn't accept? Could someone exploit a weakness in a remote monitoring application to access patient information?

These are the kinds of questions that medical device penetration testing can help answer.

Testing should reflect the actual system architecture, including the interfaces and security boundaries identified during threat modeling.

Testing without compromising patient safety

There's an obvious challenge with implantable devices. Manufacturers can't conduct potentially disruptive security tests on devices actively providing therapy to patients.

Instead, testing should use controlled laboratory environments, representative hardware, simulators, or other appropriate test setups.

These environments allow engineers to evaluate vulnerabilities, communication failures, and recovery procedures without putting patients at risk.

Manufacturers should also document the test configuration, methods, findings, and any limitations that could affect how results apply to the finished device.

FDA reviewers need to understand what was tested, what the testing demonstrated, and whether any identified cybersecurity risks remain unresolved.

Managing cybersecurity throughout the implant's lifecycle

An implanted medical device may remain inside a patient for years. During that time, new vulnerabilities can emerge, software components can become outdated, and the technology supporting the device may change.

Manufacturers need a plan for managing these risks long after the device receives FDA clearance or approval.

Vulnerability monitoring and coordinated disclosure

A device that passes cybersecurity testing today may develop security concerns later.

New vulnerabilities can appear in the implant's software, external programmers, remote monitors, or third-party components.

Manufacturers should have processes for monitoring vulnerability reports, evaluating potential risks, and determining whether corrective action is necessary.

Coordinated vulnerability disclosure is another important part of this process. It gives security researchers and other parties a way to report suspected weaknesses so manufacturers can investigate them.

For devices covered by Section 524B, manufacturers must establish plans and processes for monitoring, identifying, and addressing postmarket cybersecurity vulnerabilities and exploits.

Software updates and patchability

Software updates can address known vulnerabilities, but delivering them to an implanted device requires careful planning.

Depending on the device, an update may involve wireless communication, specialized programming equipment, or a visit to a healthcare provider.

Manufacturers need to consider what happens if an update is interrupted or fails. They should also protect the update process against unauthorized software changes.

FDA recommends designing devices with secure update capabilities and documenting how vulnerabilities will be addressed throughout the device's lifecycle.

For implantables, the update strategy must account for patient safety, device limitations, and the need to maintain essential clinical functions.

Long-term support and end-of-life planning

What happens when a software component reaches the end of vendor support, but the implant is still functioning inside a patient?

That's a question manufacturers should address well before the device reaches the market.

Unsupported components may no longer receive security patches, leaving manufacturers to evaluate whether additional protections or other corrective measures are needed.

The same concern applies to external programmers, monitoring equipment, and supporting software.

Manufacturers should document component support status, assess vulnerabilities as they emerge, and establish plans for maintaining cybersecurity throughout the device's expected service life.

For implantable devices, end-of-life planning isn't simply about replacing outdated technology. It's about managing cybersecurity risks while patients continue to depend on devices already in use.

What manufacturers should document for FDA

FDA reviewers need to understand how a manufacturer identified cybersecurity risks, what protections are in place, and whether those protections work.

For implantable devices, the documentation should cover more than the implant itself. External programmers, wireless connections, remote monitors, and supporting software may all play a role in device safety.

The goal is to provide enough technical evidence for FDA to evaluate the manufacturer's cybersecurity approach.

Threat models and cybersecurity risk assessments

A threat model identifies potential attack paths and vulnerabilities across the medical device system.

For implantables, that includes examining how the device communicates with external equipment, who can access its functions, and what could happen if a security control fails.

The cybersecurity risk assessment builds on that work by evaluating exploitability, potential consequences, and the measures used to address identified risks.

Manufacturers should document their findings and show how security controls relate to specific threats. If a vulnerability could lead to patient harm, the assessment should also address those connections.

SBOMs, security testing, and architecture views

FDA recommends documentation that gives reviewers a clear picture of the device's software, system architecture, and cybersecurity protections.

A software bill of materials (SBOM) identifies software components and helps manufacturers track vulnerabilities and support status. For devices subject to Section 524B, SBOM is a statutory submission requirement.

Security architecture views should show relevant system connections, trust boundaries, and security controls.

Testing documentation should explain what was tested, how testing was performed, what vulnerabilities were found, and how those findings were addressed.

For implantable devices, this evidence should account for the external systems and communication pathways that could affect device safety.

Cybersecurity management and update plans

Manufacturers also need to explain how they'll manage cybersecurity after the device reaches the market.

That includes monitoring vulnerabilities, evaluating newly discovered threats, and determining when corrective action is needed.

Update plans should address how software changes will be authenticated, delivered, and verified without compromising essential device functions.

For implantables, manufacturers should also consider what happens when an update fails or a component reaches the end of vendor support.

Preparing this information is part of the broader medical device cybersecurity documentation process. Well-organized documentation helps FDA reviewers understand how the manufacturer plans to manage cybersecurity risks throughout the device's lifecycle.

How CyberMed helps manufacturers secure implantable devices

Securing an implantable medical device takes more than testing the implant itself. Manufacturers also need to evaluate the programmers, remote monitors, wireless connections, and supporting software that make up the complete system.

CyberMed helps medical device manufacturers identify cybersecurity risks, evaluate security controls, and prepare the technical documentation needed for FDA submissions.

That work can include:

• Threat modeling: Identifying potential attack paths across the implant, external equipment, and communication interfaces. The goal is to understand where vulnerabilities could arise and how they might affect patient safety.
• Security testing: Evaluating authentication, wireless communications, software vulnerabilities, and other potential weaknesses. Testing focuses on the device's actual architecture and identified risks.
• Cybersecurity documentation: Preparing threat models, risk assessments, security architecture views, and testing evidence that help FDA reviewers understand how cybersecurity risks have been addressed.
• Submission readiness: Reviewing cybersecurity documentation for missing information, unresolved risks, and gaps that could lead to additional FDA questions.

For manufacturers, the benefit is having a clearer picture of the entire device system before submitting it for FDA review.

Securing the entire implantable device system

An implantable medical device doesn't operate in isolation. It may depend on wireless communications, external programmers, remote monitoring equipment, and software that changes throughout the device's lifecycle.

Each connection creates another area manufacturers need to evaluate.

The challenge is protecting these systems without interfering with the clinical functions patients depend on. That means identifying realistic threats, testing security controls, documenting the results, and preparing for vulnerabilities that may emerge years after implantation.

FDA expects manufacturers to address cybersecurity risks based on the device's design, connectivity, and potential consequences for patient safety.

CyberMed can help manufacturers bring those pieces together, from early threat modeling through security testing and FDA submission documentation.

Sources

• FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance, February 3, 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
• Federal Food, Drug, and Cosmetic Act, Section 524B, Ensuring Cybersecurity of Devices (21 U.S.C. 360n-2). https://www.law.cornell.edu/uscode/text/21/360n-2
• FDA. Postmarket Management of Cybersecurity in Medical Devices. Final guidance, December 28, 2016. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/postmarket-management-cybersecurity-medical-devices
• FDA. Cybersecurity in Medical Devices Frequently Asked Questions (FAQs). https://www.fda.gov/medical-devices/digital-health-center-excellence/cybersecurity-medical-devices-frequently-asked-questions-faqs