How does it feel to literally lose your heart? Not in a metaphorical way, but in a literal way? Having a pacemaker is quite common these days. It can not only be hacked, but the bad actors can also put malware on it. Yes, it has not happened outside of laboratory, experiments, yet. There have also been massive recalls of pacemakers due to security concerns. This is not just one connected medical device; the danger has been flagged in JAMA in 2024. Now, the FDA has swung the hammer hard.
FDA’s 2025 final premarket cybersecurity guidance reframes cybersecurity for connected medical devices (CMDs) as a foundational safety obligation that must be demonstrated before market entry, not as an auxiliary concern. This diktat changes the very logic of how device makers design, document, and govern software risk in clinical environments they do not control. To put it simply, the new guidance now needs vendors to provide evidence that the product will be sustainably manageable across real hospitals, fragmented IT estates, aging infrastructure, and an unpredictable threat landscape. Then again, connected medical devices are not your “normal” devices. An infusion pump depends on hospital Wi-Fi. A patient monitor streams data to cloud analytics platforms. Imaging equipment integrates with PACS, EHRs, and third-party visualization tools. Remote patient monitoring devices rely on consumer-grade networks, which are usually outside clinical facility control. Each integration introduces dependencies, vulnerabilities, and operational frictions that sit outside the manufacturer’s direct authority. A device by itself may be safe, but what about the surrounding environment?
QKS Group’s senior security analyst Kunal Kumar advises, “The FDA’s latest cybersecurity guidance signals a structural shift in how connected medical devices are evaluated. Cybersecurity is no longer a post-market IT issue, but a premarket patient safety requirement. Vendors must now prove not only that their devices work, but that they can be securely deployed, maintained, and trusted across complex hospital environments. In this new reality, lifecycle resilience and transparency will differentiate leaders from laggards.”
The FDA guidance acknowledges this reality by treating cybersecurity as a system-level risk shaped by software supply chains, deployment environments, patch feasibility, and organizational incentives inside medical facilities, and not as a property of the device alone. This is why the guidance leans heavily on documentation such as Software Bills of Materials (SBOMs), structured patch plans, and lifecycle risk management artifacts. This is not unnecessary paperwork. They are intended to answer the question of the manufacturer’s understanding of how the device behaves in the messy, networked real-life world where it will actually end up.
The guidance helps answer this question by making guidelines binding. It ensures cybersecurity is now embedded in design controls. This addition makes risk analysis traceable to specific software decisions, threat models, and mitigations, and does away with generic claims about “secure coding.” Documentation must be easier. Patch plans, vulnerability management processes, and monitoring approaches must be concrete enough to allow a reviewer to imagine how they would actually function in a hospital setting. Supply chain transparency has become non-negotiable, with structured SBOMs now an expected component of premarket submissions.
It also addresses another vexing issue of patching. Downtime can affect patient care. Facilities operate under strict change-control windows, often lack sufficient biomedical staffing, and rely on legacy networks that complicate updates. In some cases, devices are kept in an “as is” condition for long periods because any change introduces clinical or liability risk. The guidelines should allow vendors and users to share the responsibility of controls between manufacturers and users. Users can handle controls that can be managed locally. In a field where a vulnerability has potentially fatal consequences, this will ensure risk analyses connect technical threats to real-world outcomes, essentially tying cybersecurity with safety engineering. Effective vendor-user collaboration is vital for efficient equipment functioning in such a situation.
For manufacturers, this shift creates both risk and opportunity. Companies that treat cybersecurity as a late-stage compliance exercise will struggle as boilerplate documentation will no longer suffice, and review timelines may lengthen for those unprepared. However, organizations that invest early in software governance, threat modeling, and hospital partnerships can differentiate themselves not just with regulators, but with healthcare providers. Hospitals increasingly prioritize manageability: how easy is this device to secure over its lifecycle, how transparent is the vendor about vulnerabilities, and how cooperative are they during incidents? Does your product provide answers to all these questions?