Post-Quantum Cryptography for Medical Devices (2026)

Nothing in this guide asks you to rewrite your crypto stack this year. It asks you to avoid three decisions that you cannot undo after tape-out.

Last reviewed: September 2026 against the FDA February 3, 2026 final premarket cybersecurity guidance, FIPS 203, FIPS 204, FIPS 205, NIST SP 800-208, NIST IR 8547 (initial public draft), and the NSA CNSA 2.0 advisory.

What is actually broken, in one page

Two kinds of cryptography sit in your device, and only one of them is in trouble.

Public-key cryptography is the part at risk. RSA and elliptic curves are what your device uses to agree on a session key with a programmer or a gateway, and to check that a firmware image came from you. Their security rests on math problems that a large quantum computer solves quickly. No such machine exists publicly today. The standards bodies have scheduled the retirement anyway, because you cannot re-key a fielded implant the way you re-key a web server.

Symmetric cryptography is mostly fine. AES and SHA lose some strength against quantum search, but doubling the key size restores it. If your device encrypts bulk data with AES-128, moving to AES-256 is the cheapest post-quantum work you will ever do, and you can do it in a sprint.

There is one more piece that surprises people. An attacker can record your encrypted telemetry or programming sessions today and decrypt them years later when the capability exists. That only matters if the data still matters years later, which for patient data it usually does. So confidentiality of long-lived data is a present-tense question even though the attack is not.

Here is why this reads differently for a device than for a hospital IT team.

Four things to do this quarter

None of these require you to pick a post-quantum algorithm. All four are cheap now and expensive after design freeze.

1. Write the cryptographic inventory. One table. Every place the device does cryptography: what algorithm, what key size, how long the key lives, and what it protects. Include the manufacturing line, the service tool, and the cloud service the device talks to. Most teams discover at least one algorithm nobody knew was in the product, usually inside a supplier's stack. This table is also the single artifact that makes every other statement in your submission checkable, so the work gets reused.

2. Answer one question about your trust anchor. Can the key that verifies firmware ever be replaced or joined by a second key? If it is in one-time-programmable fuses and there is only room for one, then the device can never accept a post-quantum signed update, no matter what software you write later. That is a hardware decision, and it has to be made before tape-out. Provisioning two anchors at manufacture is the common fix and it is much cheaper than the alternative.

3. Do a sizing pass. Take your flash layout, your certificate store, your update payload limit and your radio MTU, and check them against a signature of about 3.3 KB instead of 64 bytes. If any of them is sized exactly to today's numbers, add headroom while the numbers are still soft.

4. Ask your vendors in writing. Your secure element, your MCU crypto accelerator, your TLS library, your bootloader. Ask whether they support ML-KEM and ML-DSA, on which parts, and on what schedule. A vendor with no answer is a risk you should be tracking in the SBOM, not just a component.

[KEY REQUIREMENT] Steps two and three are the ones with a deadline. Everything else can be revisited in firmware. Silicon and flash layout cannot.

The new algorithms, in plain terms

Four standards matter. Everything here is final, not a candidate.

A few things worth knowing that are easy to get wrong.

ML-KEM only agrees on keys. It never signs anything. If a supplier says their product is "Kyber-secured" and the only cryptography in the boot path is signature checking, that claim describes nothing.

The LMS and XMSS catch is state. Each key can only sign a given message slot once, and your signing infrastructure has to remember which slots it used. If it ever forgets, security is lost. That is a manageable problem in a controlled build server and a bad idea anywhere else. In exchange you get a very conservative security assumption, which is why it is attractive for firmware.

SLH-DSA is the pessimist's choice. It relies only on hash functions, which is about as small a security assumption as exists, and it is big and slow to sign. Verification is cheap, which is the direction that matters for a device.

Why size is the real engineering problem

The surprise for most teams is that the math is fast. Lattice operations often run quicker on a Cortex-M than the elliptic-curve arithmetic they replace. The cost shows up in bytes.

Three practical effects follow.

