Harvest Now, Decrypt Later:
Post-Quantum Risk and Readiness in Healthcare Revenue Cycle Management

Introduction: The Next Cybersecurity Challenge

The long-term risk described in the Executive Summary begins with a practical question: how could advances in quantum computing affect the cryptographic protections that healthcare relies on today? The following sections explain the technology in plain language, distinguish current capabilities from future risk and establish why early planning is warranted without overstating the immediacy of the threat.

Scope and Intended Use

This paper focuses primarily on quantum risk to public-key cryptography used for key establishment, digital signatures, certificates, authentication and trusted communications. It does not assert that all symmetric encryption or hashing will fail at the same time. The discussion is intended to support executive planning and risk governance; specific implementation decisions should be validated against current standards, applicable requirements, vendor capabilities and approved enterprise architecture.

Quantum Computing in Plain Language

Quantum computing is a specialized form of computing designed for problems that are difficult or impractical for today’s traditional computers. It will not replace laptops, servers, or revenue cycle platforms, but it may eventually solve certain complex calculations far faster than conventional systems.

Limits of Traditional Computing

Traditional computers process information through tiny switches that are either on or off. Everything they do, from sending email to processing claims, depends on billions of these simple decisions happening at very high speed.

For most business tasks, this approach works well. The challenge is that some problems involve so many possible combinations that even powerful traditional computers would need an impractical amount of time to evaluate them.

The Role of Today’s AI Infrastructure

This is one reason organizations are investing in large data centers filled with high-end graphics processing units, or GPUs, to support modern AI systems. GPUs help traditional computers perform many calculations in parallel, making them well suited for training and running AI models.

Quantum computing represents a different approach. Instead of adding more conventional computing power, it may eventually help solve certain specialized problems that remain impractical even for today’s largest GPU-powered environments.

How Quantum Computers Are Different

Traditional computers process information as a series of fixed choices: off or on, 0 or 1. Quantum computers use a different building block called a qubit. Qubits follow the rules of quantum physics, which allows them to represent and coordinate possibilities in ways traditional bits cannot.

Figure 1. Classical bits store a defined value of 0 or 1, while qubits use superposition to represent multiple possibilities and entanglement to coordinate outcomes across a correlated quantum system.

Two Concepts That Matter

• Superposition: A qubit can represent more than one possible state before it is measured. A traditional bit is like a coin that has already landed: it is either heads or tails. A qubit is more like a coin still spinning in the air, where more than one outcome remains possible until the result is observed.
• Entanglement: Qubits can be linked so the state of one qubit is connected to the state of another. As a loose healthcare finance analogy, consider a model that evaluates payer mix, reimbursement rates, denial trends, system performance and cash flow together because no single measure tells the full story. Entangled qubits are not simply business variables that influence one another; they form one quantum system, so their measurement results must be understood together rather than independently.

Current State of Quantum Computing

Quantum computing has moved beyond theory, but current systems remain primarily research and development platforms. Their limitations in scale, stability and error correction mean they do not yet pose an immediate threat to widely used encryption. Three characteristics define the current state:

• Available, but specialized. Quantum computers can be accessed through research institutions and cloud services, although practical business applications remain narrow.
• Technically fragile. Qubits are highly sensitive to environmental interference and maintaining reliable calculations often requires extreme cooling, precise controls and extensive error correction.
• Timeline remains uncertain. Significant advances in hardware, stability and scale are still required before quantum systems could threaten modern public-key encryption broadly, making readiness a long-term planning issue rather than an immediate crisis.

AI could accelerate progress within this still-uncertain timeline. It will not instantly produce a quantum breakthrough, but it may reduce the time required to address difficult hardware, error-correction, control and optimization challenges. By helping researchers solve these barriers faster, AI could shorten the path toward cryptographically relevant quantum systems.

The result is a planning challenge: quantum systems are limited today, but the pace of progress may not remain predictable. If AI accelerates development, organizations may have less time than expected to modernize cryptographic protections. Healthcare leaders should therefore use the current period to identify long-lived sensitive data, understand cryptographic dependencies and prepare for risks that could emerge as quantum capabilities advance.

From Quantum Capability to Cybersecurity Risk

Quantum algorithms use superposition and entanglement to steer calculations toward more useful answers and away from less useful ones. In practical terms, this means quantum computers may eventually narrow enormous sets of possibilities much faster than traditional computers can for certain specialized problems. Their advantage is limited to problems that can benefit from quantum behavior, but some of those problems have important implications for cybersecurity.

Why Quantum Computing Creates a Security Concern

