PQC Readiness Vendors for Hospitals: Who Covers Each Step

Which vendors help hospitals prepare for post-quantum cryptography?

Hospitals prepare for post-quantum cryptography (PQC) with six kinds of vendors: cryptographic discovery and inventory, PKI and certificate lifecycle, medical device manufacturers, PQC-capable gateways and tunnels, medical device visibility, and network segmentation. No single vendor covers all six, and only the manufacturer can change the cryptography inside a medical device.

The examples below come from each vendor’s own pages as of November 2026. They are examples, not a ranking or an endorsement.

The order matters more than the brand: inventory first, then the decisions the inventory makes possible.

Why is PQC readiness harder for hospitals than for other enterprises?

PQC readiness is harder for hospitals because patient data stays sensitive for decades, medical devices change on their manufacturers’ schedule rather than the hospital’s, and clinical systems can’t go down for a migration window.

• Long confidentiality life (harvest now, decrypt later). A patient record stays sensitive for the patient’s lifetime, and genomic data also reveals relatives. Traffic protected with quantum-vulnerable key exchange can be recorded today and decrypted once a cryptographically relevant quantum computer exists, so the exposure starts now.
• Devices on manufacturer validation cycles. In a study of more than 2.5 million devices across more than 50 healthcare delivery organizations, Forescout reported (October 6, 2026) that only 6% of IoMT devices and 16% of OT devices used SSH implementations supporting PQC, compared with 50% of IT devices. It also found that only 31% of the internet-exposed healthcare systems it identified support TLS 1.3, which Forescout notes is the only TLS version capable of supporting standardized PQC.
• Clinical uptime. An infusion pump server or a PACS interface can’t go offline for a weekend cutover. Every change, including a segmentation policy or a gateway hop, needs clinical engineering involved and a tested rollback.

Regulation points the same way. The HIPAA Security Rule proposal published January 6, 2025 would require a regulated entity “to conduct and maintain an accurate and thorough written technology asset inventory and a network map of its electronic information systems and all technology assets that may affect the confidentiality, integrity, or availability of ePHI” (HHS, Federal Register). It is a proposed rule; as of November 1, 2026 the Federal Register lists no final version.

What should a hospital do to prepare for quantum risk to patient data?

A hospital should prepare for quantum risk to patient data in six steps: build an inventory that includes manufacturer attestations, rank systems by data lifetime and clinical criticality, open an exception register with replace-by dates, segment devices that can’t migrate to the clinical systems they need, tunnel patient-data flows that leave the segment through a PQC-capable gateway, and put the replacements in the capital plan.

How do you build a cryptographic inventory in a hospital?

Build a hospital cryptographic inventory from three sources: a discovery tool for servers, applications and cloud; the medical device inventory from clinical engineering or an IoMT visibility tool; and a written statement from each manufacturer about the device’s cryptography and PQC plans. NIST’s NCCoE describes the same first move: find where quantum-vulnerable public-key algorithms are used in hardware, software and services, then build a prioritized roadmap (NIST NCCoE, Migration to PQC). Prefer passive collection on clinical networks. Active probes can disrupt older medical devices, so test any scan on a spare unit first and run it only with clinical engineering’s approval, in an agreed window.

How should a hospital rank systems for PQC migration?

Rank systems for PQC migration on two scores: how long the data they carry must stay confidential, and how critical the system is to patient care. The EHR, exchange interfaces, imaging archives and genomic data usually rank highest on data lifetime. Devices that verify firmware with quantum-vulnerable signatures rank high on safety, because a forged update is a patient-safety risk. Record key exchange and signatures as separate lines; they have different fixes. Record flows with no encryption at all, such as cleartext HL7 or DICOM inside the network, as their own line; they’re exposed today, not after a quantum computer arrives.

What goes in a PQC exception register for medical devices?

A PQC exception register for medical devices records, for each model: the owner (usually clinical engineering), algorithm and use, data lifetime, why it can’t migrate, compensating controls with their IDs, the manufacturer’s roadmap letter, a review date and a replace-or-retire-by date. Our legacy-systems guide has an infusion pump example. An entry without a replace-by date is a permanent exception.

Which medical devices should a hospital segment for quantum risk?

Segment every medical device that can’t migrate to PQC so it reaches only what it needs: its device server or central station, the interface engine, alarm and messaging middleware it sends alerts to, core services such as DHCP, DNS and NTP, its vendor’s controlled support path and its gateway. CISA wrote about operational technology, not medical devices, but the reasoning carries over to long-lived clinical and building systems: “Entities should prioritize network segmentation for legacy OT, end-of-life software, and platforms that require extensive time to apply updates” (CISA, Post-Quantum Considerations for Operational Technology, October 2024). Canada’s Cyber Centre says that for systems that can’t migrate, “it may be necessary to isolate such systems on the network or to tunnel traffic within a PQC-protected encapsulation layer” (ITSM.40.001, June 2025).

