Quantum-Safe Cryptography for Pharma: The Post-Quantum Migration Timeline

Why Pharma Cannot Wait for Q-Day

The phrase “post-quantum cryptography” invites a comforting mental shortcut: this is a future problem, and future problems can be scheduled around near-term priorities. For most industries that shortcut is defensible. For pharmaceutical and biotech organizations, it is not.

Two features of pharma data make the threat immediate rather than eventual. The first is retention. FDA regulations under 21 CFR 312.62(c) require investigator retention of clinical study records for at least two years after marketing application approval, and ICH GCP effectively extends that to a minimum of fifteen years in many cases. Sponsors routinely contract for twenty-year retention on pivotal trials, and manufacturing batch records and quality events sit on similar horizons.⁵ Any encrypted material that leaves a pharma network today is expected to remain confidential well past 2040.

The second feature is adversarial. Nation-state and financially motivated groups have targeted pharmaceutical intellectual property for more than a decade, from MenuPass and APT41 campaigns aimed at drug research and clinical trial data to coordinated attacks on COVID-19 vaccine cold chains and infrastructure.⁶ These actors have the patience and storage capacity to run “harvest now, decrypt later” campaigns: intercept encrypted transmissions or exfiltrate encrypted archives today, park them, and decrypt them once a cryptographically relevant quantum computer becomes available.⁷

The math is uncomfortable. A clinical dossier transmitted in 2026, protected by RSA-2048 or ECC over TLS, will still be under retention obligation when the expert consensus predicts those algorithms will be breakable. The intellectual property in a preclinical filing today may still be commercially relevant when a determined adversary can decrypt what they harvested a decade earlier. The World Economic Forum framed this bluntly in September 2025: for pharma and life sciences, “a decade-long clinical trial overlaps with projected CRQC timelines, putting sensitive results within reach of adversaries.”¹

The NIST Standards and the CNSA 2.0 Timeline

The good news is that the algorithms are no longer a moving target. After an eight-year evaluation process that began in 2016, NIST finalized three post-quantum cryptography standards in August 2024. These give pharma organizations concrete targets to migrate toward rather than theoretical constructs to argue about.³

The three finalized NIST standards

The engineering consequences are practical. ML-KEM-768 transmits roughly 1,184 bytes of public key and 1,088 bytes of ciphertext, and ML-DSA-65 signatures are about 3,309 bytes compared to 64 bytes for ECDSA P-256. Certificate sizes grow from roughly 1 KB to 4-5 KB, and TLS handshakes carry an additional ~2.27 KB of overhead compared to X25519. The CPU cost is negligible in most cases, but any protocol, appliance, or embedded system with tight bandwidth or record-size assumptions needs to be tested.⁹

CNSA 2.0: the federal timeline that shapes everything else

The NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) is not directly binding on pharmaceutical companies, but its schedule shapes the federal procurement, cloud services, and TLS ecosystem that pharma depends on. The key milestones:^{4 10}

Executive Order 14144, signed in January 2025 and substantially amended by EO 14306 in June 2025, preserved the PQC urgency of the earlier framework while streamlining agency oversight to NSA and OMB. CISA published its list of quantum-safe product categories on January 23, 2026, classifying commercial technology into “Widely Available” and “Transitioning” tiers.¹¹ The signal to industry is clear: PQC is not experimental, and procurement conversations from 2027 forward should assume PQC capability as a baseline expectation, not an optional feature.

GxP System Implications: Validation, Change Control, and Data Integrity

Every cryptographic algorithm change touches a GxP validated system somewhere in the pharma stack. TLS certificates protect LIMS-to-instrument connections. Digital signatures underpin 21 CFR Part 11 electronic records. HSM-backed keys sign batch release records. Cloud-provider TLS terminates on data-integrity-critical ingestion paths. The migration to PQC is therefore, unavoidably, a computer system validation event — but a diffuse one that traverses hundreds of systems rather than one big-bang project.

The 21 CFR Part 11 dimension

21 CFR Part 11 sets the criteria under which electronic records and electronic signatures are considered equivalent to paper. The regulation itself does not mandate any specific cryptographic algorithm; what it requires is that systems demonstrably preserve authenticity, integrity, and non-repudiation across the record lifecycle.¹² Digital signatures based on RSA or ECDSA satisfy the intent today. Once quantum computers can forge those signatures, the same systems will no longer satisfy the same intent — with respect to any record that must remain legally defensible after Q-Day.

The uncomfortable question, then, is not whether Part 11 requires PQC (it does not, explicitly) but whether Part 11 is satisfiable indefinitely by pre-quantum signatures on records that must survive into a post-quantum world. Regulators have not answered this in writing yet. Prudent quality organizations should assume the answer is no.

GAMP 5 change control

Under GAMP 5, changes to a validated system are assessed, approved, tested, and documented before implementation. GAMP 5 explicitly favors ongoing control based on risk over calendar-based revalidation, so the modern expectation is not to revalidate every system on a schedule but to reassess risk whenever functionality, configuration, data flow, or supplier responsibility changes.¹³