Healthcare data is protected through regulatory requirements, industry standards, contractual obligations, risk-based safeguards and established security practices, with encryption commonly securing electronic protected health information, payment data, financial transactions, system connections, backups, files and communications at rest and in transit. Although quantum computers are not breaking healthcare encryption today, sufficiently capable systems could eventually compromise some of the public-key cryptography used for secure connections, key exchange, authentication and digital signatures. This creates a long-term concern for clinical, financial and revenue cycle data whose sensitivity, regulatory significance, or strategic value may persist for years or decades.

The uncertainty surrounding the timeline does not justify immediate, large-scale replacement of existing cryptography, but it does justify beginning the lower-cost work of discovery, risk assessment, vendor engagement and roadmap development now. Early planning allows healthcare organizations to align future investments with normal technology refreshes, contract renewals and capital cycles rather than fund a rushed and potentially disruptive response later. This preparation is particularly important because encrypted data can be collected today and retained until future capabilities make it readable.

Understanding “Harvest Now, Decrypt Later”

The Core Idea

Harvest Now, Decrypt Later describes a long-term threat model: encrypted data may be stolen today even if it cannot be read yet, then stored until future tools make decryption possible. The risk is not tied to quantum computers breaking healthcare encryption today. It is tied to whether information protected by current encryption will still need to be confidential when stronger computing capabilities arrive.

The pace of emerging technology adoption is difficult to predict. AI’s rapid expansion illustrates how advances in computing power, investment, research and commercial adoption can reinforce one another, underscoring the value of preparing before a developing capability reaches an operational tipping point.

A useful analogy is a locked filing cabinet that can be stolen even when the thief cannot open it. The contents remain protected for now, but the attacker controls the cabinet and can preserve it until better tools become available. Similarly, encrypted healthcare data taken from systems, vendors, file transfers, backups, or cloud repositories may be retained for years in anticipation that future capabilities will make some of today’s cryptographic protections easier to defeat.

This makes time horizon the central issue. Data with little future value creates limited exposure. Data that remains useful, sensitive, regulated, or strategically important for years creates a much larger risk window. Harvest Now, Decrypt Later is therefore less about the moment of theft and more about the future value of what was taken.

 

Figure 2. Ransomware creates immediate operational disruption and financial pressure, while Harvest Now, Decrypt Later creates a delayed risk to the confidentiality of long-lived healthcare and revenue cycle data.

How This Differs from Ransomware

Ransomware dominates healthcare cybersecurity discussions for good reasons. It can interrupt clinical operations, delay care, divert patients, disrupt pharmacy and laboratory workflows and create immediate patient safety concerns. These attacks are usually designed to create near-term pressure: disrupt operations, create urgency and force a payment decision.

Harvest Now, Decrypt Later is different. It reflects a patient, intelligence-driven approach in which sophisticated threat actors collect encrypted data because they believe it may be valuable in the future. The attacker does not need immediate access to the contents. The value comes from preserving the data until cryptographic protections weaken, keys are exposed, or more advanced computing capabilities become available.

• Ransomware creates immediate disruption, operational pressure and extortion.
• Harvest Now, Decrypt Later relies on patience, persistence and the future value of stolen data.
• Ransomware threatens availability today; Harvest Now, Decrypt Later threatens confidentiality over time.

Who Has the Motivation and Resources

Not every attacker will take this approach. Many cybercriminals want quick monetization. Harvest Now, Decrypt Later is more likely to appeal to nation-state groups, advanced criminal organizations, intelligence-driven adversaries, or others with the patience, storage capacity and resources to preserve encrypted data for future use.

For these threat actors, the payoff may not come from shutting down a hospital today. It may come years later, when previously unreadable information provides insight into healthcare infrastructure, financial flows, payer relationships, patient populations, or strategic business activity.

Leadership Implications

The practical leadership takeaway is that encryption must be judged against the full life of the data, not only the moment it is created, transmitted, or stored. Some data loses value quickly. Other data may remain sensitive for years or decades.

This risk is especially significant in healthcare, where long-lived data moves across many organizations and supports both patient care and financial operations.

 

Why Healthcare Is Particularly Vulnerable

Long-Lived Data and Retention Obligations

Healthcare is unusually exposed to Harvest Now, Decrypt Later risk because sensitive information often retains clinical, operational, financial, legal and regulatory value long after it is created. Patient records may support ongoing care, while claims histories, payer terms, reimbursement strategies, denial trends and forecasts may remain important to billing, appeals, audits, disputes and strategic planning.

HIPAA, CMS program requirements, state laws, payer contracts, audits, disputes and litigation holds may require records to be retained for extended periods. Unlike a compromised password, this information cannot simply be reset or invalidated after exposure. It and the cryptographic controls that secure it must remain protected throughout its useful and required life, including when it moves across systems, vendors and business partners.

