Medical Device Cybersecurity in the Quantum Era: Why Hospital Devices Will Outlive Their Encryption
Medical device cybersecurity has always been a race between patching and exposure. Now it has a second clock. The infusion pump, patient monitor, or imaging system a hospital buys this year may still be in clinical use in the late 2030s. By then, the RSA and elliptic-curve cryptography protecting it is scheduled to be retired. Healthcare leaders who plan only for today’s threats are buying devices that will fall short of tomorrow’s standards before they are fully paid off.
This guide explains the gap, what regulators already require, and how hospitals and manufacturers can close it. It starts from a simple belief we hold at ibm/SEIMless: protecting patient data is protecting people.
What is medical device cybersecurity? Medical device cybersecurity is the practice of protecting connected clinical devices, and the patient data and care they support, from unauthorized access, tampering, and disruption across the device’s full lifecycle, from design through retirement.
What is the cryptographic lifespan gap? The cryptographic lifespan gap is the number of years a device stays in clinical service after the encryption it relies on has been deprecated. For most connected devices bought in 2026, that gap is already more than zero.
Why Medical Device Cybersecurity Now Has a Quantum Deadline
In August 2024, NIST published its first three post-quantum standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). In March 2025 it selected HQC as a backup encryption algorithm. Its draft transition plan, NIST IR 8547, proposes deprecating quantum-vulnerable algorithms after 2030 and disallowing them after 2035.
Federal policy has since set dates. Executive Order 14412, signed June 22, 2026, gives federal systems until December 31, 2030 to adopt post-quantum key establishment. We covered those milestones in our Executive Order 14412 deadline guide. The NSA’s CNSA 2.0 FAQ goes further on firmware. It urges signing systems to move first, because the code that checks a signature is often hard to update once a product ships.
That last point is the heart of the medical device cybersecurity problem. Enterprise laptops are replaced every few years. Clinical equipment is not.
The Cryptographic Lifespan Gap, Explained
Here is the arithmetic. A connected device bought in 2026 and kept for 10 to 15 years stays in service until 2036–2041. If the 2030 and 2035 dates in NIST’s draft hold, that device will spend years running cryptography that federal standards no longer accept.
| Device purchased | Likely retirement | Years past 2030 deprecation | Years past 2035 disallowance |
| 2020 | 2030–2035 | 0–5 | 0 |
| 2026 | 2036–2041 | 6–11 | 1–6 |
| 2029 | 2039–2044 | 9–14 | 4–9 |
These ranges are illustrative, not a prediction for any single product. The pattern is the point: the later a hospital waits to demand post-quantum readiness, the wider the gap it signs up for.
An FDA-commissioned white paper from MITRE, Managing Legacy Medical Device Cybersecurity Risks, makes the same point. It warns that devices being purchased today can already meet the definition of a legacy device. It also notes a mismatch between how long hospitals keep equipment and how long manufacturers support it.
Why patient data makes “harvest now, decrypt later” worse
Attackers do not need a quantum computer today to benefit from one later. They can record encrypted traffic now and decrypt it once the math breaks. We explain the tactic in Harvest Now, Decrypt Later, and the underlying math in Shor’s algorithm explained.
Health data is an ideal target. A credit card can be canceled. A diagnosis, a genetic result, or a psychiatric history cannot. Data that stays sensitive for a patient’s lifetime needs protection that lasts just as long.
What the FDA Already Requires for Medical Device Cybersecurity
The FDA has steadily raised the bar. Since March 29, 2023, section 524B of the FD&C Act has required makers of “cyber devices” to include cybersecurity information in premarket submissions. The FDA’s cybersecurity FAQ defines a cyber device as one that includes sponsor-validated software, can connect to the internet, and could be vulnerable to cyber threats.
Manufacturers must now:
- Submit a plan to monitor, identify, and address postmarket vulnerabilities.
- Provide a software bill of materials (SBOM) covering commercial, open-source, and off-the-shelf components.
- Make updates and patches available to the device and related systems.
The FDA’s premarket guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, was updated on February 3, 2026 to align with the new Quality Management System Regulation. It lists cryptography among its recommended security controls. It also names secure and timely updatability and patchability as a core security objective. The agency’s postmarket guidance adds that networked devices need continual maintenance for their entire life.
Where the rules stop
None of these documents sets a date for post-quantum algorithms in medical devices. And as the GAO noted in GAO-24-106683, the 524B requirements do not reach back to devices already on the market before March 2023 unless a maker files a new submission. That leaves the installed base, which is most of what hospitals actually run, outside the new rules.
The Legacy Fleet Hospitals Already Own
Healthcare delivery organizations inherit the gap whether they planned for it or not. The FBI warned in a 2022 private industry notification that unpatched and outdated medical devices give attackers openings into hospital networks. The Health Sector Coordinating Council’s Managing Legacy Technology Security (HIC-MaLTS) guide describes the same shared burden between makers and providers.
The risk is not theoretical. In January 2025, the FDA issued a safety communication on certain Contec and Epsimed patient monitors. It pointed to CISA advisory ICSMA-25-030-01, which described hidden functionality and patient data being sent outside the care environment. The FDA’s advice was to cut the monitors off from the internet.
When the fix for a device is “disconnect it,” the network becomes the only control left. That is exactly where post-quantum protection can be added without waiting for firmware.
The stakes are high. An analysis of 2025 OCR data counted 710 large healthcare breaches exposing more than 61.5 million people’s records. Every one is listed on the HHS OCR breach portal. We saw the downstream damage in the Change Healthcare hack.
Why Post-Quantum Cryptography Is Hard on Medical Devices
If swapping algorithms were easy, the gap would close on its own. Four constraints make it hard.
1. Bigger keys and signatures
Post-quantum keys and signatures are much larger than the ones they replace. Per the FIPS 203 and 204 parameter sets:
| Function | Classical (today) | Post-quantum (NIST) |
| Key exchange public key | X25519: 32 bytes | ML-KEM-768: 1,184 bytes |
| Digital signature | ECDSA P-256: about 64 bytes | ML-DSA-65: 3,309 bytes |
On a battery-powered wearable or a low-memory controller, those extra bytes cost power, bandwidth, and storage.
2. Firmware roots of trust
Many devices verify updates with a key burned into hardware. If that check only understands RSA or ECDSA, no software update can teach it a new algorithm. This is why CNSA 2.0 favors the stateful hash-based signatures in NIST SP 800-208 (LMS and XMSS) for firmware signing now.
3. Validation and re-submission
Changing cryptography can mean new testing under the Cryptographic Module Validation Program and, for some changes, a new FDA submission. Our look at certificate lifecycle management and the FIPS 140-2 sunset covers why validation queues matter.
4. Protocols built for another era
Clinical networks still carry older protocols, flat VLANs, and vendor remote-access tunnels. We examined similar weak points in quantum computing’s impact on IPsec and why SD-WAN is not ready for next-generation attacks.
Regulatory Pressure Beyond the FDA
Medical device cybersecurity sits inside a wider compliance picture for providers:
- The January 2025 Security Rule proposal would require encryption of ePHI with limited exceptions, a technology asset inventory, and network segmentation. It had not been finalized as of this writing, but it shows where regulators are heading.
- HHS voluntary goals. The HPH Cybersecurity Performance Goals and the 405(d) Health Industry Cybersecurity Practices give hospitals a practical baseline, including asset management and medical device security.
- Federal quantum readiness. CISA, NSA, and NIST’s joint Quantum-Readiness fact sheet asks organizations to build a cryptographic inventory and engage vendors now. Health systems that serve federal programs should also watch EO 14412 contract requirements.
- Reference designs. NIST’s NCCoE offers SP 1800-8 on securing wireless infusion pumps and a Migration to Post-Quantum Cryptography
A Medical Device Cybersecurity Roadmap for Hospitals
Hospitals cannot rewrite vendor firmware. They can control what surrounds it. A practical sequence:
- Inventory every connected device and its cryptography. Record the protocol, algorithm, certificate, and end-of-support date. A cryptographic bill of materials (CBOM) turns this into a living record.
- Score each device by its lifespan gap. Rank devices by planned retirement date, data sensitivity, and whether their cryptography can be updated.
- Segment clinical networks. Put devices in tightly scoped zones with zero trust policies, so a compromised monitor cannot reach the EHR.
- Wrap device traffic in quantum-resistant tunnels. Protect the paths between clinical zones, data centers, clouds, and remote sites so recorded traffic stays safe.
- Centralize key management. Rotate and govern keys in one place, rather than on thousands of endpoints.
- Watch device behavior. Flag devices that suddenly talk to unknown destinations, as in the Contec case.
- Protect the data at rest. Encrypt and back up the imaging archives and clinical data that devices feed.
- Write post-quantum language into contracts. Make readiness a buying requirement, not a wish.
Six questions to ask every device manufacturer
- Which algorithms does the device use for key exchange, signing, and storage today?
- Can those algorithms be changed by a field update, or are they fixed in hardware?
- What is your published roadmap for ML-KEM, ML-DSA, or LMS/XMSS support?
- Will you provide a CBOM alongside the SBOM?
- What is the end-of-support date, and what happens to security updates after it?
- Does the device support hybrid classical plus post-quantum modes during the transition?
What Manufacturers Should Build Into the Next Submission
For device makers, medical device cybersecurity is now a design decision with a long tail. The strongest submissions will show:
- Crypto-agility by design. Algorithms isolated behind interfaces so they can be swapped without a hardware change.
- Quantum-safe roots of trust. LMS or XMSS firmware signing, with ML-DSA as validated modules fit the device.
- Hybrid key exchange. Classical plus ML-KEM during the transition, so security never drops below today’s level.
- Honest lifecycle dates. End-of-support timelines that match how long hospitals actually keep equipment.
- A CBOM next to the SBOM. Buyers increasingly need to see cryptography, not just components.
How ibm/SEIMless Helps Close the Medical Device Cybersecurity Gap
Our view is simple: the fastest way to protect devices you cannot change is to protect the network around them. That is the thinking behind our Exodus QRN quantum-resistant networking suite.
- Exodus QRN Data in Motion applies quantum-resistant encryption to traffic in transit, with optional stateful firewalling.
- QR Edge extends quantum-resistant protection to the edge of the network.
- Exodus Key Management centralizes key control across sites.
- Exodus Aria ADR and the Exodus NxtGen Firewall add detection and policy enforcement around clinical zones.
- Zero Trust Content Security and EDR protect the workstations that manage devices.
- Exodus QRN Data at Rest, backup and recovery, and private and hybrid cloud services protect the records devices produce.
Because this protection runs at the network layer, it does not depend on a device maker shipping new firmware. Hospitals can start with their highest-risk paths this quarter, then extend coverage as budgets allow. For the full migration picture, see our post-quantum cryptography migration playbook and network edge security in 2026. For AI-driven clinical workflows, our analysis of blind agent transfer applies to healthcare just as much as finance.
Medical Device Cybersecurity FAQ
What is medical device cybersecurity?
Medical device cybersecurity is the protection of connected clinical devices, and the patient data and care they support, from unauthorized access, tampering, and disruption across the device’s full lifecycle, from design through retirement.
Does the FDA require post-quantum cryptography in medical devices?
Not by a specific date. Section 524B requires cybersecurity information, an SBOM, and a vulnerability plan for cyber devices, and FDA guidance recommends strong, updatable cryptography. It does not yet set a deadline for post-quantum algorithms.
What is the cryptographic lifespan gap?
It is the number of years a device stays in clinical use after the encryption it relies on has been deprecated. A device bought in 2026 and kept 10 to 15 years may run six or more years past NIST’s proposed 2030 deprecation date.
Can hospitals protect legacy medical devices that cannot be updated?
Yes, with compensating controls. Segmentation, zero trust policies, behavior monitoring, and quantum-resistant encryption of network paths protect device traffic without changing device firmware.
Why is health data a target for harvest-now, decrypt-later attacks?
Health information stays sensitive for a patient’s lifetime. Attackers can record encrypted traffic today and decrypt it once quantum computers can break RSA and elliptic-curve cryptography.
What should hospitals ask device manufacturers about quantum readiness?
Ask which algorithms the device uses, whether they can be updated in the field, the vendor’s roadmap for ML-KEM, ML-DSA, or LMS/XMSS, whether a CBOM is available, and the end-of-support date.
Protect Patients Before Q-Day Arrives
Every connected device in your hospital carries a patient’s trust. ibm/SEIMless and Exodus QRN help healthcare, financial, and insurance organizations close the medical device cybersecurity gap at the network layer, without waiting on firmware. Let’s map your highest-risk device paths together.
