PQC for Healthcare

What PQC means in healthcare

Post-quantum cryptography (PQC) is cryptography based on mathematical problems that large-scale, fault-tolerant quantum computers are not expected to solve efficiently. It is the primary mitigation identified for the future threat to today’s asymmetric public-key cryptography. For healthcare, the scope includes systems that encrypt or exchange keys, systems that authenticate people and machines, and systems that create or validate digital signatures. That reaches well beyond a hospital’s perimeter: electronic health-record platforms, laboratory and imaging services, patient portals, telehealth, email and document signing, identity systems, software and firmware updates, medical devices, operational technology, remote access, network protocols, cloud services, and supplier-managed products.12

The transition also affects the implementation details beneath applications. Applications and services may need new algorithms for encryption, digital signatures, and key exchange; changes to key sizes and performance; updated protocols and libraries; refactored code; extensive testing; and, in some cases, redesigned interfaces. Healthcare architecture teams should therefore treat cryptography as a dependency that crosses software, infrastructure, device, and service boundaries.2

Why healthcare should plan now

The strategic concern is not limited to the date when a cryptographically relevant quantum computer becomes available. Information captured today may retain value long enough to be targeted for later decryption. The NIST transition draft says migration to quantum-resistant key-establishment schemes is expected to receive priority to protect against “harvest now, decrypt later” attacks, particularly in interactive protocols such as TLS and IKE. Healthcare organizations should consequently assess records, research, genomic information, identity data, contracts, and other information whose confidentiality horizon extends beyond the migration itself.2

Healthcare also has an integrity problem. A clinical system must be able to distinguish an authorized update, device, user, or service from a forged one. The inventory therefore needs to include systems involved in creating and validating digital signatures, including software and firmware updates. In connected operational environments, integrity can be more immediately consequential than confidentiality: faulty sensor readings or commands can contribute to control-system failures.31

The risk is distributed across the supply chain. Commercial products, cloud-hosted services, custom applications, older platforms, embedded devices, proprietary protocols, and equipment that cannot be physically or remotely upgraded may each follow a different schedule. The joint CISA, NSA, and NIST guidance recommends prioritizing high-impact systems, industrial control systems, and systems with long-term confidentiality or secrecy needs, while the NCSC highlights resource constraints, difficult servicing, non-upgradeability, embedded deployment, and immature protocol support as special challenges for industrial IoT devices.31

A practical healthcare migration workflow

A workable program is staged. First, establish a project-management team with representation from security architecture, infrastructure, application engineering, clinical technology, privacy and risk, procurement, legal, business continuity, and relevant suppliers. The team should define scope, decision rights, acceptable transition risk, and the relationship between PQC work and broader IT, operational-technology, and cyber-resilience modernization. The joint guidance specifically recommends establishing a quantum-readiness project team and beginning proactive discovery while standards and implementation details continue to develop.3

1. Discover cryptography in network protocols, endpoints, servers, applications, libraries, identity services, certificates, software and firmware signing, devices, and cloud dependencies.
2. Map each cryptographic dependency to the data, function, system owner, supplier, lifecycle state, exposure, and required confidentiality or integrity period.
3. Prioritize high-impact clinical and business services, long-lived sensitive information, remote access, PKI, signed updates, and assets whose failure could affect safety or continuity.
4. Engage product manufacturers, commercial-off-the-shelf suppliers, and cloud providers about supported algorithms, upgrade mechanisms, timelines, costs, testing responsibilities, and fallback behavior.
5. Design target states for protocols, applications, certificates, key establishment, signatures, hardware, firmware, and device replacement or compensating controls.
6. Pilot representative paths, test performance and interoperability, deploy in controlled waves, monitor actual negotiation and use, and retire traditional support only when evidence and dependencies permit.

Discovery should be more than a list of algorithm names. A useful inventory records where cryptography occurs and why it matters. It should expose relationships between outside access and datasets, identify quantum-vulnerable algorithms in network protocols and assets on end-user systems and servers, and support later risk analysis. For a healthcare organization, adding data-retention requirements, clinical criticality, device serviceability, and supplier ownership makes the inventory actionable rather than merely descriptive.23

Architecture considerations

Crypto agility is the architectural capability to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. This capability is especially valuable in healthcare because technology lifecycles differ: a cloud service, a patient-facing application, a bedside device, and a legacy laboratory instrument may not be upgradeable through the same mechanism. Separating cryptographic policy and interfaces from application logic, documenting algorithm and certificate dependencies, and maintaining controlled configuration paths can reduce the cost and disruption of later changes.4

