Case Study: Building a Quantum Readiness Roadmap for a Hospital System

Executive Summary

Meridian Health operates eleven hospitals and retains patient records for the lifetime of the patient plus twenty-one years. Its board has asked a simple question with an uncomfortable answer: "Are we exposed to quantum computing, and if so, when?"

Unlike the previous case study, where the correct answer was "ignore this," here the correct answer is "act, but not on the thing you probably think." You will build a defensible readiness roadmap by separating three timelines that get conflated in board conversations: the data sensitivity horizon, the cryptographically relevant quantum computer (CRQC) horizon, and the migration effort horizon. The analysis uses only Chapter 1 concepts, but the framing carries through the whole book.

Skills applied

• Applying the harvest-now-decrypt-later threat model to a concrete data inventory (§1.14).
• Reasoning quantitatively about qubit requirements and their uncertainty (§1.6).
• Distinguishing Shor-vulnerable from Grover-weakened cryptography (§1.4, §1.14).
• Communicating a probabilistic technical timeline to non-technical decision makers (§1.13).

Background

The organization

Meridian Health's cryptographic footprint:

The three timelines

The board hears "experts disagree about when quantum computers will break encryption" and concludes the matter can wait. That inference is wrong, and showing why is the heart of this case study. Three separate clocks are running:

• $T_{\text{data}}$ — how long a given secret must stay secret.
• $T_{\text{CRQC}}$ — when a cryptographically relevant quantum computer exists.
• $T_{\text{migrate}}$ — how long it takes this organization to replace its cryptography.

Mosca's inequality: if $T_{\text{data}} + T_{\text{migrate}} > T_{\text{CRQC}}$, you are already too late. Note that it does not require knowing $T_{\text{CRQC}}$ precisely — only bounding it.

Phase 1: Classify the cryptography

From Chapter 1, the split is sharp:

Shor-vulnerable (broken outright): RSA-2048 certificates, ECDHE-P256 key exchange, ECDH-P256 VPN, RSA-2048 key wrapping and firmware signing. Shor's algorithm solves factoring and discrete log in polynomial time; these schemes do not survive a CRQC in any key size that is practical to deploy.

Grover-weakened (halved, not broken): AES-256 at rest. Grover's quadratic speedup takes the effective search cost from $2^{256}$ to $\approx 2^{128}$, which remains comfortably infeasible. AES-256 needs no replacement.

Finding 1. Every symmetric-at-rest system is fine. Every public-key system is not. The exposure is narrower and more specific than "our encryption is at risk."

Note the trap in the last row: backup tapes use AES-256 (safe) but with RSA-wrapped keys (not safe). An adversary who recorded the wrapped key needs only to break the RSA wrapper to obtain the AES key. The strength of a hybrid system is the strength of its weakest link, and inventories that record only the bulk cipher miss this.

Phase 2: Estimate $T_{\text{CRQC}}$ honestly

Chapter 1 gives the resource estimate: roughly 20 million noisy physical qubits to factor RSA-2048 in about eight hours, using surface-code error correction. Today's largest devices are in the 10²–10³ physical qubit range with no error correction.

The gap is four to five orders of magnitude in qubit count, plus the entire error-correction stack. Reasonable expert estimates cluster in the 2035–2045 range, with meaningful probability mass on both sides.

The correct way to present this to a board is as a distribution, not a date:

These are judgment calls, not measurements, and should be labeled as such. The roadmap must not depend on their precision — which is exactly the point of the next phase.

Finding 2. We cannot date the threat. We can bound it well enough to act, because the decision turns out to be insensitive to the exact date.

Phase 3: Apply Mosca's inequality

Take the genomics archive: $T_{\text{data}}$ is effectively indefinite, call it 50 years. Enterprise cryptographic migration for an organization this size is realistically $T_{\text{migrate}} = 5$–7 years.

$$T_{\text{data}} + T_{\text{migrate}} = 50 + 6 = 56 \text{ years} \gg T_{\text{CRQC}}$$