A cryptographic algorithm change is, in almost all cases, a supplier or configuration change. Whether it triggers full revalidation depends on where the change lands:

• TLS versions and cipher suites: generally infrastructure changes handled through the qualification of the infrastructure layer. A vendor moving from ECDHE-only to hybrid ML-KEM handshakes is normally not a Part 11 revalidation event.
• Digital signature algorithm in an e-signature workflow: higher risk. If the signature algorithm in a Part 11 signing chain changes, the audit trail, key-management, and non-repudiation controls all warrant reassessment.
• Code-signing chain on device firmware: requires coordinated updates across engineering, quality, and cybersecurity — and, for connected medical devices, alignment with FDA premarket cybersecurity guidance.¹⁴
• HSM and KMS root-of-trust migration: touches every downstream key, certificate, and encrypted archive. Effectively a program-level change.

Long-term data integrity: signatures on archived records

There is a subtler GxP problem than “how do we validate the new algorithm.” It is: how do we preserve the evidentiary value of records that were signed with pre-quantum algorithms, once those algorithms are broken? A batch release record signed with RSA-2048 in 2027 will still be under retention in 2040, when RSA-2048 may be forgeable. The signature will not automatically become invalid, but its evidentiary weight in a regulatory inspection or product-liability dispute is another matter.

The pragmatic answer, borrowed from long-term archival practice in other regulated industries, is to consider timestamped re-signing of critical archived records as part of a PQC transition. The originating signature remains as historical fact; a co-signature, using a PQC algorithm and a trusted timestamp, attests that the record existed and was accepted before Q-Day. This is not required by any current regulation, but it may be prudent for records with the highest evidentiary stakes — pivotal trial datasets, batch release records for approved products, safety database submissions.

CMO, CDMO, and Regulatory Exchange Encryption

Modern pharma is a network of encrypted exchanges. Sponsors send master batch records to CMOs. CDMOs return in-process and release data. CROs return case report forms, adverse event data, and imaging. Regulatory affairs teams push submissions through the FDA Electronic Submissions Gateway and the EMA CESSP portal. Almost none of this data goes over the open internet without TLS; almost all of it involves digital certificates from either commercial or FDA-issued certificate authorities.

According to industry reporting, 28% of life science organizations use five or more separate systems to exchange sensitive data with partners, and 68% of data breaches involve third-party vulnerabilities.¹⁵ Every one of those exchange points is a candidate for “harvest now, decrypt later” attack — often outside the sponsor’s direct control.

Where the exchange encryption lives

The contract layer: PQC obligations in supplier agreements

The most practical near-term lever is contractual. New and renewed master service agreements with CMOs, CDMOs, CROs, and IT vendors from 2026 forward should include specific PQC obligations: a commitment to inventory cryptographic assets, a migration roadmap aligned with CNSA 2.0 milestones, and audit rights to verify progress. This is not a technical control — it is a governance control. And it costs almost nothing to add in negotiation windows that are already open.

Legacy Devices, Instruments, and Embedded Systems

The hardest layer of the pharma cryptographic stack is not the cloud or the network — it is the equipment on the plant floor and in the lab. HPLCs, mass spectrometers, autoclaves, filling lines, environmental monitoring systems, PLCs, historian databases, medical-device manufacturing equipment, and QC instruments frequently run embedded operating systems and cryptographic libraries that were validated once, ten years ago, and have not been meaningfully touched since.

These systems share a set of properties that make PQC migration genuinely hard:

• Long operational lifespans. Many pharma manufacturing systems have 15-20 year lifespans. A device commissioned in 2018 may still be in production in 2033, straddling the entire CRQC risk window.¹⁷
• Constrained cryptographic environments. Embedded chips often lack the RAM or flash to accommodate ML-DSA signature verification code and expanded certificate chains. Vendors may need firmware updates, or in some cases hardware replacement.
• Validation lock-in. The system is validated as a unit. Swapping out a TLS stack triggers a formal change control, not a routine patch — and change control on a validated instrument is not a two-week exercise.
• Vendor lifecycle asymmetry. Some vendors will treat PQC as a paid feature upgrade. Others will treat it as a reason to end-of-life older instruments. Sponsors need to know which is which before their compliance windows close.

The hybrid transition pattern

The consensus deployment pattern for enterprise PQC in 2026 is hybrid: run classical and post-quantum algorithms in parallel, so a session is protected by both ECDH and ML-KEM simultaneously. An attacker needs to break both to compromise the connection.¹⁸ Hybrid deployment gives three things at once: safety if either algorithm has interoperability trouble, backward compatibility with legacy clients, and telemetry on handshake size, performance impact, and failure modes before pure PQC rollout.

For validated instruments and legacy systems that cannot immediately support pure PQC, the hybrid approach is the safest transition. It buys years of migration runway without leaving harvested traffic decryptable. It also lets quality organizations spread the validation work across multiple change-control cycles rather than a single high-risk cutover.

A PQC Readiness Assessment for Pharma

