up:: In the Protocols MOC

PQC in Medical Devices

Medical device PQC is the work of getting post-quantum cryptography into pacemakers, insulin pumps, infusion systems, imaging machines, and the hospital network gear around them, on a class of hardware that often stays in a patient or a clinical setting for a decade or more and can be slow or impossible to update. A medical device uses cryptography for the same jobs anything else does: authenticating firmware updates so only the manufacturer’s code runs, protecting the confidentiality and integrity of patient data in motion, and proving the device’s identity on a network.

Those jobs lean on the same classical public-key algorithms a quantum computer breaks, and the device lifetime is what turns that into a real problem, because a pacemaker implanted this year is meant to keep working past the 2035 deadline NIST has set for disallowing classical public-key cryptography. The FDA’s 2023 premarket cybersecurity guidance, and its statutory requirement for a software bill of materials, are the levers that make the exposure visible and the migration accountable.

The short version:

• Medical devices use classical public-key cryptography (RSA, ECC) to sign firmware, authenticate to networks, and protect patient data, and those algorithms are broken by Shor’s algorithm.
• The lifetime is the problem. Implantables and capital equipment routinely stay in service 10 years or more, so a device fielded today can outlive NIST’s 2035 disallowment of classical public-key algorithms while running on hardware that’s hard to patch.
• The most urgent surface is firmware code signing, because a quantum-forged update signature lets an attacker install malicious firmware on a life-sustaining device, and firmware roots of trust are among the longest-lived cryptography in the whole system.
• The FDA’s September 2023 premarket cybersecurity guidance operationalizes section 524B of the FD&C Act, which requires a software bill of materials for “cyber devices” in marketing submissions, and that SBOM is the natural home for a cryptographic bill of materials.
• A CBOM is what makes a hospital’s or a manufacturer’s exposure legible, turning “which of our devices use RSA-2048 and can’t be updated” from an unanswerable question into an inventory.

Picture a hospital full of safes that each open with a specialized key, and the locksmith who made them is the only one trusted to change the combination. Some safes were installed 15 years ago and are welded into the wall; some are new and can be re-keyed remotely. You learn that a master key will eventually exist that opens any safe of this design. You can re-key the new ones over the network, but the old welded ones can only be changed by physically replacing them, which means surgery in the case of an implant. Knowing which safes are which, and which ones can still be re-keyed, is the entire planning problem, and that inventory is exactly what a cryptographic bill of materials gives you.

What cryptography do medical devices actually use?

Medical devices use cryptography for three jobs, and each rests on a mix of symmetric and public-key algorithms, with the public-key half carrying the quantum exposure. The specific primitives vary by device class, and the pattern holds across implantables, bedside equipment, and networked hospital systems.

1. Firmware and update authentication. Before a device installs new firmware, it verifies a digital signature to confirm the code came from the manufacturer and wasn’t tampered with. This is code signing, and it’s typically RSA or ECDSA today. It’s the security property that keeps an attacker from loading malicious firmware onto a device that controls a heart rhythm or a drug dose.
2. Data protection in motion. Patient telemetry, device readings, and remote-monitoring streams are protected with TLS or a similar protocol, whose key exchange is classical ECDH or RSA key transport, wrapped around a symmetric AES channel.
3. Device and network identity. A device authenticates to a hospital network, a manufacturer’s cloud, or a programmer using certificates and signatures, again resting on classical public-key algorithms.

Source: NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016 (RSA and elliptic-curve public-key algorithms fall to a quantum computer; symmetric algorithms need only larger keys), csrc.nist.gov.

The split to hold onto is the same one that governs every PQC migration. The symmetric AES that protects the bulk data only faces Grover’s algorithm and stays strong with a 256-bit key, while the public-key signatures and key exchanges are what Shor’s algorithm breaks outright. The work is on the public-key layer, and in medical devices the firmware-signing part of it is the sharpest.

Why does the long device lifetime make this urgent?

Because the cryptography baked into a device at manufacture has to keep protecting it for the device’s entire service life, and that life routinely runs past the point where the underlying algorithms are disallowed. Implantable devices such as pacemakers and defibrillators, and capital equipment such as imaging systems and infusion platforms, commonly stay in service 10 years or more, often 15. A device implanted or installed this year therefore has to remain trustworthy past NIST’s 2035 disallowment of classical public-key algorithms, and in many cases well beyond it.

Source: NIST IR 8547 (Initial Public Draft), “Transition to Post-Quantum Cryptography Standards,” November 2024 (classical public-key algorithms deprecated after 2030 and disallowed after 2035), csrc.nist.gov.

The device classes span a wide range of lifetime and update capability, and that spread is what shapes the migration:

Device class	Typical service life	Update path	Migration difficulty
Implantable (pacemaker, defibrillator)	10 or more years	Sometimes over-the-air; otherwise replacement via surgery	Highest, because the un-updatable units can only be migrated by explant
Capital equipment (imaging, infusion)	10 to 15 years	Vendor firmware update where supported	High, gated by vendor roadmap and validation cycles
Bedside / networked monitor	5 to 10 years	Usually patchable over the network	Moderate, closer to standard IT migration
New device in development	Sets the next decade	Designed-in agility and secure update	Lowest, if agility is engineered up front