A Broad and Interdependent Healthcare Ecosystem

Healthcare organizations rarely control the full lifecycle of their data. Information moves through electronic health record systems, revenue cycle platforms, clearinghouses, payer portals, cloud services, analytics environments, managed service providers and payment workflows. Each connection adds another cryptographic dependency and another location where data may be stored.

Encrypted copies may also persist in backups, reporting platforms, file exchanges, testing environments and transaction repositories managed internally or by third parties. This distribution expands the attack surface and increases potential exposure across clinical, financial and operational environments.

Financial, Operational and Patient Impact

Healthcare exposure extends beyond privacy. Claims, remittance information, payer contracts, denial trends, pricing assumptions and forecasts can retain strategic and financial value long after the original transaction. Future cryptographic weaknesses could also affect identity systems, secure connections, file transfers, claims submission, vendor trust relationships and other functions that support revenue flow and patient care. The result could be financial loss, operational disruption, or reduced support for clinical services.

Leadership Implications

Healthcare’s vulnerability reflects practical business conditions rather than speculation about quantum computing: critical data remains valuable for extended periods, moves through many organizations and supports patient care and financial performance. Leaders across security, technology, finance, revenue cycle, legal, procurement and vendor risk should establish ownership, identify long-lived sensitive data, map where it travels and who retains it and prioritize systems where cryptographic weakness or migration disruption would create the greatest impact.

Turning that shared responsibility into action requires visibility into the cryptographic dependencies embedded across the technology environment.

The Hidden Challenge: Cryptographic Technical Debt

Encryption Is Everywhere, but Often Hard to See

One of the hardest parts of post-quantum readiness is that many organizations do not have a complete view of where encryption is used. Cryptography is not limited to obvious security tools. It is embedded in applications, databases, file transfers, APIs, identity platforms, certificates, backups, cloud services, medical devices and vendor connections.

In healthcare, this creates a form of technical debt. Systems that were designed years ago may still work reliably, support critical workflows and pass current security reviews, but they may rely on cryptographic methods that will eventually need to be replaced or redesigned. The difficulty lies not only in selecting a replacement algorithm, but also in locating every instance of legacy cryptography across the environment.

Where Cryptographic Debt Accumulates

Cryptographic debt tends to accumulate in the systems that are hardest to replace, most deeply integrated, or least visible to business leaders. In healthcare, those areas often include:

• Legacy applications: long-running clinical, billing, finance and operational systems that may use older encryption libraries or hard-coded assumptions.
• Medical devices and specialized equipment: devices with long service lives, limited update paths, or manufacturer-controlled software.
• Authentication and identity systems: certificates, tokens, single sign-on integrations, VPNs and secure access tools that depend on cryptographic trust.
• Embedded cryptography: encryption built into applications, databases, APIs, file transfer tools, middleware and third-party components.
• Long technology replacement cycles: systems that remain in production for many years because they are expensive, complex, or operationally difficult to replace.

Why This Matters for Post-Quantum Migration

Post-quantum migration will likely be more complicated than a routine software upgrade. Some systems may support new cryptographic standards through normal updates. Others may require application redesign, vendor coordination, certificate replacement, interface testing, contract changes, or long-term replacement planning.

This is why cryptographic agility matters. Organizations need the ability to change encryption methods, certificates, keys and related controls without disrupting critical workflows. In revenue cycle operations, even a well-intentioned security migration can create risk if it interrupts claims submission, remittance processing, payer connectivity, eligibility checks, payment workflows, or customer access.

Planned Obsolescence of Cryptographic Algorithms

Cryptographic technical debt is becoming more urgent because widely used public-key algorithms for key establishment and digital signatures are not expected to remain suitable indefinitely. NIST finalized its principal post-quantum cryptography standards in 2024 and has advised organizations to begin applying them while planning a transition away from quantum-vulnerable public-key algorithms.

NIST post-quantum cryptography standards include:

• FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
• FIPS 204: Module-Lattice-Based Digital Signature Standard
• FIPS 205: Stateless Hash-Based Digital Signature Standard

NIST’s current transition roadmap anticipates deprecating and ultimately removing quantum-vulnerable algorithms from NIST standards by 2035, with higher-risk systems transitioning earlier. This is a standards-transition planning horizon—not a universal statutory deadline for every healthcare organization—and should be applied according to data sensitivity, system criticality, vendor readiness and applicable obligations.

