For most of your career, “encrypted” has meant “safe.” In 2026, that equation is breaking down for a specific and consequential class of data. The threat isn’t a quantum computer sitting on an attacker’s desk today — it’s the encrypted traffic and archives your organization is generating right now, which adversaries can intercept, store, and simply wait to decrypt once the technology catches up. This is the “harvest now, decrypt later” problem, and it’s the reason post-quantum cryptography has moved from academic curiosity to board-level priority in the space of two years.
The clock already started
In August 2024, the National Institute of Standards and Technology (NIST) finalized the first three post-quantum cryptography standards: FIPS 203 (ML-KEM, a key encapsulation mechanism derived from CRYSTALS-Kyber), FIPS 204 (ML-DSA, a digital signature standard derived from CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, a hash-based signature standard derived from SPHINCS+, intended as a structural backup in case ML-DSA is later found weak). A fourth standard, FIPS 206, based on the FALCON algorithm, is expected to follow. NIST has also signaled a deprecation path for RSA and elliptic-curve cryptography, with disallowance in NIST-validated systems targeted for 2035.
None of that would matter urgently if the risk only materialized the day a cryptographically relevant quantum computer (CRQC) came online. It doesn’t work that way. “Harvest now, decrypt later” describes a strategy — already attributed to well-resourced nation-state actors by multiple government cybersecurity authorities — of intercepting and archiving encrypted data today, banking on future decryption capability to unlock it retroactively. Estimates for when a CRQC becomes practical vary and cluster loosely in the early-to-mid 2030s, but the exact date is beside the point. Any data with a confidentiality shelf life longer than roughly eight to ten years — health records, intellectual property, government and defense communications, long-dated financial and contractual data — is exposed under today’s encryption the moment it’s intercepted, not the moment quantum decryption arrives.
That reframing is what has pulled PQC out of research roadmaps and into 2026 budget conversations. The migration decision isn’t “when do we need to be quantum-safe,” it’s “how much of our current data can we afford to have exposed retroactively while we get there.”
Zero trust and PQC are converging on the same infrastructure
The urgency around PQC is compounding with a parallel shift already underway: zero-trust adoption. Industry surveys consistently show a large majority of organizations — commonly cited around four in five — now treat zero trust as essential architecture, even though full, mature implementations remain a minority. Identity and access management continues to account for the largest share of zero-trust investment, as organizations move toward continuous verification instead of perimeter-based trust, driven by remote work, SaaS sprawl, API-driven systems, and increasingly autonomous AI workloads that don’t fit the traditional model of a predictable human user or service account.
This matters for PQC planning because the two initiatives touch the same technical substrate: public key infrastructure, TLS termination points, identity providers, hardware security modules, VPN and network segmentation layers. A zero-trust rollout that re-architects identity and network trust boundaries is, in practice, also an opportunity to introduce crypto-agility into those same components — rather than treating PQC migration as a second, disconnected multi-year program competing for the same engineering time and the same PKI touchpoints. Security and platform teams that sequence these two initiatives together, rather than in isolation, reduce both cost and coordination risk.
Why this isn’t a vendor purchase
It’s tempting to treat PQC readiness as a checkbox: buy a quantum-safe VPN appliance, update a TLS library, declare victory. Government and industry guidance converges on a different reality. Joint guidance from CISA, the NSA, and NIST frames PQC migration as a structural program, not a patch: it starts with a cryptographic inventory — identifying every place cryptography actually lives across TLS termination, code signing, identity and access management, HSMs, mobile applications, and third-party SDKs — because most organizations don’t have a reliable answer to “where is RSA or ECC used in our stack” before they start.
From there, the work is prioritization by data sensitivity and confidentiality lifetime, not a uniform sweep. Data that needs to stay confidential for two years is a very different risk profile than data that needs to stay confidential for twenty. Full enterprise migration is realistically described as a five-to-fifteen-year program that touches PKI, identity, network, application, and procurement simultaneously — which is also why executive sponsorship and a named owner (some organizations are formalizing a “quantum readiness” role) show up repeatedly in enterprise guidance. Without a named owner, cryptographic migration competes for engineering time against every other roadmap item and consistently loses.
Crypto-agility is the real deliverable
The architectural concept doing the most work in serious PQC planning right now is crypto-agility: treating cryptographic algorithms as a replaceable abstraction layer rather than something hardcoded into applications, protocols, and certificates. This matters for a concrete reason — the standards themselves are still evolving. FIPS 206 is still pending. Real-world implementations are still surfacing edge cases in performance and interoperability. An organization that hardcodes ML-KEM the same way it once hardcoded RSA has solved today’s problem and recreated tomorrow’s.
In practice, most enterprises are approaching the transition through hybrid cryptography — combining classical algorithms (RSA/ECC) with post-quantum algorithms (ML-KEM/ML-DSA) in the same handshake or signature scheme. This protects against two distinct failure modes at once: it keeps systems safe against HNDL-style harvesting even before the classical algorithm is retired, and it hedges against the — currently low but non-zero — risk that a newly standardized PQC algorithm is later found to have a weakness of its own.
Concrete steps for software and security teams
The organizations making real progress in 2026 are following a broadly consistent sequence:
- Build a cryptographic inventory before buying anything. Map every place cryptography is used — TLS/mTLS endpoints, code signing pipelines, IAM and SSO providers, HSMs, VPN concentrators, mobile app crypto libraries, and every third-party SDK that touches sensitive data. Most teams are surprised by what surfaces here, especially in legacy services and vendor-managed components.
- Classify data by confidentiality lifetime, not just sensitivity. A dataset that only needs to stay secret for eighteen months is a lower HNDL priority than one — health data, IP, long-term contracts, government-adjacent data — that needs to stay secret for a decade or more. Prioritize migration work against that timeline, not a flat sensitivity label.
- Engage vendors on their PQC roadmaps now. Cloud providers, HSM vendors, and TLS library maintainers are at very different stages of ML-KEM/ML-DSA support. A dependency you don’t control can become the longest pole in your migration timeline — find out early rather than at renewal time.
- Design for crypto-agility, not a one-time swap. Abstract cryptographic algorithm selection out of application code and into configuration or a managed layer (certificate lifecycle management, centralized key management) so the next algorithm change — and there will be one — doesn’t require another multi-year re-architecture.
- Adopt hybrid cryptography as the default transition state. Combine classical and post-quantum algorithms in TLS and signing workflows where your stack supports it, rather than waiting for a single “flip the switch” migration event.
- Sequence PQC work alongside your zero-trust roadmap. Both initiatives touch PKI, identity, and network trust boundaries — plan the PKI and IAM re-architecture once, for both objectives, instead of twice.
- Name an owner and instrument progress. Track PQC coverage as a measurable metric — percentage of TLS endpoints, services, and certificates migrated — the same way you’d track any other multi-year platform initiative, so the program survives budget cycles and leadership changes.
The decision in front of technical leaders
Post-quantum cryptography isn’t mainstream in 2026 because quantum computers arrived. It’s mainstream because the standards are finalized, the regulatory deprecation timeline for classical algorithms is public, and the exposure window for long-lived sensitive data is already open. Enterprises that treat this as a procurement decision will spend the next several years reacting to vendor timelines they don’t control. Enterprises that treat it as what it actually is — a crypto-agility and systems-architecture initiative that overlaps heavily with the identity and zero-trust work already on the roadmap — will be the ones with a defensible answer when a customer, regulator, or board member eventually asks: what happens to the data we encrypted five years ago?
Luby Software works with engineering and security teams building and modernizing enterprise systems across financial services, healthcare, and SaaS — the exact sectors where long-lived, high-sensitivity data makes the harvest-now-decrypt-later threat concrete rather than theoretical. If your team is starting a cryptographic inventory or evaluating where crypto-agility fits into a broader modernization roadmap, that’s a conversation worth having before the next procurement cycle, not after.