The unpatchable medical device problem and the FDA compensating-control answer.

Why can't legacy and end-of-life medical devices be patched?

Legacy and end-of-life medical devices frequently cannot be patched because the fix no longer exists, the platform beneath them has aged out, or a patch would break the certified configuration.

Three forces converge on the same result. First, the manufacturer no longer supports the software, and for a device whose maker has left the market there is simply no one to write or validate a fix. Second, the underlying operating system has itself reached end of life, so even where the device code could change, the platform beneath it stopped receiving security updates years ago and cannot be brought current without replacing the device. Third, the device was cleared against a fixed configuration, and changing the code on a device certified under a specific design can trigger revalidation that the organization has neither the time nor the manufacturer relationship to complete. Layer on top of this the clinical reality: a twelve-year-old infusion pump, an aging imaging console, a bedside monitor that has run reliably for a decade, these devices still work and still serve patients, so pulling them from service is expensive, disruptive, and sometimes unsafe in its own right. The result is a fleet of devices carrying real, known vulnerabilities that cannot be closed at the source and cannot simply be retired. That is the gap. It is not a failure of diligence; it is a structural feature of long-lived medical hardware, and it is exactly the situation compensating controls are designed to address. RankShieldMD begins by attesting the identity and integrity of the unpatchable device, so containment starts from a device you can actually name and verify rather than a guess.

What does the FDA mean by a compensating control?

A compensating control is a safeguard used in lieu of a manufacturer fix, and the FDA recognizes it, naming network segmentation explicitly, as a way to bring the risk of patient harm to an acceptable level.

The idea is borrowed from long-established security practice. When you cannot remove a vulnerability at its source, you apply a different safeguard that reduces the chance the vulnerability is reachable or exploitable, and then you document why the risk that remains is acceptable. The FDA recognizes compensating controls in this sense for devices that cannot be patched, and it explicitly includes network segmentation among the controls it will consider.^[3] That matters, because it means the regulatory posture for an unpatchable device is not simply refuse to accept and remove from service; it is contain, evidence, and justify. For an unpatchable infusion pump or imaging console, a compensating control typically means isolating the device on a segmented network so only approved systems and approved traffic can reach it, restricting the accounts and services that touch it, and monitoring its posture continuously so drift is caught. None of that changes the device software, which is precisely why it works for a device you cannot patch. RankShieldMD produces the evidence layer beneath the control: a verifiable device identity so the isolated thing is provably the right thing, and continuous posture evidence so the isolation is demonstrably still in place. The control is yours to design and operate; RankShieldMD makes it provable rather than asserted. And it never claims more than that: a compensating control brings risk to an acceptable level, it is not a cure, and it does not make an unpatchable device safe in absolute terms.

How do segmentation and containment states reduce patient-harm risk?

Segmentation and containment states reduce patient-harm risk by shrinking the paths an attacker can use to reach an unpatchable device and by quarantining it the moment its posture drifts, even though the underlying vulnerability remains.

Segmentation is the workhorse. Placing an unpatchable device on an isolated network zone, where only approved systems and approved traffic are permitted to communicate with it, dramatically reduces the number of ways an attacker could ever reach the vulnerability in the first place. The flaw in the device software has not gone anywhere, but reachability has collapsed, and reachability is what turns a latent weakness into an exploitable one. Containment states extend the same logic in time: if a device that should be quiet on its segment begins behaving abnormally, or its posture drifts from the known-good baseline, it can be quarantined so it stops being a pathway to anything else. The load-bearing addition RankShieldMD makes is verifiable device posture. It is one thing to assert that a pump sits on an isolated VLAN; it is another to prove, with a signed identity and a continuous posture record, that this specific device is on that specific segment and that its posture has not changed since it was placed there. Without that proof, segmentation is a diagram; with it, segmentation is evidence. RankShieldMD attests the device identity, records posture continuously, and seals containment events to a tamper-evident ledger, so a reviewer can confirm not only that a control was designed but that it was actually in force. Segmentation reduces reachability and containment limits blast radius; neither removes the vulnerability, so the residual risk that survives these controls still has to be documented and formally accepted.

What is a residual-risk dossier under ISO 14971?

A residual-risk dossier is a documented, signed record, built on the ISO 14971 risk-management framework, that shows the risk remaining after your controls are applied and justifies why that remaining risk is acceptable.

ISO 14971 is the international standard for the application of risk management to medical devices, and it frames risk in a specific shape: hazards, the controls applied against them, and the residual risk that survives once those controls are in place. A residual-risk dossier for an unpatchable device puts that shape to work. For each hazard the vulnerability creates, it records the compensating control used against it, the risk level before the control and the risk level after, and the benefit-risk reasoning that justifies keeping the device in clinical service rather than removing it. That benefit-risk step is central: a device that is delivering real clinical value while carrying a contained, monitored, residual risk can be entirely defensible, but only if the reasoning is written down, evidenced, and signed rather than assumed. The weakest version of this is a spreadsheet that asserts controls exist; the strongest is a dossier where each control is backed by verifiable evidence that it is actually in force. RankShieldMD produces the identity and posture evidence that populates the dossier, the proof that the segmented device is the right device and that its posture holds, and seals the whole record to a tamper-evident, externally-anchored ledger with a verify recipe. A reviewer or auditor can then recompute the dossier and confirm it has not been altered after the fact. RankShieldMD supports your risk file. The risk decision, and the formal acceptance of the residual risk, remain yours.

How does containment become §524B submission and postmarket evidence?

Containment becomes submission and postmarket evidence when the compensating control and its residual-risk dossier are produced as signed artifacts that map to the §524B(b)(1) postmarket obligation and drop into the quality record.

FD&C Act §524B(b)(1) expects a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits within a reasonable time.^[7] For a device that cannot be patched, the compensating control is how you address the vulnerability the statute has in mind, and the residual-risk dossier is how you show the risk that remains after the control is acceptable. Framed this way, containment is not a workaround that lives outside the regulatory record; it is the substance of the postmarket obligation for an unpatchable device, and it belongs in the submission and the quality record as evidence. RankShieldMD produces that evidence as signed artifacts: a continuous posture and containment feed that records how the device is isolated and whether that isolation holds, plus the ISO 14971 residual-risk dossier, each sealed to an externally-anchored transparency ledger a reviewer can recompute rather than take on trust. This lands directly against a near-term change in expectations. The Quality Management System Regulation, which harmonizes the FDA quality-system requirements with ISO 13485, takes effect February 2, 2026 and expects objective evidence that processes were followed and risk decisions justified.^[7] Signed containment records, posture evidence, and a sealed residual-risk dossier are exactly that kind of objective evidence, and they file into the quality record as they are produced rather than being reconstructed at audit time. RankShieldMD produces evidence that supports your submission and quality record. It never makes your submission, it never makes you compliant or cleared, and the FDA remains the deciding authority.

References

1. [3] FDA (June 27, 2025, final). Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions. federalregister.gov/documents/2025/06/27/2025-11669
2. [7] FD&C Act §524B (added by the Consolidated Appropriations Act 2023, effective March 29, 2023). fda.gov/medical-devices/…/cybersecurity
3. ISO ISO 14971 Medical devices, application of risk management to medical devices. iso.org/standard/72704.html