NIST’s Post-Quantum Cryptography Standards Are Final: Why “Harvest Now, Decrypt Later” Is Now a Board-Level Data Liability

• NIST has published its first post-quantum cryptography standards—FIPS 203, FIPS 204, and FIPS 205—standardizing ML-KEM (key establishment), ML-DSA (digital signatures), and SLH-DSA (stateless hash-based signatures) for use in engineered migration programs rather than research-only pilots.
• “Harvest now, decrypt later” (HNDL) turns today’s encrypted exfiltration into a deferred disclosure risk if long-lived records are decrypted in the future, pulling cryptography decisions into governance, legal, and audit scope.
• Organizations with long retention horizons (e.g., financial services, healthcare, legal) should prioritize a cryptographic asset inventory, map data confidentiality lifetimes, and identify the specific exposure paths where encrypted material can be captured and stored.
• Most real-world transitions will be phased and interoperability-driven; hybrid approaches (classical + PQC) and crypto-agile designs reduce risk while ecosystems and dependencies catch up.
• A practical near-term control is reducing retrospective exposure by re-wrapping or selectively re-encrypting stored data so historical archives are not protected solely by cryptography likely to be deprecated.

Why PQC suddenly matters to boards (not just security teams)

For years, post-quantum cryptography (PQC) was framed as future-proofing. That changed when NIST published its first PQC standards: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for digital signatures, and FIPS 205 (SLH-DSA) for stateless hash-based signatures.

Standards publication does not mean every system must switch immediately. It does mean PQC is no longer a speculative line item; it is now an engineering and governance program with definable scope, controls, testing, and vendor requirements. Boards are accountable for material cyber risk, including the risk that encrypted data stolen today becomes readable later—particularly when the data’s confidentiality value lasts longer than the cryptography protecting it.

What “harvest now, decrypt later” means in operational terms

“Harvest now, decrypt later” describes an adversary capturing encrypted traffic or exfiltrating encrypted datasets now, then storing the ciphertext for future decryption when capabilities improve. NIST explicitly discusses this risk in its PQC migration guidance, noting that data encrypted today may need protection against future quantum adversaries.

The operational consequences are complex because many organizations have:

• Long-lived sensitive data (patient histories, financial records, privileged communications) that must remain confidential for many years.
• Backups and archives that outlive production systems and often have weaker monitoring and access controls.
• Opaque cryptographic dependencies embedded in commercial software, SaaS platforms, appliances, and third-party integrations.
• Public-key cryptography in critical paths (e.g., TLS handshakes, PKI, identity, code/document signing), where algorithm transitions can break interoperability.

The board-level issue is not predicting a specific date for cryptanalytically relevant quantum computers. The issue is whether the organization is already holding—or transmitting—data whose required confidentiality lifetime exceeds the expected safe lifetime of the public-key algorithms used for key exchange and signatures.

Why banks, hospitals, and law firms are “on the clock”

Banks and financial services: retention, fraud, and systemic exposure

Financial institutions retain transaction histories and customer records for extended periods and operate complex vendor ecosystems (core banking, payments, KYC/AML, data analytics) where cryptography is pervasive but difficult to map end-to-end. If encrypted backups or partner traffic are harvested, later decryption can expose high-volume historical records, amplifying legal, regulatory, and reputational impact.

Hospitals and health systems: PHI longevity and archival reality

Health systems handle inherently long-lived data distributed across EHR platforms, billing systems, imaging archives, research environments, and data exchanges. Even when production is modernized, archival stores and legacy interfaces can preserve older cryptographic assumptions, making encrypted backup theft a potential deferred PHI disclosure event.

Law firms: privileged data that stays valuable

Legal matter files, privileged communications, M&A archives, IP, and litigation strategy can retain sensitivity indefinitely. The HNDL risk is acute because the value of historical ciphertext can remain high for a long time, and the impact of later decryption can extend beyond the firm to clients, counterparties, and outcomes.

From algorithms to accountability: what a defensible PQC program looks like

A common mistake is treating PQC migration as primarily an algorithm selection exercise. Standards help, but the hard problem is knowing where cryptography exists, what it protects, and how quickly you can change it without breaking operations. A defensible, board-readable plan typically includes five layers.

1) Build a cryptographic asset inventory (where crypto actually lives)

You cannot migrate what you cannot enumerate. The inventory should identify:

• Where public-key cryptography is used for key establishment, authentication, and signatures (e.g., TLS/mTLS, VPNs, API gateways, service mesh, code signing, document signing).
• Where data-at-rest encryption depends on envelope encryption and key wrapping patterns tied to a KMS, HSM, or PKI.
• Third-party and SaaS dependencies: which vendors terminate TLS, manage certificates, or store encrypted archives on your behalf.
• Hardware constraints: HSMs, smart cards, embedded systems, and endpoints that may lag in algorithm support.

The goal is a map from cryptography to business processes, not just a list of ciphers. Leadership needs to see where breakage and exposure concentrate if algorithms must change on a compressed timeline.

