How Should Healthcare Organizations Assess Post-Quantum Cryptography Readiness in 2026?

What a Healthcare PQC Readiness Assessment Actually Measures

A Healthcare PQC Readiness Assessment is a structured review of how an organization’s encryption, authentication, signing, key-management, and technology-supply chain will behave when quantum-capable attackers can use a cryptographically relevant quantum computer, or CRQC, against current systems. It is not a test of quantum hardware, a prediction of the exact year a quantum computer will break RSA or elliptic-curve cryptography, or a claim that patient data is already unsafe. Instead, it measures the organization’s exposure, dependencies, migration options, ownership, and ability to execute a controlled transition. For healthcare operations, the review should cover EHR interfaces, claims exchanges, payer-provider transactions, identity services, telehealth, mobile applications, cloud connections, medical devices, backups, and archived records. As of September 26, 2026, organizations are moving from general education into planning, but standards, procurement rules, and vendor road maps can still change. The practical goal is therefore not immediate replacement of every certificate; it is building an evidence-backed inventory and a sequence of work that reduces the risk of discovering unsupported cryptography too late.

Also worth reading: How Should Healthcare Organizations Control AI Agents Accessing Clinical and Payer Systems? · What Are Operational AI Risk Controls for Healthcare Organizations in 2026? · How Can Healthcare Organizations Undo Risky AI Actions Before They Affect Patients?

A credible assessment normally produces four concrete outputs: a ranked cryptographic inventory, a list of systems that can support post-quantum algorithms, a remediation and replacement plan, and accountable owners with target dates. It should also distinguish data that merely needs to remain confidential for a limited period from information that may require decades of confidentiality. That distinction matters because an attacker can capture encrypted traffic or stolen records now and attempt decryption later, known as harvest now, decrypt later. Healthcare data can fit that pattern when it includes longitudinal medical histories, genomic information, behavioral records, or identifiers that make stolen data more useful over time. The assessment should not automatically classify every file as an emergency. It should correlate cryptographic strength, data sensitivity, retention period, system lifetime, compliance obligations, and migration difficulty before assigning priority.

Why Cryptography Becomes a Healthcare Operations Issue

Healthcare systems are unusually dependent on cryptography because protected information crosses many organizational boundaries. A hospital may use one identity provider, several cloud services, an EHR supplied by a third party, interfaces certified through a separate clearinghouse, imaging systems from another vendor, and connected medical equipment with firmware that cannot be changed quickly. A weak link can therefore affect trust between organizations even when the data itself resides in a well-managed application. The risk is not limited to clinical records either: payer coordination depends on trusted member matching, eligibility information, claims, authorization references, payment instructions, and communications among provider, payer, clearinghouse, and service-provider teams.

Connected devices add another layer because they often remain in service for 10 years or more, may lack conventional update mechanisms, and can be difficult to test in a production environment. A device does not need to process every patient record to create an exposure; telemetry, certificates, pairing protocols, and maintenance channels can reveal useful operational or clinical information. The same hardware-availability problem appears in servers and appliances, where a compatible replacement may take many months to order, configure, certify, and deploy. A post-quantum migration that ignores lead times can therefore create a service-availability problem while attempting to improve security. For payer and provider operations, the assessment should treat continuity, interoperability, and rollback procedures as core requirements rather than secondary technical details.

Regulatory and policy attention is increasing, but the timing should not be exaggerated. The U.S. National Institute of Standards and Technology finalized its first three post-quantum cryptography standards in August 2024: ML-KEM for key establishment, ML-DSA for digital signatures, and SLH-DSA for signature algorithms based on higher-security hash-based constructions. NIST’s migration planning has generally described a transition during the 2030s and full disallowance of vulnerable algorithms around 2035, although organizations should verify the current status of rules and agency-specific schedules in September 2026 and later. Federal contractor mandates may arrive through procurement terms, while regulated industries face pressure from data-protection expectations and supply-chain requirements. The absence of one universal healthcare deadline does not make planning optional; it makes dependency-based planning more sensible than waiting for a single compliance date.

The Five Assessment Workstreams

The first workstream is discovery. Organizations need to locate algorithms, libraries, protocol versions, certificates, cryptographic modules, and accountable vendors throughout the environment. Automated discovery tools can identify items such as RSA, elliptic-curve keys, SHA-1, and certificate chains, but their output must be validated because scans may miss embedded firmware, offline systems, shadow IT, backups, and software inherited from an acquisition. A useful inventory records not only an IP address, but also the business service, data class, owner, environment, algorithm, key size, protocol, certificate expiration date, vendor, and replacement lead time. The target should be near 100% coverage of internet-facing assets and priority clinical or financial workflows, while recognizing that perfect inventory accuracy is unrealistic in a large hospital network.