Public-key infrastructure deserves explicit treatment. An enterprise PKI migration generally requires a new PQC root of trust and new PQC certificates for network entities; some devices may require physical interaction. A parallel PKI can operate alongside the traditional PKI during a staged migration, although a tightly controlled environment might move directly from one to the other. Protocols such as TLS and IKE must support selecting the appropriate certificates during coexistence.1

Hybrid key-establishment or dual-signature designs may help preserve interoperability while a healthcare ecosystem changes at different speeds. However, NIST’s draft notes that hybrid solutions add implementation and architectural complexity, which can increase security risks and costs. They should therefore have a documented rationale, defined compatibility boundaries, independent review, operational monitoring, and an exit condition. The draft characterizes hybrid solutions as typically temporary measures leading to tools that use only PQC algorithms, while recognizing that the tradeoffs vary by technique, application, vendor, and user community.2

Backward compatibility is important during transition, but compatibility must not become an invisible downgrade path. The NCSC recommends additional testing to confirm that standardized PQC cipher suites are actually being used rather than silently falling back to traditional cryptography. In a healthcare setting, this applies to patient portals, partner connections, clinician access, device-management channels, APIs, and cloud integrations.1

Where to focus first

The priority order should be risk-based, not simply technology-based. A modest-looking integration may deserve early action if it protects long-lived records or controls a high-impact clinical function. Conversely, a system with quantum-vulnerable cryptography may be scheduled later if its data has a shorter sensitivity horizon and its replacement cycle is well understood. The cited guidance supports prioritization by impact, confidentiality duration, exposure, and migration feasibility rather than a universal healthcare deadline.3

Standards, suppliers, and limitations

The source set includes NIST IR 8547, Transition to Post-Quantum Cryptography Standards, identified as an initial public draft published November 12, 2024. It also includes a final 2023 joint CISA, NSA, and NIST fact sheet, current NCSC migration guidance dated March 20, 2025, and NIST CSWP 39 Update 1, identified in the cited source record as final with an update dated June 29, 2026. These status labels and dates matter: an initial public draft is not the same as a final standard, and product implementation details may remain incomplete even when organizations are encouraged to prepare.2

Supplier engagement should ask when and how each commercial product will support PQC, whether support arrives through an upgrade or configuration change, what it costs, and how it will be tested. For cloud-hosted products, the organization should ask the cloud provider for its quantum-readiness roadmap. Vendors are encouraged to review NIST’s draft standards, but the joint guidance explicitly notes that final implementation specifics for those algorithms are incomplete. Procurement should preserve the ability to obtain evidence, update products, and avoid indefinite dependence on a supplier’s unsupported promise.3

Assurance and useful measures

Testing should cover correctness, interoperability, performance, availability, certificate issuance and renewal, signature validation, device behavior, recovery, monitoring, and rollback. It should also verify the cryptography actually used in production. The NCSC gives a concrete measurement direction: quantify how many software clients use PQC and identify those that do not. These measures show migration progress, expose remedial work, and help determine when support for traditional algorithms can be disabled.1

• Percentage of inventoried cryptographic dependencies with an owner, criticality, supplier, and migration decision.
• Percentage of high-impact services with a tested PQC or approved transition design.
• Number and proportion of clients, services, certificates, and connections observed using the intended PQC mechanism.
• Number of systems still relying on traditional algorithms, with documented reason and target date.
• Coverage of signed software and firmware paths tested for PQC-compatible creation and validation.
• Percentage of critical suppliers and cloud providers with a documented roadmap, delivery mechanism, and evidence plan.
• Count of devices that are constrained, non-upgradeable, difficult to service, or dependent on proprietary non-PQC protocols.

Start with a bounded pilot that represents the organization’s hardest dependencies: for example, an identity or remote-access path, a long-lived data exchange, a signed-update workflow, and a device or supplier integration. Record baseline latency, message and certificate sizes, failure modes, support boundaries, and fallback behavior. Then expand by risk-ranked waves, revisiting the inventory as systems change. Planning should coincide with normal infrastructure maintenance where possible, especially when physical infrastructure or embedded equipment is involved.31

Conclusion

PQC for healthcare is a disciplined transition of cryptography, identity, software supply chains, networks, applications, cloud services, and connected equipment. Begin now with governance and discovery, prioritize long-lived confidentiality and high-impact integrity functions, make suppliers accountable for concrete roadmaps, design for crypto agility, and test what systems actually negotiate. Keep hybrid operation and traditional algorithms under explicit control, preserve uncertainty where standards or implementations are still developing, and use measurable evidence to decide when each dependency is ready for the next stage.341