The most useful thing a pharma organization can do in the next twelve months is not to pick an algorithm or a vendor. It is to know where its cryptography actually lives. Most enterprises cannot answer that question because cryptography was implemented ad hoc across decades of system development and acquisitions.¹⁹ A PQC readiness assessment is fundamentally an inventory exercise, layered over a risk exercise.

Six domains to score

Organizations should score each domain on a simple maturity scale (unaware, aware, planned, in-progress, operational). The purpose is not to produce a beautiful heatmap. It is to force honest conversation with the CFO, CIO, CISO, chief quality officer, and general counsel about the fact that most of the map is currently blank.

A Five-Phase Migration Roadmap

The migration itself is a multi-year, multi-workstream program. Framing it as five sequential phases — rather than eighty parallel projects — gives leadership a chance to sequence spend and validation load. The phases are drawn from consensus industry practice and adapted for the regulated pharma context.²¹

Program economics

Realistic enterprise timelines from industry sources suggest cryptographic discovery and inventory across global infrastructure will take two to three years; risk assessment and prioritization roughly a year; governance six to twelve months; infrastructure upgrades phased over five to seven years; and application migration spanning eight to ten years.¹⁹ That range is defensible for a large pharma. For a mid-sized biotech with a focused system footprint, the top-end numbers compress meaningfully — but the discovery phase does not, because the vendor ecosystem is the same.

The Vendor Question Checklist

Most pharma organizations will migrate to PQC through their vendors, not around them. That makes the RFP and vendor-review process the single highest-leverage governance intervention available today. The questions below can be added to any technology, cloud, or instrument RFP or annual vendor review starting immediately.

For all vendors handling GxP or regulated data

1. What is your public position on NIST PQC standards (FIPS 203, 204, 205), and what is your roadmap for adopting them in the products or services we consume from you?
2. Do you publish or share a Cryptographic Bill of Materials (CBOM) for the components of your product or service that handle our data? If not, when will you?
3. Have you inventoried your reliance on RSA, ECC, DH, and ECDH across your product architecture, including certificate authorities, HSMs, TLS termination, code signing, and internal service-to-service communication?
4. Which of your products or services currently support hybrid classical/PQC TLS handshakes (for example, X25519 + ML-KEM), and on what schedule will the remaining products?
5. For digital signatures (code signing, document signing, JWT/SAML signing, e-signature workflows): what is your ML-DSA or SLH-DSA roadmap?
6. How is your PKI (internal CAs, intermediate CAs, code-signing CAs) preparing for PQC? Have you tested certificate chains with ML-DSA-signed intermediates?
7. What is your policy on cryptographic agility — the ability to swap algorithms without redeploying application code — and can you demonstrate it in your architecture?
8. How will you handle certificates and keys that were issued under classical algorithms during our contract term? What is the plan for re-issuance?
9. What is your position on CNSA 2.0 compliance, and do you commit contractually to alignment with its milestones for the categories that apply to your product?
10. For our GxP-validated deployments, how will you sequence PQC changes with our change control and release calendars, and what advance notice will you commit to?

Additional questions for instrument and connected-device vendors

1. What is the memory and processing headroom in the current hardware to accommodate ML-KEM/ML-DSA overhead? Will firmware updates suffice, or is hardware replacement required?
2. What is your PQC upgrade path for instruments currently deployed? Is it a covered firmware update, a paid feature, or an end-of-life event?
3. For long-lived embedded devices (10+ year lifespans), what is your commitment to PQC support through the end of expected operational life?
4. How does your device handle firmware code signing today, and what is the migration plan to ML-DSA or SLH-DSA signing?

Additional questions for cloud and SaaS providers

1. Does your public-facing TLS support hybrid PQC key exchange today, and if so, what percentage of client traffic actually negotiates it?
2. What is the roadmap for internal service-to-service communication, storage encryption at rest, and backup encryption?
3. Do your logs and observability tooling capture cryptographic agility signals (which algorithms are negotiated, failure rates)?
4. Where you rely on third-party cryptographic libraries and HSMs, what is your subcontractor migration schedule, and how is it audited?

Conclusion

Post-quantum cryptography is arriving on a schedule that is knowable and a threat vector that is already active. For pharma and biotech leaders, the operational reality is that the twenty-year retention profile of clinical, manufacturing, and safety data collapses the future threat into a present one: material transmitted today, protected by classical algorithms, is expected to remain confidential well past the window in which those algorithms are expected to be broken. Adversaries are aware of this, and they are collecting.

The response is not exotic. It is inventory, governance, vendor pressure, and disciplined multi-year sequencing against a set of NIST standards that are finalized and a CNSA 2.0 timeline that shapes the whole commercial ecosystem. Organizations that begin their cryptographic inventory and readiness assessment in 2026 will finish their migration on time. Organizations that wait for a regulator or a headline will finish it under duress, at higher cost, and with material amounts of legacy data left exposed.

Sakara Digital works with pharma and biotech organizations building the quality, IT, and regulatory foundations for AI-enabled and quantum-safe operations. If you are exploring how a PQC readiness assessment should be sequenced against your GxP validation calendar, your CMO/CDMO contract renewals, and your submissions roadmap — and you want an independent perspective on where to start — we are happy to have that conversation.