The second workstream is data and risk classification. Teams should estimate how long sensitive information must remain unreadable and how long the system that protects it is expected to operate. A useful planning threshold is to review cryptography whenever confidentiality is required for 10 years or more, especially when systems will remain in service beyond 2030. Risk scoring can give additional weight to genomic data, authentication credentials, signing keys, and data that would enable fraud if altered. However, numeric scoring should support judgment rather than replace it. A low-priority system connected to a high-priority identity service may inherit more risk than its own data classification suggests, while a sensitive system running on a platform with no supported upgrade path requires an earlier exception decision.

The third workstream is testing cryptographic agility and vendor readiness. Cryptographic agility means an organization can change algorithms, protocols, key sizes, and libraries without redesigning every dependent application. The review should ask vendors for supported algorithms, migration mechanisms, performance data, hybrid-mode plans, certificate-handling changes, testing environments, and contractual commitments. Product road maps alone are weak evidence, so a demonstration in a representative environment is more useful. The fourth workstream is implementation planning, including pilot, dependency, interoperability, rollback, and communications plans. The fifth is governance: executives need a decision owner, risk owners must accept documented exceptions, and a program office must maintain the inventory across procurement cycles. A successful assessment does not necessarily authorize migration; it defines what can be done safely and what uncertainty requires further testing.

A Practical Assessment Method for Health Systems

A healthcare organization can begin with a 90-day discovery phase, but should not confuse a short assessment with a complete migration. During the first 30 days, it can appoint an executive sponsor, establish scope, and identify the EHR, identity, cloud, claims, telehealth, payment, backup, and medical-device domains. Between days 31 and 60, teams can run discovery across production and supporting infrastructure, interview system owners, and attach cryptographic metadata to configuration-management records. Days 61 to 90 can be used to validate high-impact findings, test vendor claims, rank scenarios, and approve a multi-year roadmap. Organizations that begin now may need 12 to 36 months for early remediation and longer where medical devices, embedded software, or external payer interfaces are involved. Those are planning ranges, not guaranteed project schedules.

For each priority scenario, the team should document the current algorithm, expected service life, data confidentiality period, vendor dependency, replacement method, and operational consequence of failure. It should then compare immediate upgrade, hybrid deployment, compensating controls, managed postponement, and retirement. A hybrid protocol can reduce transition risk where both parties support it, but it adds complexity and does not automatically solve every incompatibility. Compensating controls—tight key rotation, segmentation, tokenization, access reduction, or shorter retention—may reduce exposure without removing it. A migration plan should include load and latency tests, certificate validation, disaster-recovery tests, rollback criteria, user communications where appropriate, and a method for proving that old algorithms are no longer active. Progress should be measured by scenarios retired or made ready, not by the number of scans completed.

A small pilot should involve one bounded but meaningful workflow, such as internal service-to-service authentication or a nonclinical interface with a controlled partner. It should use representative data, realistic certificate and key-management processes, and the same monitoring used in production. Performance overhead varies by algorithm, network conditions, hardware, protocol, and implementation, so no universal percentage is dependable. Teams should define acceptable latency, throughput, packet-size, availability, and recovery thresholds before testing, and require the supplier to provide comparable measurements. The pilot can then reveal issues that a workshop cannot, including library conflicts, certificate-size limits, proxy behavior, third-party gateways, and insufficient vendor support.

Comparing the Main Remediation Options

There is no single healthcare PQC strategy that fits every system. Replacements work best for short-lived, modular software, while retirement or redesign may be safer for obsolete appliances and inflexible devices. Hybrid modes can support staged interoperability, but they consume additional bandwidth and engineering effort. Compensating controls can buy time, yet they should be recorded as risk acceptance rather than presented as equivalent to a post-quantum migration.

Upgrading a modern application is often the cleanest option because the organization can adopt standardized libraries and managed key services. It is less attractive when a vendor has not committed to post-quantum support or when the product is near end of life. Hybrid deployments are useful when an organization cannot coordinate a simultaneous change with many trading partners, yet they should have an exit date. Compensating controls are valuable for a short-lived endpoint or a low-impact internal service, but rotating RSA keys against a future quantum threat does not solve the underlying longevity problem. Retirement can be the best security decision for a legacy appliance, provided the replacement preserves care delivery, claims processing, or patient safety.

Costs, Budgeting, and Avoided Risk

