MedJacking Explained: What the Term Covers and What Doesn't

Part of our Medical device vulnerability, threat, and attack-technique catalogue. For the full overview, start with The Top 50 Cybersecurity Issues with Medical Devices.

MedJacking gets used as a headline word more often than it gets used accurately. The underlying engineering question is not whether an implanted device could theoretically be manipulated. Researchers have shown that under controlled conditions for over a decade. The question that matters for a manufacturer is which of those demonstrated vulnerabilities have realistic attacker economics behind them, and which controls close the gap between a lab proof of concept and a device sitting in a patient for ten years without a security update. That is an engineering question, not a marketing one.

Why This Matters

The FDA's final guidance Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, issued February 3, 2026, is the current step in a chain that ran through the September 27, 2023 final guidance and the June 27, 2025 update, and it makes cybersecurity documentation a gating criterion for clearance under Section 524B of the FD&C Act. Reviewers evaluate the threat classes MedJacking describes, unauthorized access, remote manipulation, and command injection, using the same threat-modeling and security-risk-management expectations that apply to every cyber device.

That means the term itself does not matter to a reviewer. What matters is whether your threat model names the specific attack paths a connected implant or infusion device actually has, and whether your controls close them. A submission built around a vague reference to hacking risk, without a concrete attack tree, does not meet that bar regardless of what the product category is called in the press.

Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); FDA, Postmarket Management of Cybersecurity in Medical Devices (2016); CISA Known Exploited Vulnerabilities Catalog; CISA Cybersecurity Advisories (including ICS medical advisories).

What does MedJacking actually describe?

MedJacking describes an attacker gaining control of a specific medical device's function, as opposed to breaching a hospital network or stealing data. MedHacking is the umbrella term that covers both: any unauthorized access to medical technology, from an EHR breach to a compromised infusion pump. The distinction is useful for scoping a threat model, since network breaches and device hijacking need different controls even though both fall under the same broad label.

In practice, a device threat model should not use either term as a category. It should enumerate specific attack paths: unauthenticated wireless pairing, an unsigned firmware update mechanism, a debug interface left active in production, or a cloud API that trusts device identity without verifying it. MedJacking as a word describes an outcome, not a mechanism, and mechanisms are what a security architecture review and a penetration test actually evaluate.

Which historical cases are verified, and which are overstated?

Verified: independent researchers have repeatedly demonstrated that certain wireless insulin pumps and implantable cardiac devices could be manipulated by someone with physical or close-range radio access and the right equipment, and these findings led to FDA safety communications and manufacturer firmware updates. These are documented, published, and led to concrete remediation. That track record is real and it is the reason regulators now expect premarket threat modeling for connected implants.

What does not hold up under scrutiny is the broader claim, often repeated without a specific source, that hospital ransomware outbreaks were caused by an attacker pivoting through a hijacked implanted device. That mechanism has not been demonstrated in a documented, attributed incident. Ransomware operators overwhelmingly enter through phishing, exposed remote access, and unpatched enterprise systems, not through pacemakers. Conflating the two exaggerates the implant risk and understates the actual dominant attack vector.

Why do researcher demonstrations differ from real attacker economics?

A researcher demonstration is optimized to prove a vulnerability exists, with time, physical device access, specialized radio equipment, and no need to profit from the result. A real attacker weighs cost against payoff, and targeting one implanted device to harm one patient is an enormous amount of effort for a single, hard-to-monetize outcome.

Compare that to the economics of a ransomware attack against a hospital's file servers, which can affect thousands of records and extract a payment with far less specialized equipment. That is why the actual incident record skews heavily toward network and data attacks rather than device hijacking, even though device hijacking demonstrations get more media attention.

Which controls actually break the attack chain?

No single control stops device hijacking; the attack chain breaks at whichever link is missing, so a manufacturer needs coverage across several links rather than one strong control and several weak ones. Authentication on every command interface prevents an unauthorized party from issuing commands even with radio or network access. Encrypted and authenticated communication prevents both eavesdropping and injected commands that impersonate a legitimate sender.

See also: What Is MedTech? MedTech vs Medical Device vs Life Sciences, CVSS Scoring for Medical Devices: A Complete Walkthrough, and Medical Device Software Development: A Compliance Guide.

Signed firmware with integrity verification at boot stops a tampered update from ever running. Network segmentation limits how far a compromised device or workstation can reach, which matters most for infusion pumps and monitors that sit on hospital networks. Penetration testing under real attack conditions is what confirms these controls actually hold together as a chain rather than as a checklist of independent items.

What should a manufacturer do about legacy fielded devices?

Legacy devices without a security update mechanism are the real long-term liability, more than any single dramatic exploit, because a vulnerability found five years into a device's service life has no remediation path if the device cannot receive a signed update. A manufacturer's postmarket process should track which fielded device versions can and cannot receive updates, and treat the second category as a standing risk to manage, not a closed issue.

Where a device cannot be updated, compensating controls at the network or facility level, such as segmentation and access restriction, become the primary mitigation, and that dependency should be documented and communicated to the health delivery organizations still using the device. Waiting for a specific exploit to force the issue costs more than building the update path during design.

How Blue Goat Cyber Approaches This

We build the threat model around specific attack paths, unauthenticated interfaces, unsigned updates, unauthenticated wireless pairing, rather than a general hijacking risk narrative, because that is what a reviewer and a real penetration test both need to evaluate. Our team includes CISSP and OSCP certified engineers with prior red team backgrounds who test the full attack chain, not isolated components, so the result reflects whether the controls actually hold together.

For legacy or currently fielded devices, we assess what a security update path can realistically support and where compensating network-level controls have to carry the risk instead. Every finding traces back to a specific control and a verified test result. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.

Related reading: CAN Bus and CANopen Vulnerabilities in Medical Devices, RTOS Security for Medical Devices: What Manufacturers Must Control, Medical Device Penetration Testing Post Exploitation Explained, Functional vs Non-Functional Requirements in Medical Device Software, Brainjacking: FDA Cybersecurity Requirements for NeuroTech Manufacturers.

Frequently Asked Questions

Is MedJacking a term the FDA uses in its guidance?

Has a patient ever been harmed by an actual MedJacking attack, outside of a lab demonstration?

Does a device need physical proximity to be at risk, or can MedJacking happen remotely?

How does segmentation help if the vulnerability is in the device itself?

What is the single biggest gap manufacturers have in this area?

Should older cleared devices be retested against current threat classes?

CTA

If your device threat model still describes hijacking risk in general terms rather than specific attack paths, that gap will surface in review. Book a discovery session to walk through your device's attack surface and update path.