Your BLE pairing changes shape. A handshake that used to fit in a couple of packets now fragments across many. That affects pairing time, reliability in a noisy hospital, and battery draw. Measure it on real hardware over the real radio before you commit, because the number on a bench with a clean channel is not the number in a ward.

Your certificate store may not fit. Teams size that flash region against ECDSA and never revisit it. A post-quantum chain can be an order of magnitude larger.

Your update path pays twice during the transition. The common approach is to sign an image with both a classical and a post-quantum signature so it verifies either way. That is the safe path, and it means carrying both sizes at once.

What is coming, and when

Three schedules get quoted at you. Only one of them actually governs your device, and mixing them up is the most common error we see in submissions and in supplier claims.

Work the third row backwards, because that is the argument that lands. Clear a device in 2027 with a fifteen-year supported life and it is in clinical use in 2042. Classical public-key cryptography is scheduled to be disallowed seven years before that. You do not need a prediction about quantum computers to see the gap, because the retirement is already on a calendar.

Two more things are moving. NIST picked HQC in March 2025 as a backup key-agreement algorithm built on different math from ML-KEM, so a weakness in lattices does not leave the industry with nothing. FN-DSA, formerly Falcon, is in draft as FIPS 206 and is appealing when signature size dominates, though it is genuinely hard to implement safely in constant time. Neither changes what you should do this quarter.

What is not coming is quantum key distribution. It needs dedicated physical infrastructure, does not solve authentication, and has no place in a portable or implanted device. The NSA does not recommend it for protecting transmissions in national security systems either.

What to write in the submission

The FDA does not mandate ML-KEM. No guidance names a post-quantum algorithm, and anyone telling you otherwise has not read the February 3, 2026 final premarket cybersecurity guidance.

What the guidance does expect is that the controls you claim provide the protection you claim, for as long as you say the device is supported, and that your risk assessment reflects a realistic threat environment. That is where this topic enters. A device whose confidentiality and authenticity rest entirely on elliptic curves, with a twenty-year supported life and no way to change algorithms, has a control set that does not cover the period claimed. That is an answerable question, not a philosophical one.

Four things belong in the file:

• The cryptographic inventory. The table from step one. Few submissions include one, and it makes everything else assessable.
• An agility statement in the architecture section. How an algorithm gets replaced in the field, what that takes, and what limits it.
• A threat model row. Long-horizon confidentiality and signature forgery as the consequences, with service life as the reason behind your control decision.
• A dated position. Not necessarily a shipped implementation. A written, dated plan tied to service life is defensible. Saying nothing is not.

[KEY REQUIREMENT] Do not claim quantum resistance you have not built. "Quantum-safe because we use AES-256" describes symmetric strength while leaving key agreement and signing untouched, and that kind of imprecision turns into a deficiency letter.

Designing so you can change your mind later

Cryptographic agility gets used loosely enough to mean nothing. For a device it is five concrete properties.

The algorithm is chosen by data, not by a hardcoded call. An identifier in the protocol or the image header selects the operation.

The verification key can be replaced or joined. Either the root key lives somewhere updatable under its own authenticated process, or you provision more than one anchor at manufacture.

There is headroom. Buffers, flash regions, certificate stores and payload limits sized for the bigger artifacts.

The crypto library can be swapped. A statically linked, unversioned vendor stack with no roadmap is a risk item, not just a component.

Negotiation fails loudly. When the two ends disagree, you get a defined, logged failure, not a quiet drop to the weaker option.

The pattern the wider internet is deploying is hybrid: run a classical and a post-quantum algorithm together and derive the session key from both, so the result is no weaker than the better of the two. Browsers and servers already do this with X25519 and ML-KEM-768. For devices it is usually the right transition position, with the caveat that you pay both size costs at the same time.

If you want a sequence rather than a list, this is the order, sorted by how hard each decision is to reverse: inventory, trust anchor, signing, sizing, hybrid key agreement, AES-256, then write the position down.

Devices already in the field

For a device already shipping, the honest answer is usually that migration is not available, and the work is compensating controls plus a clear end-of-life position.