Two properties turn the long life into a genuine bind:

1. The update path is constrained or absent. Some modern devices can receive a secure over-the-air firmware update, which is how St. Jude Medical (now Abbott) delivered a cybersecurity firmware patch to hundreds of thousands of pacemakers in 2017. Many devices in the field, especially older implantables and deeply embedded controllers, either cannot be updated remotely or require a clinical visit or physical replacement, which in the case of an implant means a surgical procedure. That makes a later algorithm swap far harder than a server-side library upgrade.
2. The forge-later exposure is real for firmware. A code-signing key that a quantum computer recovers lets an attacker forge a valid firmware update long after the device shipped, so the signing surface is a forge-later target across the device’s whole life. Where patient data is stored or transmitted with long confidentiality requirements, the harvest-now-decrypt-later clock also applies, because health records retain their sensitivity for decades.

So the urgency is a lifetime problem before it’s a threat-timeline problem. Even if a cryptographically relevant quantum computer is years out, the devices being designed and fielded now are the ones that will still be running when it arrives, which is why post-quantum readiness belongs in current device design rather than a future refresh.

What is the FDA’s role and what does the 2023 guidance require?

The FDA is the regulatory lever, and its 2023 guidance plus the underlying statute turn medical device cybersecurity, including cryptographic hygiene, into a condition of market authorization rather than a voluntary practice. On 27 September 2023 the FDA issued final guidance titled “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions,” which superseded its 2014 premarket cybersecurity guidance and set out what manufacturers must include in marketing submissions to demonstrate a device is reasonably secure.

Source: FDA, “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions,” final guidance, 27 September 2023, fda.gov.

The guidance operationalizes section 524B of the Federal Food, Drug, and Cosmetic Act, “Ensuring Cybersecurity of Medical Devices,” which Congress added in the Consolidated Appropriations Act, 2023. Two elements of that statutory scheme matter most for the quantum transition:

1. A software bill of materials is mandatory for cyber devices. Section 524B(b)(3) requires a device maker to provide an SBOM in the marketing submission for a “cyber device,” listing the software components in the device, including commercial, open-source, and off-the-shelf software, together with support and end-of-support information. This is a legal requirement, so producing the inventory is a gate the marketing submission has to clear.
2. Lifecycle security planning is required. The guidance expects a manufacturer to plan for monitoring, identifying, and addressing vulnerabilities across the device’s supported life, which is exactly the frame a cryptographic-agility plan for the quantum transition fits inside.

Source: FDA / U.S. Congress, section 524B of the FD&C Act as added by the Consolidated Appropriations Act, 2023 (SBOM required for cyber devices in marketing submissions), fda.gov.

The consequence for PQC is that the accountability structure already exists. A manufacturer that must inventory its software and plan lifecycle security is one step from inventorying its cryptography and planning its post-quantum migration, and the SBOM mandate gives that work a compliance hook rather than leaving it to good intentions.

Why does a CBOM matter specifically here?

Because migrating cryptography depends on first seeing it, and a medical device fleet is one of the hardest environments in which to see it: many devices, many vendors, many firmware versions, and a wide spread of update capability. A cryptographic bill of materials extends the software-inventory idea down to the algorithm level, recording which algorithms, key sizes, certificates, and protocols each device actually uses. In healthcare that inventory answers the questions the migration turns on.

1. Which devices use quantum-vulnerable algorithms? The CBOM surfaces every device signing firmware with RSA or ECDSA and every device negotiating classical key exchange, which is the population that needs a plan.
2. Which of those can be updated, and which can’t? Pairing the crypto inventory with each device’s update capability separates the fleet into the units that can receive a post-quantum firmware update and the units that can only be migrated by replacement. That split is the core of the sequencing.
3. What’s the exposure to a board, an auditor, and the FDA? A CBOM makes the fleet’s cryptographic posture legible to the people who have to sign off on risk, and it aligns naturally with the SBOM the FDA already requires, so the crypto inventory rides on top of an artifact the manufacturer is producing anyway.

The FDA’s SBOM requirement is the wedge that makes the CBOM practical. A manufacturer building the mandated software inventory is positioned to record the cryptographic details in the same pass, and a hospital receiving SBOMs from its vendors can aggregate them into a fleet-wide view. The CBOM note covers the artifact in depth; in the medical setting its value is that it converts an opaque, multi-vendor device population into a sequenced migration plan.

How does a medical device migrate to post-quantum cryptography?

The migration follows the same shape as every PQC transition, prioritized by exposure and gated by what each device can physically accept, with firmware signing at the front. The order is set by which surface is most dangerous and which cryptography is most permanent.