For healthcare organizations, this planned obsolescence changes the conversation from “if” to “when.” Systems that rely on aging cryptographic methods may continue to function today, but they may become harder to defend, harder to certify, harder to contract around and harder to connect to partners as standards and customer expectations evolve. The risk is especially significant for applications, devices, integrations and vendor platforms with long replacement cycles.

This is why technical debt should be treated as a roadmap issue, not just an architecture issue. Leaders need to know which systems depend on algorithms that may be deprecated, which workflows would be affected by replacement, which vendors control those components and how long the organization has to migrate safely before old cryptography becomes unacceptable for new deployments or disallowed entirely.

Aging Infrastructure Is the Right Analogy

Quantum migration is similar to replacing aging infrastructure that was never designed for today’s requirements. The work is difficult not only because new standards are complex, but because older systems were often not built for quick replacement, broad interoperability, or frequent cryptographic change.

For healthcare leaders, the most important first step is visibility. Before an organization can prioritize migration, it must understand where cryptography exists, which systems rely on it and which workflows would be affected if it had to change. That visibility also helps leaders understand where third parties may control critical parts of the cryptographic environment.

Once those dependencies are visible, leaders can assess how cryptographic weakness or migration activity could affect the financial workflows that depend on them.

How Quantum Risk Impacts Revenue Cycle Management

Quantum Risk as a Revenue Integrity Issue

Revenue cycle management depends on trust: trust that claims are accurate, payer connections are secure, remittance information is reliable, identities and systems are authentic and financial data remains confidential. Post-quantum risk matters because public-key cryptography supports not only confidentiality, but also digital signatures, certificates, authentication, software integrity and secure key establishment across claims submission, eligibility, remittance, payment posting, denial management, analytics and payer communications.

If future quantum capabilities weaken today’s cryptographic protections, the impact could extend beyond patient privacy to revenue integrity, financial performance and operational resilience. For finance and revenue cycle leaders, quantum readiness is therefore a business risk and continuity issue, not only a technical security concern.

Business and Financial Consequences

Revenue cycle data can reveal how services are billed and paid, how coverage and authorization workflows operate, where reimbursement is at risk and how an organization approaches payer negotiations, pricing and financial planning. Claims, remittance files, eligibility transactions, payer responses, denial and appeal data, contract terms, pricing assumptions, provider compensation models, acquisition materials and forecasts may retain strategic value long after the original transaction.

If this information becomes readable years after it was stolen, the consequences could include weaker payer negotiations, exposed reimbursement strategies, greater audit complexity, competitive intelligence risk and harm to long-term financial performance, even after the original systems have changed.

Operational Dependencies and Resilience

Revenue cycle operations depend on secure, trusted connections among providers, clearinghouses, payers, banks, analytics platforms and technology vendors. Claims, eligibility, authorizations, remittance, payments and reconciliation must continue to move reliably as cryptographic standards, certificates, interfaces and vendor connections change. A poorly coordinated migration could create immediate financial and operational disruption.

Quantum readiness therefore belongs within revenue cycle resilience, vendor risk, payment integrity, audit readiness and long-term technology modernization. Planning should identify critical dependencies, coordinate migration across partners and test continuity before production changes.

Among the most consequential dependencies are clearinghouses, whose central role in healthcare transactions concentrates both operational reliance and long-lived data exposure.

Clearinghouses: The Healthcare Ecosystem’s Data Concentrators

Why Clearinghouses Deserve Special Attention

Clearinghouses occupy a unique position in healthcare because they sit between providers, payers and other revenue cycle participants. They process large volumes of claims, eligibility transactions, remittance information, edits, acknowledgments and related financial data. That concentration of transaction activity makes them important to revenue flow and important to post-quantum risk planning.

In a Harvest Now, Decrypt Later scenario, data concentration matters. A hospital breach may expose information from one organization. A clearinghouse or revenue cycle platform may contain transaction histories across many organizations, payers, service lines and geographies. The value of that data may come not only from individual records, but from the patterns and relationships visible across the ecosystem.

Historical Archives and Transaction Repositories

Clearinghouses and RCM platforms may retain transaction data for operational support, audit response, customer service, reporting, analytics, dispute resolution and regulatory or contractual obligations. These repositories can include claims histories, payer responses, remittance files, edits, rejections, acknowledgments and metadata about transaction timing and flow.

The longer these archives remain available, the more important long-term cryptographic protection becomes. A repository that supports today’s operations may also become a future exposure point if the encryption protecting historical data does not remain durable over the life of the archive.

Clearinghouse Assurance