under any plausible estimate. The inequality is violated by decades, not months. Data being exfiltrated and stored today is exposed, regardless of which column of the probability table you believe.

Now take the staff VPN: $T_{\text{data}}$ is a session, minutes. $T_{\text{migrate}}$ is perhaps a year. The inequality is satisfied comfortably. VPN traffic is only at risk if an adversary is recording it and the session content stays sensitive for decades — which for routine administrative traffic it does not.

Finding 3. The urgency is not uniform. It is driven almost entirely by $T_{\text{data}}$, which the organization already knows, and not by $T_{\text{CRQC}}$, which nobody knows. This is what makes the roadmap defensible.

Phase 4: Sequence the work

Priority ordering falls out of the inequality directly:

Tier 1 — start now (violated by decades). Genomics archive key wrapping; backup tape key wrapping; patient records in transit where the content is long-lived. All are Shor-vulnerable protections over data with lifetime measured in decades. Migrate to ML-KEM (FIPS 203) in hybrid mode with the existing classical scheme, so that a break of either component alone is survivable.

Tier 2 — begin within 24 months (long-lived, but bounded). Medical device firmware signing. Devices deployed in 2027 will be in service until ~2040, and a signing key compromise then means forged firmware updates on life-critical equipment. Migrate to ML-DSA (FIPS 204) or SLH-DSA (FIPS 205); the large signature sizes of SLH-DSA matter here because embedded devices have constrained flash.

Tier 3 — routine refresh cycle. TLS certificates for public-facing services, staff VPN. Follow browser and OS vendor timelines rather than leading them.

Tier 0 — prerequisite for all of the above. A cryptographic inventory. Meridian cannot migrate what it cannot find, and the table above is certainly incomplete: it omits third-party medical devices, vendor SaaS integrations, and any hard-coded certificates in legacy systems. In practice, discovery is the longest pole in the tent.

Phase 5: What not to do

The roadmap should explicitly rule things out, because vendors will propose them:

• Do not buy quantum hardware. Nothing in this analysis is solved by owning a quantum computer.
• Do not deploy QKD. Quantum key distribution (Chapter 10) solves key exchange over dedicated fiber with specialized hardware; it does not address the certificate, signing, or data-at-rest problems, and it does not fit a multi-site hospital network. Post-quantum cryptography, which is software, does.
• Do not wait for "the standards to settle." FIPS 203, 204, and 205 have been final since August 2024. The waiting is over.
• Do not abandon AES-256. It is fine. Effort spent replacing it is effort not spent on the RSA key wrappers that actually matter.

Discussion Questions

1. Mosca's inequality requires no precise estimate of $T_{\text{CRQC}}$. Explain to a skeptical CFO why "nobody knows when" is an argument for acting rather than against it.
2. The backup tapes were the subtlest finding. What other hybrid constructions would an inventory likely miss?
3. If a breakthrough halved the qubit requirement for factoring next year, which tier of the roadmap changes? Does the ordering change at all?
4. Meridian's competitor announces it has "quantum-proofed" its infrastructure in six months. What would you infer?

Your Turn: Extensions

• Build the same table for your own organization or a system you know. The exercise is usually uncomfortable.
• Compute Mosca's inequality for three data classes with lifetimes of 1, 10, and 40 years, using $T_{\text{migrate}} = 5$ and a $T_{\text{CRQC}}$ of 2040. Identify the crossover lifetime.
• After Chapter 30, revisit the Tier 2 recommendation and justify choosing between ML-DSA and SLH-DSA on signature size and security-assumption grounds.

Key Takeaways

• The quantum threat to cryptography is dated by your data lifetime, not by hardware forecasts.
• Shor breaks public-key cryptography outright; Grover only halves symmetric key strength. Triage accordingly.
• Hybrid constructions hide public-key exposure underneath symmetric ciphers — inventory the key wrapping, not just the bulk cipher.
• Mosca's inequality converts an unanswerable question ("when?") into an answerable one ("how long must this stay secret, and how long will migration take?").
• The right response to quantum computing for most organizations is a cryptography project, not a hardware purchase.