Why post-quantum cryptography matters for implants: harvest now, forge later.
An implant is certified once and runs for a decade, well inside a realistic quantum window, and it usually cannot be recalled. Post-quantum identity with in-field rotation is how it migrates without a field action.
For post-quantum medical devices, and implants most of all, the cryptographic choices made at certification are frozen into hardware that cannot be called back. Records kept for years can be harvested now and read later; a classical device signature can be forged later.[2] The answer is post-quantum device identity with in-field key rotation, migrating a device to the NIST FIPS 203/204/205 baseline through a signed update.[4] RankShieldMD attests identity and integrity, non-device and PHI-free by design.
Certified once,
frozen for a decade.
The algorithms and trust anchors a device carries are fixed at design and validation time, and an implant cannot be recalled to change them.[2] Anything not built to update in the field is effectively frozen for the life of the device, which for an implant is a decade or more, well inside a realistic quantum window. If the only path to quantum-safe cryptography runs through a physical field action, for many devices that path does not exist. RankShieldMD works on device identity and posture, never on protected health information, and attests rather than renders, so it stays non-device.
Captured today,
read and forged later.
Two long-horizon risks share one root. Harvest-now, decrypt-later: encrypted long-retention records captured today, read once a quantum computer arrives. Forge-later: a classical device signature captured or modeled today, forged in that same future to impersonate a trusted device.[2] The long-horizon framing is directional, drawn from forward-looking preprint work, and we present it honestly as a planning assumption, not a settled fact. Either way the response is the same: move confidentiality and identity to post-quantum algorithms before the window closes. Quantum-safe, not quantum-proof.
FIPS 203, 204,
and 205.
NIST finalized the first federal post-quantum standards in August 2024.[4] FIPS 203 is ML-KEM, a key-encapsulation mechanism for confidentiality, answering harvest-now, decrypt-later. FIPS 204 is ML-DSA and FIPS 205 is SLH-DSA, the signature schemes that answer forge-later for identity and integrity. RankShieldMD can carry composite identities pairing a classical signature with a post-quantum one, so a device stays interoperable today while gaining quantum-safe assurance and a clear path to the standard. These are the algorithms a device line migrates toward.
Rotated in place,
no recall.
In-field key rotation turns a cryptographic upgrade from a physical action into a signed software event.[2] If a device can re-provision its identity credentials and trust anchors through an authenticated, integrity-checked update, migrating it to post-quantum algorithms never touches the hardware. The device verifies the rotation, adopts a quantum-safe identity in place, and the event is recorded as signed evidence a reviewer can inspect. RankShieldMD produces the identity and the record of its rotation as verifiable artifacts, and supports your migration rather than making a regulatory decision.
The device you ship today,
safe for its whole life.
Below: why a certified device can't be re-encrypted later, what harvest-now and forge-later mean, the NIST FIPS 203/204/205 baseline, how in-field rotation avoids a recall, and what device makers should decide at architecture time. Quantum-safe, not quantum-proof, PHI-free, non-device.
Why post-quantum cryptography matters for implants, in one paragraph.
Implanted and connected medical devices are rarely re-secured after certification and often cannot be recalled, yet they run for a decade or more, well within a realistic quantum window. Post-quantum identity with in-field key rotation lets a device migrate to quantum-safe cryptography without a recall.[2] That is the whole problem in a sentence, and it is why post-quantum medical devices are a design question rather than a future one. The cryptography a device carries is fixed when it is validated, and an implant compounds that constraint because there is no way to physically retrieve it. Two long-horizon risks follow: encrypted long-retention records harvested now and decrypted later, and classical device signatures forged later to impersonate a trusted device. The response is to move confidentiality and identity onto the NIST post-quantum standards finalized in August 2024, FIPS 203, 204, and 205, and to architect the device so that migration can happen through a signed, authenticated update rather than a field action.[4] That is where RankShieldMD works: it attests device identity and integrity, carries composite classical-plus-post-quantum credentials, and records each in-field rotation as verifiable evidence. It never renders, drives, or scores a clinical decision, so it stays non-device by design, and it works on device identities, credentials, and posture, never on protected health information, so it is PHI-free by construction.
It puts device makers ahead of where regulation is heading, not past a rule that already exists: the FDA today expects crypto-agility and migration planning and does not mandate post-quantum cryptography, so the honest framing is quantum-safe, not quantum-proof.
Why can't a certified medical device just be re-encrypted later?
Because the cryptography is validated into a device that has been through formal certification and, for an implant, often cannot be physically retrieved.
The algorithms, key sizes, and trust anchors a device carries are decided at design and validation time and then locked in, and changing them later is not a configuration tweak. It can mean re-opening the premarket submission and revalidating the functions that depend on the cryptography, which is exactly the friction that keeps aging devices on classical algorithms long after those algorithms have a visible expiry date.[2] An implant makes the constraint absolute rather than merely expensive. You cannot recall a device that is inside a patient, so anything not deliberately architected to be updated in the field is frozen for the working life of the device, and for an implant that life is a decade or more. Put those two facts together and the exposure is structural: a device shipped this year could still be running its original identity cryptography well into a period when a large enough quantum computer is a realistic assumption. If the only route to quantum-safe cryptography is a physical field action, for many devices that route simply does not exist, and the risk stays live for as long as the device does. That is why the migration path has to be designed in at the start rather than bolted on later. RankShieldMD works on device identities, credentials, and posture, never on protected health information, and it attests identity rather than driving any clinical function, so it stays non-device by design and never pulls a manufacturer across a regulatory line.
What is harvest-now, forge-later for medical devices?
It is two long-horizon risks with one root cause: cryptography that is safe today but not against a future quantum computer.
The first risk is harvest-now, decrypt-later. An adversary captures encrypted data today, stores it, and decrypts it once a sufficiently capable quantum computer exists, which matters in healthcare specifically because medical evidence and device logs are retained for years, so data encrypted now is still sensitive when the window opens.[2] The second risk is the signature side, which we call forge-later: a classical device signature that is captured, observed, or modeled today could, in that same future, be forged, letting an attacker impersonate a trusted device or fabricate a signed command, record, or firmware update that a verifier would accept as genuine. For a device whose entire trust model rests on a classical signature, forge-later is the more pointed exposure, because it is not about reading old data but about counterfeiting future authority. Both risks share a root: the cryptography protecting confidentiality and identity today is not designed to withstand a large quantum computer tomorrow. It is worth stating plainly that the long-horizon harvest-and-forge framing is directional, drawn from forward-looking preprint work rather than a settled or dated event, and we present it honestly as a planning assumption a prudent device maker adopts, not a prediction with a clock on it. The response does not change: move confidentiality and identity onto post-quantum algorithms before the window closes. RankShieldMD is non-device and PHI-free, and describes this as quantum-safe, not quantum-proof.
What are the NIST post-quantum standards FIPS 203, 204, and 205?
They are the first finalized US federal post-quantum standards, published by NIST in August 2024, and they are the baseline a device line migrates toward.
NIST finalized three post-quantum standards in August 2024, and each answers a different part of the problem.[4] FIPS 203 is ML-KEM, a module-lattice key-encapsulation mechanism used to establish shared secrets, and it is the confidentiality tool, the direct answer to harvest-now, decrypt-later, because data protected with a quantum-safe key exchange is not readable by a future quantum computer that captured the traffic. FIPS 204 is ML-DSA, a module-lattice digital signature algorithm, and FIPS 205 is SLH-DSA, a stateless hash-based signature scheme, and these two are the identity and integrity tools, the answer to forge-later, because a device that signs with a quantum-safe scheme cannot have that signature counterfeited by the same future machine. Having two signature families matters for defense in depth: ML-DSA rests on lattice assumptions while SLH-DSA rests on hash assumptions, so a device line is not betting everything on one mathematical foundation. In practice a device does not have to flip from classical to post-quantum in a single step. RankShieldMD can carry composite identities that pair a classical signature with a post-quantum one, so a device stays interoperable with today's infrastructure while already gaining quantum-safe assurance and a clean path to the standard as the ecosystem catches up. These are the algorithms a device line migrates toward, and RankShieldMD attests identity against them while remaining non-device and PHI-free by design.
How does in-field key rotation avoid a device recall?
It turns the cryptographic upgrade from a physical action into an authenticated, integrity-checked software event.
A recall is a physical process: retrieve or service the device, touch the hardware, replace what is inside. In-field key rotation replaces that process with a signed update. If a device is architected so its identity credentials and trust anchors can be re-provisioned through an authenticated, integrity-checked channel, then migrating it to post-quantum algorithms never requires physical access at all.[2] The device receives the new material, verifies that the rotation is authorized and that the payload is intact, adopts the quantum-safe identity in place, and continues operating, and the entire event is captured as a signed record a reviewer or auditor can later inspect and recompute. That signed record is the difference between a claim and evidence: rather than asserting that a fleet was migrated, a manufacturer can point to the sealed rotation event for each device and show exactly when its identity moved to the post-quantum baseline. The architectural requirement is the load-bearing part. A device that was never designed to rotate its trust anchors cannot be rescued by tooling after the fact, which is why the decision belongs at design time. RankShieldMD produces the device identity and the signed record of its rotation as verifiable artifacts, working on credentials and posture rather than protected health information, and it supports your migration rather than making any regulatory determination on your behalf, since that determination stays yours and the FDA's.
What should device makers decide at architecture time?
Whether the device can rotate its own trust anchors in the field, because that single decision determines whether a future migration is an update or a recall.
The most consequential post-quantum decision is not which algorithm to ship first, it is whether the device can change its cryptographic identity later without being touched.[2] A device architected for crypto-agility, with re-provisionable credentials, an authenticated update path, and room for larger post-quantum keys and signatures, can be migrated through a signed event years after it leaves the factory. A device that hardcodes a single classical trust anchor with no update path has, in effect, chosen a recall as its only future migration option, and for an implant that option may not exist. So the design-time checklist is concrete: plan for crypto-agility rather than a fixed algorithm; leave headroom for post-quantum key and signature sizes; build an authenticated, integrity-checked rotation path; and consider composite identities that pair a classical and a post-quantum signature so the device is interoperable today and quantum-safe as the ecosystem moves. It is also worth being honest about the regulatory posture: the FDA today expects crypto-agility and migration planning, and it does not mandate post-quantum cryptography, so a maker who designs for in-field rotation now is ahead of where regulation is heading, not past a rule that already exists. RankShieldMD attests device identity and integrity against the NIST baseline, records rotations as verifiable evidence, and stays non-device and PHI-free by construction. Quantum-safe, not quantum-proof.[4]
Where to go next.
Post-quantum identity for a device line
Composite classical-plus-post-quantum device identity and in-field key rotation, so a fleet can migrate to the FIPS 203/204/205 baseline without a recall.
Explore → PQC IN HEALTHCAREWhat quantum-safe means for healthcare
Harvest-now and forge-later explained for long-retention records and device identity, and how the NIST standards map onto a healthcare estate.
Explore → DEVICE SECURITYContain the device you can't patch
Compensating-control segmentation, verifiable posture, and residual-risk dossiers for unpatchable and end-of-life devices still serving patients.
Explore →What we are careful never to claim.
Quantum-safe, not quantum-proof
RankShieldMD moves device identity onto the NIST post-quantum standards. It says quantum-safe, never quantum-proof, and it puts a device line ahead of where regulation is heading, not past a rule that already exists.
The FDA doesn't mandate PQC yet
Today the FDA expects crypto-agility and migration planning, and it does not mandate post-quantum cryptography. RankShieldMD supports that planning and produces the evidence; it never makes you compliant or cleared.
It's device identity, not PHI
RankShieldMD works on device identities, credentials, signed rotations, and posture. It attests identity and integrity, never renders a clinical decision, and holds no protected health information, so it is non-device and PHI-free by construction.
References
- [2] npj Digital Medicine / Nature (2025). Quantum cryptography and data protection for medical devices before and after they meet Q-Day. nature.com/articles/s41746-025-02082-3
- [4] NIST (Aug 2024). FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA). nist.gov
- [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
Post-quantum implants: questions, answered.
Why does post-quantum cryptography matter for medical implants?
It matters because implants sit inside a realistic quantum window and are rarely re-secured. An implanted or connected device is often certified once, then runs for a decade or more without a fresh cryptographic review, and it usually cannot be recalled to swap its trust anchors.[2] A device whose identity rests on classical signatures alone could, in a future with a large enough quantum computer, have that identity forged. Post-quantum identity with in-field key rotation lets a device migrate to quantum-safe algorithms without a physical recall, so the device you shipped years ago can be moved to the FIPS 203/204/205 baseline through a signed update.[4] RankShieldMD attests device identity and integrity and is non-device and PHI-free by design. Quantum-safe, not quantum-proof, and ahead of where regulation is heading rather than past a rule that already exists.
Why can't a certified medical device just be re-encrypted later?
Because the cryptography is baked into a device that has been through a formal certification and often cannot be physically retrieved. The algorithms, key sizes, and trust anchors a device carries are fixed at design and validation time, and changing them can mean re-opening the submission and revalidating the affected functions.[2] An implant compounds this: you cannot call a device back that is inside a patient, so anything not designed to be updated in the field is effectively frozen for the life of the device. If the only path to quantum-safe cryptography is a recall, that path may not exist. RankShieldMD works on device identities, credentials, and posture, never on protected health information, and it attests identity rather than driving any clinical function, so it stays non-device by design.
What is harvest-now, forge-later for medical devices?
It is two long-horizon risks. Harvest-now, decrypt-later means an adversary captures encrypted long-retention records today and decrypts them once a quantum computer is available, which matters because medical evidence is kept for years.[2] Forge-later is the signature side: a classical device signature captured or modeled today could, in that same future, be forged, letting an attacker impersonate a trusted device or fabricate a signed command or record. The long-horizon framing is directional and drawn from forward-looking preprint work, and we present it honestly as a planning assumption rather than a settled fact. The response is the same either way: move confidentiality and identity to post-quantum algorithms before the window closes. RankShieldMD is non-device and PHI-free, and describes this as quantum-safe, not quantum-proof.
What are the NIST post-quantum standards FIPS 203, 204, and 205?
They are the first finalized US federal post-quantum standards, published by NIST in August 2024.[4] FIPS 203 is ML-KEM, a module-lattice key-encapsulation mechanism for establishing shared secrets, which addresses the harvest-now, decrypt-later problem for confidentiality. FIPS 204 is ML-DSA, a module-lattice digital signature algorithm, and FIPS 205 is SLH-DSA, a stateless hash-based signature scheme, both of which address the forge-later problem for identity and integrity. RankShieldMD can carry composite identities that pair a classical signature with a post-quantum one, so a device stays interoperable today while gaining quantum-safe assurance. These are the standards a device line migrates toward. RankShieldMD attests identity against them and remains non-device and PHI-free by design.
How does in-field key rotation avoid a device recall?
It moves the cryptographic upgrade from a physical action to a signed software event. If a device is architected so its identity credentials and trust anchors can be re-provisioned through an authenticated, integrity-checked update, then migrating it to post-quantum algorithms does not require touching the hardware.[2] The device authenticates the rotation, verifies the new material, and adopts a quantum-safe identity in place, and the whole event is recorded as signed evidence a reviewer can inspect. That is the difference between a field action and a routine update. RankShieldMD produces device identity and the signed record of its rotation as verifiable artifacts, working on credentials and posture rather than protected health information, and it supports your migration rather than making any regulatory decision on your behalf.
Is RankShieldMD a medical device, and does it touch patient data?
No on both. RankShieldMD attests device identity and integrity and never renders, drives, or scores a clinical decision, so it stays non-device by design. FDA classification turns on intended use, and attesting that a device is genuine is not the same as making a clinical determination. It also works only on device identities, credentials, signed commands, and posture evidence, never on protected health information, so it is PHI-free by construction. The device keeps doing its clinical job through its own systems; RankShieldMD proves the identity behind it and records the migration. It attests, it never renders. And on cryptography it says quantum-safe, not quantum-proof, and puts a device line ahead of where regulation is heading rather than past a rule that already exists, since the FDA today expects crypto-agility and migration planning and does not mandate post-quantum cryptography.
Make a device line quantum-safe without a recall.
Bring a device or a fleet. We'll show you post-quantum device identity, composite credentials your infrastructure still accepts today, and in-field rotation that migrates the device you already shipped through a signed update rather than a field action. Quantum-safe, not quantum-proof, PHI-free, non-device.