Because clearinghouses concentrate high volumes of long-lived transaction data and support critical revenue workflows, healthcare organizations should treat their post-quantum readiness as a priority within third-party risk management. Assessments should address cryptographic visibility, data retention, platform modernization, migration planning and the ability to maintain transaction continuity as encryption standards evolve.

Clearinghouses represent one of the most concentrated points of exposure, but they are part of a broader supply chain in which technology and service providers store, process, transmit, or protect healthcare data. Managing post-quantum risk therefore requires visibility and accountability across the entire vendor ecosystem.

The Vendor and Supply Chain Problem

Shared Vendor and Supply Chain Risk

A healthcare organization is only as quantum-resilient as the vendors and subcontractors that store, process, transmit, or protect its data. Even when internal systems modernize, exposure remains if critical EHR, RCM, cloud, managed service, clearinghouse, or medical device providers cannot identify their cryptographic dependencies, retained data, accountable owners, or migration paths.

Readiness therefore requires shared visibility into product architecture, third-party components, subcontractors and the changes needed to preserve clinical, financial and revenue cycle operations as cryptographic standards evolve.

Vendor Readiness and Accountability

Healthcare organizations should not expect every vendor to have completed a post-quantum migration today. They should expect critical vendors to identify where cryptography is used, understand which systems and third parties shape their migration path, assign accountable ownership and explain how customer data and services will be protected during the transition.

Assurance should focus on evidence: a current cryptographic inventory, defined retention practices, prioritized modernization needs, tested continuity plans, customer communication processes and governance for residual risk. The objective is not immediate completion, but confidence that each critical vendor can support a controlled migration as standards evolve.

Contracting and Procurement Implications

Vendor readiness should be reflected in procurement, contracting, security reviews and third-party risk management. CISA now identifies product categories in which PQC-capable technologies are widely available and recommends that organizations planning acquisitions in those categories procure PQC-capable products. New agreements should preserve cryptographic agility and address data retention, subcontractor dependencies, customer communications, migration responsibilities, interoperability testing and evidence of continued support.

This does not mean every contract needs detailed post-quantum language immediately. It does mean organizations should begin asking better questions and preserving flexibility. Technology decisions made today may remain in place when quantum-resistant standards become more broadly expected.

Leaders can focus vendor assessments on four executive questions.

1. Does the vendor maintain a current inventory of cryptographic dependencies across its products, services, infrastructure and third-party components?

2. How long does the vendor retain sensitive customer data, transaction data, logs, backups and archives?

3. How will migration and continuity be tested to protect critical healthcare and revenue cycle workflows?

4. Who is accountable for the vendor’s roadmap, customer communications and residual risk? 

For a broader organizational and third-party guide, see Appendix A: 10 Questions Healthcare Leaders Should Ask About Quantum Readiness.

FinThrive’s Approach

As a responsible RCM partner, FinThrive is applying the approach described in Building a Post-Quantum Roadmap and the corresponding six-phase framework in Appendix B: Post-Quantum Readiness Implementation Checklist. This structured path supports awareness, cryptographic discovery, risk assessment, prioritization, migration planning and continuous readiness as standards, technologies and customer expectations evolve.

This approach reflects a broader responsibility shared across providers, vendors, payers, cloud platforms and service partners. Readiness depends on integrating vendor oversight with third-party risk, procurement, architecture review, cyber resilience and customer assurance so the ecosystem can migrate safely when needed.

These governance and vendor oversight activities require a shared, decision-quality view of cryptographic dependencies across internal systems and third-party services. A Cryptographic Bill of Materials provides the visibility needed to assess exposure, set priorities and plan modernization.

The Emerging Concept of a Cryptographic Bill of Materials (CBOM)

Knowing What Must Be Modernized

Before organizations can modernize cryptography, they need to know where it exists. A Cryptographic Bill of Materials, or CBOM, is an emerging inventory approach for documenting cryptographic algorithms, keys, certificates, libraries, protocols and dependencies across systems, applications, platforms and vendors. Building this view typically combines automated discovery, architecture and certificate records, vendor disclosures and manual validation.

A CBOM turns post-quantum readiness into a practical management activity by showing leaders what may need to change, where material exposure exists and which systems require early attention.

How a CBOM Differs from Existing Inventories

Most healthcare organizations already maintain some form of asset inventory. Many are also expanding Software Bill of Materials, or SBOM, programs to understand which software components and dependencies exist in their environment. A CBOM builds on these efforts but answers a different question: not just what systems and software exist, but what cryptographic protections those systems rely on.

For example, an asset inventory may show that an organization uses a claims processing platform. An SBOM may show the software libraries used by that platform. A CBOM would identify the encryption algorithms, certificates, key exchange methods, signing mechanisms and secure communication protocols that allow the platform to store data, transmit files, authenticate users and connect with payers or vendors.

