Published: May 22, 2026 · Last reviewed: May 1, 2026
By Christian Espinosa, Founder & CEO, Blue Goat Cyber
Last week I sat on a neurotech panel and made a point that landed harder than I expected: the implants we're putting in patients today are designed to last 10 to 20 years, but the cryptography protecting them won't. The CNN piece on Q-Day that's been making the rounds frames quantum computing as a looming cybersecurity crisis, and it is. But for medical devices, the framing is wrong. This isn't a future problem we have time to plan for. It's a present-day compliance gap the FDA has already written into guidance, and most manufacturers haven't read it that way yet.
The FDA Already Wrote the Requirement
Here's the language that matters. The FDA's February 2026 Premarket Cybersecurity Guidance tells manufacturers to use cryptography "expected to be considered cryptographically strong throughout the service life of the device." Read that sentence with a pacemaker in mind. Or a neurostimulator. Or an implantable cardioverter-defibrillator. Or an insulin pump. These devices stay in patients for a decade or two. The crypto running on most of them today — RSA and elliptic curve — will not survive that window once a cryptographically relevant quantum computer arrives. The FDA already wrote the requirement. The industry just hasn't connected the dots.
I review premarket submissions for a living, and I can tell you what I'm not seeing. I'm not seeing threat models that include a quantum adversary. I'm not seeing cryptographic agility designed into the device architecture. I'm not seeing migration plans for post-quantum cryptography in the Secure Product Development Framework documentation. The FDA guidance also says manufacturers should not implement deprecated algorithms, and that anything in "legacy use" status needs to be discussed with the agency at pre-submission. Once NIST formally deprecates RSA and ECC for the post-quantum era — and that timeline is shortening — every device shipping with classical-only crypto is going to be in that conversation whether the manufacturer wants to be or not.
Harvest Now, Decrypt Later — But the Patient Is Still Wearing the Device
The "harvest now, decrypt later" risk lands harder for medical devices than for almost any other sector. If an attacker captures biosignals from an implant today — cardiac rhythms, neural telemetry, continuous glucose data — that data stays sensitive for the patient's entire life. And the device transmitting it is still in their body when quantum decryption becomes practical.
The data outlives the crypto. The hardware outlives the crypto.
For a banking transaction, the exposure window closes when the account closes. For a neural implant, it doesn't close until the patient does. That's the asymmetry medtech leaders need to internalize.
The Tools to Fix This Already Exist
The good news is the tools to fix this already exist. NIST finalized the first post-quantum cryptography standards in August 2024: ML-KEM for key encapsulation, ML-DSA and SLH-DSA for digital signatures. These are not research-grade. They're production-ready, and hybrid schemes that pair classical and post-quantum crypto are deployable today.
The path forward for medical device manufacturers is not "go build a quantum-proof device from scratch." It's three concrete steps that can be implemented now.
1. Design for cryptographic agility
New devices entering premarket today should be architected so that cryptographic algorithms can be swapped without replacing the device. That means modular crypto libraries, sufficient compute and memory headroom, and a secure update mechanism robust enough to push a PQC migration over the air. The FDA's guidance on firmware and software updates already requires this kind of design thinking. Quantum just raises the stakes.
2. Deploy hybrid classical+PQC schemes on anything shipping in the next 24 months
Hybrid approaches give you classical security against today's threats and post-quantum security against harvest-now-decrypt-later attacks. This is what cloud providers, browsers, and messaging platforms are already doing. There's no reason medical device manufacturers should be behind that curve.
3. Document a PQC migration plan in your SPDF
When the FDA asks how your device will remain cryptographically strong over its service life — and they will ask — you need an answer that isn't "we'll figure it out." A documented migration plan, with milestones tied to NIST's deprecation timeline, is what a defensible submission looks like.
This Isn't Theoretical Anymore
None of this is theoretical. The standards are published. The FDA guidance is signed. The threat model is real, and for the devices we're putting in patients today, the timeline is shorter than the device's own warranty card.
Q-Day isn't coming for medtech. It's already here in the form of a requirement most manufacturers haven't satisfied. The work to close that gap starts now, in the next premarket submission, not in the next decade.
Frequently Asked Questions
Does the FDA explicitly require post-quantum cryptography?
Not by name. The February 2026 Premarket Cybersecurity Guidance requires cryptography "expected to be considered cryptographically strong throughout the service life of the device." For long-lived devices, that requirement cannot be satisfied with RSA or ECC alone — which makes PQC the practical answer.
What is Q-Day?
Q-Day is the point at which a cryptographically relevant quantum computer can break the public-key cryptography (RSA, ECC) that secures most digital communication today. Estimates vary, but credible forecasts place it inside the service life of implants being submitted right now.
What is "harvest now, decrypt later"?
An attacker captures encrypted traffic today and stores it until quantum computers can decrypt it. For medical telemetry — cardiac, neural, glucose — that captured data remains sensitive for the patient's lifetime.
What should manufacturers do for devices already in the field?
Postmarket devices need a documented PQC migration plan tied to the device's secure update mechanism. If the device has no field-updateable crypto stack, that's a Section 524B postmarket gap that needs an action plan.
Which NIST PQC algorithms should I plan around?
ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) as a hash-based signature alternative. Hybrid schemes pairing one of these with classical crypto are the current best practice for transition.