A standalone assessment may cost roughly $25,000 to $100,000 for a focused environment, while a broad discovery and roadmap across a hospital, payer, clearinghouse network, or medical-device estate may range from $100,000 to $500,000 or more. These are planning estimates, not quoted market prices, and the difference is driven heavily by asset count, source-code access, device testing, partner coordination, and regulatory scope. Internal labor can add substantially more than tool fees, particularly when security, privacy, clinical engineering, infrastructure, procurement, and legal teams must participate. Commercial tools often offer better discovery scale and reporting, while open-source inventories can reduce licensing cost but require staff time and independent validation.

Migration budgets should be separated from discovery spending. A modest inventory can expose a multi-million-dollar program involving identity platforms, interface gateways, data centers, and equipment replacement, so treating the first assessment as the total budget is misleading. Conversely, a high assessment cost does not mean every system should be converted immediately. Business cases should compare migration expense with service interruption, partner delays, manual workarounds, forensic exposure, and the possible expense of emergency replacement under rushed conditions. Healthcare leaders should also include operational resilience: redundancy, testing environments, rollback capacity, and clinical or claims continuity. A security project that creates extended downtime may be economically and clinically unacceptable, regardless of its cryptographic merit.

Pricing should therefore be tied to deliverables and evidence. A useful statement of work defines asset coverage, inventory fields, validation rate, risk methodology, vendor interviews, pilot support, final roadmap, data ownership, and handover documentation. Avoid buying a dashboard and calling it a readiness program. Contracts with critical technology suppliers should address support periods, notice of algorithm deprecation, testing access, interoperability commitments, and responsibility for cryptographic components. The final budget decision should reflect the maturity of the environment: a well-managed organization may fund discovery and targeted pilots, while a fragmented system with unsupported devices may need a larger architecture and replacement program.

Common Mistakes and When Healthcare Organizations Should Act

The most common mistake is waiting for a quantum computer capable of breaking current public-key systems. Such a machine may remain uncertain for years, but data capture and technology lead times occur now. Another error is equating post-quantum cryptography with quantum-safe technology products without evaluating vendors, algorithms, implementation quality, and supply chains. Labels and marketing road maps do not replace technical evidence. Teams also frequently inventory only servers, miss mobile applications and backups, or assume that replacing a certificate automatically updates the cryptography in the underlying application. Vendor dependence is often ignored, and projects fail when a gateway, partner, or embedded device can process only one protocol.

Healthcare organizations should act immediately when a system will remain in service beyond 2030, protects information requiring more than 10 years of confidentiality, uses hard-to-replace hardware, or has a vendor with no credible post-quantum path. Early action is also appropriate when a major platform, EHR, cloud contract, medical device, or claims interface is scheduled for renewal during the next 2 to 3 years. Organizations can act more selectively for isolated, short-lived systems that can be retired or upgraded through normal maintenance. They should not claim urgent exposure solely because a general scanner found RSA, nor should they set a target date without considering the service’s lifetime and the confidentiality period of its data.

A defensible cadence is to refresh the inventory at least annually and quarterly for high-priority identity, external-facing, or long-retention systems. Board and executive reporting should focus on the top 10 to 20 scenarios, unresolved vendor dependencies, accepted exceptions, pilot results, and forecast funding. As of September 26, 2026, the strongest posture is informed preparation: standards are available, regulatory and procurement expectations are advancing, and vendor strategies are becoming more concrete, but the healthcare sector still has substantial work to do. The objective is not to declare victory after installing one algorithm. It is to prove that the organization can discover, test, purchase, deploy, monitor, and retire cryptography without compromising safe care or reliable payer-provider operations.

What Credible Readiness Evidence Should Look Like

At completion, leadership should receive a prioritized register rather than a general statement that the environment is “PQC ready.” Evidence should show which assets use which algorithms, which data they protect, which third parties are involved, and whether tested alternatives exist. For every critical workflow, the organization should be able to identify an owner, replacement or retirement date, funding requirement, and current risk decision. Exceptions should include an expiration or review date. Vendor responses should be dated, attributable, and tied to product versions, because an undated statement of support can quickly become obsolete.

Readiness is demonstrated through repeatable tests. Those tests should cover algorithm negotiation, key generation, certificate validation, cryptographic failure handling, logging, secrets management, backup and restore, performance, interoperability, and rollback. A successful laboratory demonstration should be followed by a controlled operational pilot. The organization should also know how it will detect newly introduced weak cryptography in CI/CD pipelines and configuration management. Ultimately, the measure is operational capability: when a library, certificate, protocol, or supplier changes, the health system can identify affected services and execute a controlled response. That capability matters more than a single compliance percentage, although metrics such as 100% inventory coverage for critical assets and 100% documented ownership for top-risk scenarios provide useful management thresholds.