Two questions decide it. Can the device receive a signed update at all, and can that update change algorithms? If yes, this is a scheduling problem. If no, the cryptography is fixed for the rest of the device's life, and the response belongs in the postmarket plan rather than the engineering backlog: network protections where the device is deployed, a written statement of the residual risk, and an end-of-support date that accounts for the cryptography rather than only the hardware.

That connects directly to the end-of-life communication the FDA expects. See legacy medical device cybersecurity for how to frame it, and postmarket cybersecurity monitoring program for where it lands operationally.

Related depth:

• FDA Section 524B cybersecurity requirements explained - the statutory obligations behind all of this.
• The MedTech cybersecurity standards decoder - where the cryptographic standards sit among the rest.
• SBOM for medical devices - your crypto libraries are SBOM components with a roadmap question attached.
• Medical device cybersecurity SPDF playbook - where the migration plan lives in the development framework.
• Q-Day is a present-day FDA compliance gap - the shorter argument for why this is a submission issue now.

How Blue Goat Cyber approaches post-quantum readiness

We start with the inventory, because every other conversation is guesswork without it. That means reading the firmware and the protocol traces rather than taking the architecture document at its word, since what a device actually negotiates and what the design document says it negotiates differ often enough to be worth checking every time.

From there we look at agility: whether the trust anchor can ever accept a new key, whether the update path can carry a bigger signed image, whether the certificate store has room, and whether the libraries in your SBOM have a path forward. Findings come back in service-life terms, so you get a dated argument a reviewer can follow rather than generic advice to adopt post-quantum cryptography.

The output lands inside the package you are already building. The inventory becomes a submission artifact, the agility argument goes in the architecture section, and long-horizon exposure becomes threat model rows scored like every other risk. Our FDA cybersecurity services cover the submission-side work, and testing verifies the controls behave the way the document says they do.

Frequently asked questions

Does the FDA require post-quantum cryptography?

No. No FDA guidance names a post-quantum algorithm as a requirement. The February 3, 2026 final premarket cybersecurity guidance expects controls adequate for the device's supported lifetime and a risk assessment that reflects a realistic threat environment. For a long-lived device, that is what makes agility and a written transition position worth having in the file.

What should we actually do first?

Write the cryptographic inventory, then answer whether your trust anchor can ever hold a second key. The inventory takes a few days and gets reused in the submission. The trust anchor question has a hardware deadline, because once the part is fabricated the answer is permanent. Sizing and vendor roadmaps come next, and none of it requires choosing an algorithm yet.

Should we ship ML-KEM now or wait?

For most programs, hybrid key agreement is the right position and agility is the priority. Shipping a post-quantum algorithm on a device that can never change algorithms is worse than shipping a classical one on a device that can. Get the trust anchor, the sizing and the update path right, and the algorithm choice becomes something you can revisit later.

How much bigger are the keys and signatures?

Enough to matter. An ML-DSA-65 signature is about 3.3 KB against 64 bytes for ECDSA P-256, and ML-KEM-768 moves roughly a kilobyte in each direction against 32 bytes for X25519. On a constrained microcontroller or a BLE link that changes the handshake, the update payload and the flash budget, which is why sizing belongs before design freeze.

Does CNSA 2.0 apply to our medical device?

Only if you sell into national security systems. It is the NSA's algorithm suite for those systems, not an FDA requirement. It is still worth reading, because it puts firmware and software signing first, which is the right ordering for devices too, and because it drives the roadmaps of the chip and library vendors you depend on.

We are a software-only device. Does any of this apply?

Yes, with more freedom to act. Software as a medical device has no silicon trust anchor problem, so this is a dependency and deployment exercise rather than a hardware decision. The questions are which TLS stack you use, whether your hosting supports hybrid key agreement, how your code signing works, and how long the patient data you retain stays sensitive.

Ready to assess your cryptographic position?

If your device is supported past 2035, your cryptographic inventory and agility argument belong in the submission now. We can build both and write them in the service-life terms a reviewer evaluates. Talk to us about your device.