Risk-Based Prioritization

Post-quantum migration will not affect every system equally. When paired with business context, a CBOM helps leaders identify quantum-vulnerable algorithms, third-party dependencies, certificates or keys that may require replacement and vendors that must be engaged. Prioritization should focus on five factors:

• Data sensitivity: Does the system handle PHI, claims, remittance, payer contracts, payment information, or strategic financial data?
• Data lifespan: Does the information need to remain confidential for years or decades?
• Operational impact: Would disruption affect care support, claims movement, payment posting, identity, or payer connectivity?
• Vendor dependency: Does the organization control the cryptography directly, or does a vendor, cloud provider, or third party manage it?
• Migration complexity: Can the system be updated normally, or would changes require redesign, testing, replacement, or contract changes?

Applying a CBOM to the Claims Lifecycle

Across a claims lifecycle, cryptography protects data as transactions move among provider systems, RCM platforms, clearinghouses, payers and downstream reporting or analytics services. A CBOM maps the algorithms, certificates, protocols and other dependencies supporting that flow and identifies whether each control is managed internally or by a vendor.

This view helps leaders identify which transaction points require modernization, which parties must coordinate changes and where migration could disrupt claims, remittance, payment, or related operations.

A CBOM turns cryptographic discovery into actionable business visibility by connecting technical dependencies to vendor ownership, revenue protection and critical operations. Once those dependencies are understood, leaders can plan how to modernize them without disrupting the workflows they support.

Quantum Risk and Cyber Resilience

Migration Delay as a Resilience Risk

Post-quantum risk extends beyond future confidentiality. Delayed preparation may eventually force rapid changes to certificates, digital identities, software validation and trusted connections. If those changes are made under time pressure, the migration itself could disrupt the healthcare and revenue cycle operations those controls support.

Protecting Critical Workflows During Migration

The executive concern is continuity: claims, eligibility, authorizations, remittance, payments, patient support services, authentication, recovery and partner connectivity must continue while cryptographic controls change. These workflows often depend on linked certificates, interfaces, identity services, software updates, backups and vendor connections that must be modernized in a coordinated sequence.

A poorly coordinated transition could create failed connections, authentication errors, delayed transactions, reporting gaps, outages, or weakened recovery readiness even when the underlying security objective is sound.

Building Resilience Before Urgency

Organizations should build readiness before time pressure limits their options. Changes should be sequenced by business criticality, with interoperability and continuity tested in controlled environments, rollback and recovery procedures defined, timing coordinated with critical partners and residual risk documented and managed.

Executive governance is required to ensure that migration risks are identified, funded, tested, monitored and supported by evidence of reasonable action.

Regulatory, Legal and Board-Level Implications

Evolving Expectations and Evidence of Action

As post-quantum standards, assurance frameworks, vendor capabilities and market practices mature, healthcare organizations will increasingly be expected to demonstrate informed and reasonable action. Evidence of governance, exposure assessment, accountable ownership, investment planning and measurable progress will become increasingly important alongside the technical controls themselves.

NIST guidance, HITRUST considerations, customer expectations, third-party risk practices, contracts and cyber insurance will increasingly influence how healthcare organizations demonstrate post-quantum readiness. These developments will require organizations to integrate post-quantum risk into established enterprise risk, architecture, vendor oversight and planning processes.

Board and Executive Oversight

Boards and executive leadership teams do not need to understand the mathematics of quantum computing. Their role is to establish accountability, evaluate material exposure, approve investment priorities, monitor progress and determine whether residual risk remains within the organization’s tolerance.

Governance Questions for Leadership

• Who owns post-quantum readiness across security, technology, finance, legal, procurement and vendor risk?
• Which data must remain protected for years or decades and where is it stored or transmitted?
• Which vendors and platforms are most critical to long-term confidentiality and operational continuity?
• How will cryptographic readiness be reflected in enterprise risk reporting, technology roadmaps, procurement and contract reviews?
• What evidence will leadership use to demonstrate reasonable planning and progress over time?

Effective oversight must be supported by disciplined financial planning that aligns modernization costs with technology refreshes, contract cycles and enterprise investment priorities.

Financial Planning and Investment Governance

Early discovery allows finance and technology leaders to incorporate post-quantum modernization into normal capital and operating plans rather than fund emergency remediation. Financial forecasts should account for software and infrastructure upgrades, certificate and identity modernization, vendor replacement, interoperability testing, temporary parallel environments, workforce capacity, external assurance and the accelerated retirement of assets that cannot support required cryptographic change. Investment decisions should align with technology refreshes, contract renewals and enterprise priorities, with approval gates based on business criticality, expected service life, migration complexity, continuity requirements and the financial risk of delay. The roadmap that follows translates these investment considerations into a phased program for discovery, prioritization, migration and sustained readiness.