1. Harden firmware and code signing first. The firmware root of trust is the longest-lived and highest-consequence cryptography in the device, so it migrates first. For firmware signing specifically, the stateful hash-based signatures LMS and XMSS from NIST SP 800-208 are often the right tool, because they’re conservative and well-suited to a small number of firmware releases, an approach covered in PQC in Firmware and Code Signing. General-purpose signing moves to ML-DSA.
2. Migrate key exchange and identity for networked devices. Devices that talk to a hospital network or a manufacturer cloud move their TLS key exchange to a hybrid post-quantum group and their identity certificates onto post-quantum signatures over time, the same protocol work described in the protocols hub.
3. Design new devices for agility. Devices entering development should be built so their algorithms are a configurable choice and, where the hardware allows, so they can receive a secure post-quantum update, which is the crypto-agility that keeps a device fielded today from becoming the unpatchable long tail.
4. Sequence the legacy fleet by replaceability. The devices already in service, especially implantables and un-updatable equipment, are sequenced against their remaining service life and their update capability, with the ones that can only be replaced flagged as the multi-year hardware-refresh problem they are.

The realistic framing is that this is a lifecycle program measured in years, and the hardest part is the installed base of long-lived, hard-to-update devices. That’s why the leverage sits in current design decisions and in the inventory that tells you where the legacy exposure actually is.

Common misconceptions

1. “A pacemaker doesn’t do enough computing to be a quantum target.” The target isn’t the device’s compute, it’s the signing key that authorizes its firmware. A quantum computer that recovers a manufacturer’s code-signing key can forge a valid update for a life-sustaining device, regardless of how modest the device’s own processor is.
2. “We’ll just update the firmware when quantum arrives.” Many medical devices, especially implantables and older equipment, cannot receive a remote update, and updating an implant can mean a surgical procedure. The devices being fielded now are the ones that will still be running when a quantum computer exists, so the choice made at design time is the one that has to last.
3. “The FDA doesn’t require any of this yet.” Section 524B of the FD&C Act makes a software bill of materials a legal requirement for cyber devices in marketing submissions, and the 2023 guidance requires lifecycle security planning. The cryptographic inventory rides directly on top of an obligation manufacturers already carry.
4. “Encrypting patient data with AES handles the quantum problem.” AES only faces Grover’s algorithm and stays strong at 256 bits, so the bulk-encryption layer is fine. The exposure is the public-key signing and key exchange around it, which is where Shor’s algorithm applies.
5. “An SBOM already covers the cryptography.” A software bill of materials lists components, and it doesn’t record which algorithms and key sizes each component uses. A CBOM adds that layer, and it’s what actually tells you which devices are quantum-vulnerable and which of those can be updated.

Questions people ask

Is a pacemaker quantum-safe today? Generally no. Implantable and networked medical devices rely on classical RSA and elliptic-curve cryptography for firmware signing, identity, and data protection, and those algorithms are broken by Shor’s algorithm. Post-quantum migration is early, and the long device lifetime is what makes designing for it now important.

What’s the most urgent cryptographic surface in a medical device? Firmware code signing. A quantum-forged update signature lets an attacker install malicious firmware on a device that controls a heart rhythm or a drug dose, and the firmware root of trust is the longest-lived cryptography in the system, so it migrates first, often to the stateful hash-based signatures in PQC in Firmware and Code Signing.

Why does the device lifetime matter so much? Implantables and capital equipment routinely stay in service 10 years or more, so a device fielded today can outlive NIST’s 2035 disallowment of classical public-key algorithms while running on hardware that’s hard to patch. The cryptography chosen at design time has to hold for the whole service life.

What does the FDA require? The FDA’s September 2023 premarket cybersecurity guidance operationalizes section 524B of the FD&C Act, which requires a software bill of materials for cyber devices in marketing submissions and lifecycle security planning. That obligation is the hook a cryptographic-migration plan and a CBOM fit inside.

Why is a CBOM important for a hospital or manufacturer? A medical fleet spans many vendors, firmware versions, and update capabilities, so its cryptographic exposure is opaque without an inventory. A CBOM records which devices use quantum-vulnerable algorithms and which of those can be updated, which is what converts the fleet into a sequenced migration plan.

Can most medical devices be updated to post-quantum cryptography later? Some can, through secure over-the-air firmware updates, as the 2017 St. Jude pacemaker firmware patch showed. Many cannot, especially older implantables and deeply embedded systems, so the legacy fleet has to be sequenced by remaining service life and update capability, with un-updatable devices treated as a hardware-replacement problem.

Does this apply to hospital IT and imaging equipment as well as implants? Yes. Networked hospital equipment, imaging systems, and infusion platforms all use classical public-key cryptography for identity and data protection, and much of it has a long capital lifetime, so it belongs in the same inventory and the same sequenced migration as the implantables.

---

Everything here is the map, given freely. When your team needs its device fleet inventoried down to the algorithm, its firmware-signing surfaces migrated first, and its un-updatable long tail sequenced against 2035 and the FDA’s SBOM mandate, that’s the work I do. Request an alignment briefing.

Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.