Start enforcement with low-risk device classes such as phones and printers, and move to medical devices once the process is proven. Simulate each medical-device policy against observed traffic long enough to catch its rare flows: overnight jobs, drug-library and firmware updates, preventive maintenance and vendor support sessions. Agree on the enforcement window and rollback with clinical engineering, and prefer an approach where rollback means withdrawing a policy, not re-addressing or re-cabling.

Which patient-data flows need a PQC-capable tunnel?

Patient-data flows that leave the device’s segment, or cross networks you don’t control, need a PQC-capable tunnel or gateway: links to remote clinics, health information exchanges, cloud services and outsourced reading. Place the gateway as close to the device as you can, and get the manufacturer’s written agreement before putting anything inline with a medical device. Neither the gateway nor segmentation fixes a signature the device verifies; the gateway and segmentation architecture explains how they fit together.

How should PQC readiness show up in a hospital’s budget?

PQC readiness should show up as separate budget lines: discovery tooling, PKI changes, gateways, segmentation work, register upkeep and device replacement, which usually sits in clinical engineering’s capital plan. For the whole PQC program, Gartner says that “currently Gartner’s best estimate is that this is a multiyear effort between now and 2030, with an expected budget impact between 1% and 5% of the total IT budget” (Gartner research (Elisity reprint), September 17, 2026). The 2027 budget guide breaks the lines down.

What should hospitals ask medical device manufacturers about post-quantum cryptography?

Hospitals should ask each medical device manufacturer, in writing, which cryptography the device uses for key exchange and firmware signatures, when a PQC-capable version will exist, and when support for the current version ends. Section 524B of the Federal Food, Drug, and Cosmetic (FD&C) Act requires a sponsor of a cyber device to “provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components” and to “make available postmarket updates and patches to the device and related systems” (21 U.S.C. 360n-2). FDA’s current guidance is Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, final, February 2026.

An SBOM lists software components; it doesn’t by itself tell you which algorithm protects a key exchange or signs the firmware. Ask for that directly, or for a CBOM where the manufacturer can produce one. Section 524B applies to premarket submissions; it does not reach back to devices already cleared and in service.

1. Algorithms in use: which algorithms protect key exchange, TLS or SSH sessions, and firmware or software signatures?
2. PQC roadmap: is there a version that supports the NIST PQC algorithms (FIPS 203, 204 and 205), and when will it be available for this model?
3. End of support: when does security support for this model end?
4. Update path: can the device accept new firmware signed with a new algorithm, or is the verification key fixed in hardware?
5. Network needs: which hosts, ports and directions does the device need, so you can write a segmentation policy that won’t break it?

Start from the manufacturer’s Manufacturer Disclosure Statement for Medical Device Security (MDS2), which clinical engineering may already hold, and ask the PQC questions it doesn’t answer. Put the dates into purchase agreements. The medical device security guide covers the groundwork.

How should a hospital evaluate PQC readiness vendors?

Evaluate PQC readiness vendors on demonstrated coverage in your own environment, not on a “quantum-ready” label. Run a bounded proof of value against representative clinical systems.

Where does Elisity fit in hospital PQC readiness?

Elisity fits in two rows: medical device visibility, through Elisity Quantum Posture, and segmentation, as a compensating control for medical devices and other systems that can’t migrate to post-quantum cryptography. It is not an encryption tool. Elisity is a security platform for users, devices, workloads and AI agents. Its IdentityGraph builds each device’s identity from network observations plus identity, endpoint, CMDB, IoT and cloud tools, so it can draw on IoMT inventories you may already run, such as Claroty xDome (Medigate), Armis or Asimily, and a ServiceNow CMDB. Insights powered by Elisity Intelligence recommend policy, you simulate it against observed traffic, and the Dynamic Policy Engine enforces administrator-approved policy at supported enforcement points in your existing network infrastructure, anywhere on the asset’s traffic path, from where a device connects to the data center or cloud application it talks to. No software agent runs on the protected devices, and supported deployments need no new appliances or re-IP.

Quantum Posture classifies the assets, internal services and external services Elisity observes on the network as quantum vulnerable, quantum ready or quantum safe, and labels the rest insufficient evidence, so devices that use quantum-vulnerable cryptography and can’t migrate can be segmented first. It sees the cryptography in observed traffic, not the keys or signing schemes inside device firmware, so manufacturer attestations are still needed. Elisity enforces allow-or-deny network policy and does not encrypt, decrypt or alter traffic, so it does not protect permitted traffic from harvest now, decrypt later and does not fix a forged firmware signature. Those jobs belong to discovery tools, PKI platforms, PQC-capable gateways and device manufacturers. The Virtual Edge sits outside the traffic path, so Elisity adds no hop between a device and its gateway. Enforcement depends on supported infrastructure. To control who can reach a medical device’s link to its gateway, an enforcement point has to sit between the device and the gateway. If the device’s own switch isn’t a supported enforcement point, Elisity still enforces further along the path, such as at the data center or cloud application the device talks to, but traffic that stays on that switch, or passes directly between two clients of one wireless access point, isn’t controlled.