2) Classify data by confidentiality lifetime (how long must it stay secret)

Not all data requires the same secrecy horizon. A pragmatic approach is to label major data classes by how long compromise would be material:

• Ephemeral (minutes/days): short-lived session data, transient operational telemetry.
• Medium-lived (months/years): standard business records and typical customer interactions.
• Long-lived (years/decades): medical histories, financial histories, privileged archives, high-value IP.

This classification drives sequencing: which systems must migrate earliest and which data stores justify re-encryption or re-wrapping to reduce retrospective disclosure risk.

3) Identify “harvestable” exposure paths

Focus on where adversaries can realistically capture encrypted material today:

• Backups and archives stored offsite, replicated across environments, or placed in object storage.
• Interceptable traffic across partner links, remote access channels, and third-party integrations.
• Centralized repositories (data lakes, document systems) that concentrate sensitive records behind a small number of keys.

This step frequently shows that the most urgent PQC work is not in greenfield applications, but in storage, key management, identity/PKI, and vendor-managed edges.

4) Plan migration with hybrid deployments to maintain interoperability

In most enterprises, migration will be phased because some systems and partners can adopt new algorithms quickly while others cannot. NIST’s migration guidance anticipates staged approaches and emphasizes planning and agility for transitioning to PQC, including addressing dependencies and interoperability across systems and vendors (PQC migration project).

Practically, hybrid designs can reduce risk while preserving compatibility:

• Hybrid key establishment: combining classical and PQC-derived key material so an attacker must defeat both to recover session keys (where supported by the protocol stack and endpoints).
• Layered signature strategies: maintaining existing signature schemes while adding PQC signatures for higher-assurance artifacts (e.g., firmware or code signing) as verification ecosystems mature.
• Crypto agility: designing configurations and interfaces so algorithms can be swapped without redesigning applications.

The board-level takeaway: migration is staged risk reduction with operational constraints, not a one-time cutover.

5) Re-encrypt or re-wrap stored data (so old breaches don’t become new disclosures)

The core mitigation for HNDL is ensuring that historical stores do not remain protected solely by public-key cryptography that may be deprecated. Depending on architecture, this may involve:

• Re-wrapping data encryption keys under updated key-encryption keys (KEKs), minimizing data movement while improving forward posture.
• Selective re-encryption of high-value archives and backups aligned to long-lived data classes.
• Key rotation and lifecycle tightening to limit blast radius if older key material is later exposed or becomes vulnerable.

This is also where programs uncover “unknown unknowns”: legacy backup formats, inconsistent encryption settings, orphaned keys, and third-party-held copies.

Governance: turning PQC into an auditable vendor and enterprise requirement

Even organizations outside the U.S. federal environment are likely to feel downstream effects through procurement and customer expectations. When major customers begin requiring evidence of quantum-readiness, vendors and internal teams need a verifiable posture: which standardized algorithms are supported, where they are deployed, how cryptographic controls are tested, and how exceptions are tracked.

A governance-ready approach typically includes:

• Policies defining approved algorithms and deprecation timelines aligned to data confidentiality lifetime.
• Supplier requirements for cryptographic transparency: algorithm support, certificate and key handling, migration commitments, and testing evidence.
• Controls and testing integrated into CI/CD and infrastructure-as-code to prevent regressions and configuration drift.
• Metrics executives can track: percent of systems inventoried, percent of long-lived stores re-wrapped/re-encrypted, percent of external connections upgraded, and exception counts with deadlines.

Common failure modes (and how to avoid them)

• Assuming “TLS is handled by the platform.” TLS termination is often distributed across load balancers, gateways, service mesh sidecars, CDNs, and SaaS edges—each with its own upgrade cycle and cryptographic constraints.
• Ignoring backups. Backups can be both highly “harvestable” and expensive to remediate retroactively.
• Focusing only on confidentiality. Signatures and PKI matter too: identity, software supply chain integrity, and nonrepudiation failures can be just as damaging.
• No crypto agility. Hardcoded algorithms and brittle integrations turn migration into a multi-year rewrite rather than a managed transition.
• Weak evidence. Without inventory, testing, and repeatable controls, “quantum-safe” becomes an assertion rather than an auditable posture.

What to do in the next 90 days

1. Kick off a cryptographic asset inventory spanning applications, infrastructure, endpoints, and third parties, with ownership and a single source of truth.
2. Define data confidentiality lifetimes for major record types and map them to systems and storage locations.
3. Prioritize top exposure paths: archives, backups, and high-volume external traffic where harvesting is most plausible.
4. Establish a migration architecture that supports hybrid deployments, crypto agility, and PKI/protocol upgrade paths.
5. Create an evidence plan: automated checks, configuration baselines, and reporting that can answer customer, auditor, and regulator questions.

Sources (for verification)

• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)
• NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)
• NIST FIPS 205: Stateless Hash-Based Digital Signature Standard (SLH-DSA)
• NIST CSRC: Migration to Post-Quantum Cryptography (project guidance)