Building a Post-Quantum Roadmap

A Phased Approach to Readiness

Post-quantum readiness requires a disciplined, phased program that builds awareness, visibility, governance and execution capacity before migration becomes urgent.

Phase 1: Awareness

Establish a shared understanding of post-quantum risk, secure executive sponsorship and assign accountable ownership across security, technology, finance, legal, procurement and vendor risk. Align leaders on the data, workflows and vendor relationships most important to revenue protection, patient support, cyber resilience and regulatory assurance.

Phase 2: Discovery

Build a validated view of cryptographic dependencies across internal systems and third parties, then connect those dependencies to the critical data and business workflows they protect.

Phase 3: Risk Assessment

Evaluate exposure based on data lifespan, business impact, vendor control and the risk that weakened cryptography or migration activity could disrupt operations.

Phase 4: Prioritization

Convert assessed risks into a funded, sequenced modernization plan with accountable owners, approval gates, decision points and target milestones.

Phase 5: Migration

Execute approved changes through coordinated design, vendor engagement, interoperability testing, continuity controls, rollback planning and validation of critical healthcare and revenue cycle workflows before production transition.

Phase 6: Continuous Readiness

Maintain governance, refresh cryptographic visibility and risk assessments, monitor standards and vendor developments, reassess priorities and report measurable progress through existing enterprise oversight channels.

This section establishes the six-phase post-quantum roadmap. For the corresponding phase-by-phase action guide that translates the roadmap into implementation steps, see Appendix B, “Post-Quantum Readiness Implementation Checklist.”

Together, these six phases provide a measured path from awareness to sustained readiness. The executive scorecard translates that roadmap into measurable evidence of governance, funding, execution and operational preparedness.

 

Download Executive Scorecard PDF

 

Conclusion: Quantum Computing Is a Revenue Integrity Issue

Final Message

For healthcare executives, quantum computing is not solely a cybersecurity concern or future compliance exercise. It is a long-term revenue integrity and cyber resilience issue that intersects with revenue protection, vendor governance, regulatory readiness and financial stewardship.

Organizations that prepare early gain more time to align modernization with normal technology, contract and investment cycles. Those that delay may face higher costs, compressed timelines, greater disruption and fewer options.

The defining question is whether healthcare organizations can modernize quantum-vulnerable cryptography in time to protect long-lived data, trusted connections, digital identities and revenue cycle operations without unnecessary cost or disruption.

 

Appendix A: 10 Questions Healthcare Leaders Should Ask About Quantum Readiness

Post-quantum readiness does not require healthcare leaders to become cryptography experts. It does require finance, security, technology, compliance, procurement and vendor risk leaders to ask the right business, operational and third-party questions before quantum risk becomes urgent. The following questions can help frame quantum readiness as a revenue protection, cyber resilience, customer trust and governance issue.

1. What sensitive financial, patient and operational data must remain protected for many years or decades? Long-lived data creates the greatest exposure to Harvest Now, Decrypt Later risk.
2. Where does our organization rely on encryption across revenue cycle operations? Claims processing, eligibility, remittance, payment posting, payer connectivity, analytics and vendor integrations may all depend on cryptographic protections.
3. Do we have a current inventory of cryptographic assets, algorithms, certificates and dependencies? Without a clear inventory or Cryptographic Bill of Materials, leaders cannot accurately estimate migration scope, cost, or risk.
4. Which vendors handle our most sensitive revenue cycle data and what are their post-quantum readiness plans? Clearinghouses, EHR vendors, RCM platforms, cloud providers, payment processors and managed service providers should be able to explain their migration strategy.
5. How long do our vendors retain claims, payment, eligibility, denial and remittance data? Retention practices directly affect how much historical information could be exposed if today’s encryption becomes vulnerable in the future.
6. Are post-quantum requirements being added to our procurement, contracting and third-party risk processes? New technology decisions made today may remain in place when quantum-resistant standards become expected.
7. Which systems would have the greatest financial or operational impact if cryptographic weaknesses disrupted connections or trust relationships? Leaders should understand whether claims submission, remittance processing, payment workflows, identity systems, reporting, or payer connectivity could be affected.
8. How are we prioritizing systems that combine sensitive data, long retention periods and complex vendor dependencies? These systems should receive early attention because they are harder to migrate quickly.
9. What would delayed post-quantum migration cost the organization? Leaders should consider emergency remediation, vendor replacement, contract exposure, operational downtime, audit scrutiny and reputational impact.
10. How will executive leadership and the board monitor quantum readiness over time? Post-quantum preparedness should become part of cybersecurity governance, vendor oversight, technology planning and enterprise risk discussions.