St. Luke’s University Health Network completed its major segmentation groups across 15 hospitals in 46 days with Elisity, after about a month of infrastructure preparation, without major outages. That is a segmentation rollout, not a PQC result. See Elisity for healthcare or explore the Elisity platform, and validate enforcement point models, software versions, failover and rollout effort in a proof of value.

In October 2026, IonQ announced an agreement to acquire Elisity, with closing expected in the fourth quarter of 2026.

Frequently asked questions

Which vendors help hospitals prepare for post-quantum cryptography?

Hospitals usually need several kinds of vendor together: discovery vendors such as IBM, Keyfactor and SandboxAQ find quantum-vulnerable cryptography; PKI vendors such as DigiCert and Keyfactor manage certificates; device manufacturers change firmware and signatures; gateway vendors such as QuSecure protect patient-data flows; IoMT visibility vendors such as Forescout and Claroty inventory devices, and Elisity Quantum Posture classifies observed assets as quantum vulnerable, ready or safe; and segmentation vendors, including Elisity, restrict which systems can reach devices that can’t migrate but do not encrypt traffic.

Does microsegmentation protect patient data from quantum attacks?

Not on its own. Microsegmentation limits which systems can reach a medical device and blocks lateral movement, but it encrypts nothing. Traffic on paths it permits can still be recorded today and decrypted later, and a device that verifies firmware with a quantum-vulnerable signature still accepts a forgery. Pair segmentation with a PQC-capable gateway for flows that leave the segment and a manufacturer replacement date.

Can medical devices be upgraded to post-quantum cryptography?

Some can, through new manufacturer firmware; others can’t, because the processor is too limited or the verification key is fixed in hardware. The starting point is low: Forescout reported in October 2026 that only 6% of IoMT devices it studied already used SSH implementations supporting PQC. Only the manufacturer can say which models will get PQC support and when.

Does the FDA require post-quantum cryptography in medical devices?

Section 524B of the FD&C Act does not name post-quantum cryptography. It requires sponsors of cyber devices to provide a software bill of materials, to monitor and address postmarket vulnerabilities, and to make updates and patches available. Check FDA’s February 2026 premarket cybersecurity guidance for its cryptography recommendations, and ask each manufacturer for its PQC roadmap directly.

What does Elisity do for hospital PQC readiness?

Elisity does two jobs and does not encrypt traffic. Elisity Quantum Posture classifies the assets and services Elisity observes on the network, including medical devices, as quantum vulnerable, quantum ready or quantum safe. Elisity microsegmentation then limits which systems can reach medical devices that can’t migrate, enforced at supported enforcement points in your existing network infrastructure. Elisity does not encrypt, decrypt or alter traffic, and it doesn’t replace manufacturer attestations for cryptography inside device firmware.

How much should a hospital budget for PQC readiness?

Gartner estimates the overall PQC program as a multiyear effort through 2030 with a budget impact between 1% and 5% of the total IT budget. Split it into discovery, PKI, gateways, segmentation, register upkeep and device replacement, which usually sits in clinical engineering’s capital plan.

Sources

• Forescout, Post-Quantum Cryptography in Healthcare (press release), October 6, 2026.
• HHS, HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (proposed rule), Federal Register, January 6, 2025.
• US Code, 21 U.S.C. 360n-2, Ensuring cybersecurity of devices (FD&C Act section 524B).
• FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, final guidance, February 2026.
• CISA, Post-Quantum Considerations for Operational Technology, October 2024.
• Canadian Centre for Cyber Security, ITSM.40.001, Roadmap for the migration to post-quantum cryptography for the Government of Canada, June 2025.
• NIST National Cybersecurity Center of Excellence, Migration to Post-Quantum Cryptography.
• Gartner, CISO Agenda Priority: Transition to Postquantum Cryptography Before It’s Too Late (And Too Expensive), Mark Horvath, Sarah Almond, Thomas Lintemuth, September 17, 2026 (Elisity reprint).
• Vendor pages cited for examples, accessed November 1, 2026: IBM Quantum Safe; Keyfactor and IBM Consulting joint solution (January 22, 2026); SandboxAQ FedHealthIT award release (April 13, 2023); DigiCert healthcare security; DigiCert Quantum Central; Medcrypt (September 10, 2025); PQShield healthcare; QuSecure hospital systems; Claroty healthcare.

Gartner does not endorse any vendor, product or service depicted in its research publications. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.