These questions enable leaders to translate technical risk into clear priorities for protecting critical data, systems, contracts, vendor relationships and workflows before today’s encryption becomes a material exposure.

 

Appendix B: Post-Quantum Readiness Implementation Checklist

Use this checklist to translate the six-phase post-quantum roadmap into a managed program. Assign an owner and target date to each item, retain evidence of completion and revisit the checklist as standards, vendor capabilities and organizational priorities evolve.

Phase 1: Awareness

• Establish a shared, practical understanding of post-quantum risk across executive leadership, finance, security, technology, legal, procurement and vendor risk.
• Clarify that quantum computers are not breaking healthcare encryption at scale today, while emphasizing the risk to long-lived sensitive data.
• Identify the data, workflows and vendor relationships most important to revenue protection, patient support, cyber resilience and regulatory assurance.
• Name an executive sponsor and accountable program owner.

Phase 2: Discovery

• Identify cryptography used across systems, applications, databases, certificates, APIs, file transfers, identity platforms, backups, cloud services and vendor connections.
• Begin or update a Cryptographic Bill of Materials covering algorithms, keys, certificates, protocols, libraries and dependencies.
• Map each cryptographic dependency to the business workflow and data it protects.
• Record whether the organization or a third party controls each dependency.
• Document retention periods for sensitive clinical, financial, operational and transaction data.

Phase 3: Risk Assessment

• Identify data that must remain confidential for years or decades.
• Determine where long-lived sensitive data is stored, transmitted, backed up and archived.
• Assess vendor readiness, subcontractor dependencies and customer communication plans.
• Evaluate the operational and financial impact of cryptographic weakness or migration-related disruption.
• Record risks in existing cybersecurity, enterprise risk, architecture and third-party risk processes.

Phase 4: Prioritization

• Rank systems by data sensitivity, data lifespan, operational impact, vendor dependency and migration complexity.
• Give early attention to systems that combine long-lived sensitive data with revenue cycle or patient-support dependencies.
• Identify high-risk legacy systems, certificates, interfaces and vendor-controlled components.
• Define a sequenced roadmap with owners, funding assumptions, decision points and target dates.
• Align priorities with technology refresh, procurement, contract renewal and resilience planning cycles.

Phase 5: Migration

• Select post-quantum or approved hybrid approaches as standards and supported solutions mature.
• Update affected algorithms, certificates, keys, libraries, applications, interfaces and infrastructure.
• Coordinate migration plans with vendors, cloud providers, clearinghouses, payers and other critical partners.
• Test claims submission, eligibility, remittance, payment, identity, reporting, backup and recovery workflows before production changes.
• Define rollback, continuity, exception and residual-risk procedures.
• Update procurement requirements, contracts, architecture standards and operating documentation.

Phase 6: Continuous Readiness

• Establish a recurring governance cadence and defined reporting path to executive leadership and the board.
• Refresh the CBOM and risk assessment after material architecture, vendor, certificate, or product changes.
• Reassess vendor readiness, migration timelines, contracts and residual risks periodically.
• Monitor NIST and HITRUST guidance, assurance expectations, regulatory developments and market practices.
• Track milestones, exceptions, test results and evidence of progress through existing governance channels.
• Repeat prioritization as standards, technology and business dependencies evolve.

 

Appendix C: References

1. National Institute of Standards and Technology, "Post-Quantum Cryptography FIPS Approved," August 13, 2024.
2. National Institute of Standards and Technology, "Post-Quantum Cryptography," standards and migration overview.
3. National Institute of Standards and Technology, NIST IR 8547, "Transition to Post-Quantum Cryptography Standards," initial public draft, November 2024.
4. NIST National Cybersecurity Center of Excellence, "Migration to Post-Quantum Cryptography."
5. Cybersecurity and Infrastructure Security Agency, National Security Agency and National Institute of Standards and Technology, "Quantum-Readiness: Migration to Post-Quantum Cryptography."
6. Cybersecurity and Infrastructure Security Agency, "Product Categories for Technologies That Use Post-Quantum Cryptography Standards," January 23, 2026.
7. Cybersecurity and Infrastructure Security Agency, "Strategy for Migrating to Automated Post-Quantum Cryptography Discovery and Inventory Tools."
8. HITRUST Alliance, "HITRUST CSF Version 11.9.0 Release," September 24, 2026.