Ask a CISO when their organization is migrating to post-quantum cryptography and you will usually get a version of the same answer. Soon. When the vendors ship it. When NIST finalizes guidance. The problem with that answer is that NIST already finalized the core guidance, more than two years ago now, and the vendors who sell the client-facing fix are not the ones who can tell you where RSA-2048 and ECDSA are actually running inside your environment. You are.
Post-quantum migration gets filed under future cryptography work because the scary part, a quantum computer that can actually break current public-key algorithms, does not exist yet. That framing is backwards. The part of this that is hard, slow, and overdue is not cryptographic. It is an inventory and architecture problem, and it is one your infrastructure and security engineering teams can start this quarter without hiring a single cryptographer.
Why the Clock Already Started
NIST published its first three post-quantum standards on August 13, 2024. FIPS 203 defines ML-KEM, a key-encapsulation mechanism derived from CRYSTALS-Kyber, with parameter sets ML-KEM-512, 768, and 1024. FIPS 204 defines ML-DSA, a lattice-based signature scheme derived from CRYSTALS-Dilithium. FIPS 205 defines SLH-DSA, a hash-based signature scheme derived from SPHINCS+ that exists specifically because it does not depend on the same lattice math as the other two, a conservative fallback in case that math has a weakness nobody has found yet.
That is the commercial side. On the national security side, NSA's CNSA 2.0 suite is more specific and more demanding. It mandates the largest parameter sets only, ML-KEM-1024 for key establishment and ML-DSA-87 for signatures, and NSA's own guidance states that SLH-DSA is not approved for use on National Security Systems at all. CNSA 2.0 also sets a concrete near-term marker. Beginning January 1, 2027, new National Security System acquisitions have to support CNSA 2.0 algorithms, meaning a system delivered after that date without that support is noncompliant on day one. That date applies to defense and national-security-adjacent procurement, not to commercial enterprises broadly, so do not read it as your deadline. But it tells you how seriously the people writing military procurement requirements are treating this timeline, and that should recalibrate how seriously the rest of us treat it. Industry sources describe later full phase-out milestones for legacy algorithms in the early 2030s, but they do not agree with each other on the exact year, so treat 2027 as the one concrete date worth anchoring on and everything after it as directional.
The harder reason this is urgent has nothing to do with any of those dates. It is the standard industry framing of harvest now, decrypt later. An adversary with the patience and storage budget to do it can capture encrypted traffic today and sit on it until a quantum computer capable of breaking today's key exchange exists. If that is a realistic threat to any of your long-lived sensitive data, the exposure window is not years away. It opened the day that data was encrypted with an algorithm that will eventually be breakable.
What a Cryptographic Inventory Actually Is
You cannot migrate what you cannot find, and most enterprises cannot find most of it. An Entrust/Ponemon 2026 survey, vendor-sponsored and worth reading with that caveat, found that only 38 percent of organizations are actively preparing for post-quantum migration. The gap is not willpower. It is visibility. One Fortune 100 company speaking at RSAC 2026 said that despite running a dedicated PQC program, it had only 50 percent visibility into its own cryptographic inventory. That is a single anecdote from a vendor blog, not a verified industry statistic, but it matches what most architecture reviews turn up once someone actually looks.
A cryptographic inventory is exactly what it sounds like. A record of what algorithm, key length, and protocol is protecting what data, where, and who owns it. That includes the obvious places, TLS termination points, VPN concentrators, load balancers, and certificate authorities. It also includes the places nobody checks by habit. Embedded systems and OT devices that were commissioned a decade ago and never get a security review because they still work. Third-party software and SaaS integrations where you have no visibility into what the vendor uses internally. Code that hardcodes a specific cipher suite instead of calling a configurable library. Backup and archival systems where data encrypted five years ago is still sitting there, still a harvest-now target, long after the system that created it was decommissioned.
NIST published crypto-agility guidance as CSWP 39 in December 2025, and a source summarizing it identified the inventory gap as the primary barrier organizations face before they can even start migrating. That is consistent with what we see in architecture engagements. Teams default to waiting for vendor roadmaps precisely because they have not done the unglamorous work of finding out what they actually run.
Crypto-agility is the other half, and it is purely an engineering discipline. It means building systems so the underlying algorithm can be swapped without re-architecting the application around it, typically through an abstraction layer rather than a cipher name hardcoded into application code. A service that calls a configurable TLS library and negotiates its cipher suite can adopt a new algorithm with a config change and a rolling restart. A service that pins a specific curve inside custom code needs a development cycle, a test cycle, and a deployment window for every future algorithm transition, not just this one.
What This Looks Like in the First Quarter
A comprehensive cryptographic inventory for a large enterprise with legacy infrastructure is typically estimated at three to six months of work, an industry estimate rather than a guaranteed timeline, and it does not require a cryptography specialist to start. It requires the same discovery discipline your architecture team already applies to asset management and attack surface mapping.
Start with automated discovery of TLS endpoints across your external and internal attack surface, recording protocol version, cipher suite, and certificate authority for each one. Extend that to VPN concentrators, API gateways, and internal service mesh configurations where mutual TLS terminates. Pull a list of embedded and OT devices separately, because network scanners miss devices that do not respond the way servers do, and cross-reference it against procurement and asset management records rather than relying on the scan alone. Build a single record per asset that captures the algorithm, key length, protocol, system owner, and data sensitivity, so that when a migration path becomes clear you already know which systems matter most.
In parallel, set a crypto-agility standard for anything new. Require that new builds call cryptographic primitives through a configurable library or abstraction layer, never a hardcoded cipher name, and require that TLS configurations support algorithm negotiation rather than pinning to a single suite. That single architectural rule costs nothing extra on a new build and saves a rebuild later.
Where Teams Get This Wrong
The most common mistake is waiting for a vendor to ship a "quantum-safe" product and treating that as the starting gun. The inventory and crypto-agility work does not depend on any vendor roadmap, and doing it now is what lets you adopt whatever that vendor eventually ships without a scramble. The second mistake is scoping the inventory to public-facing TLS only, because that is what a scanner can see easily, and missing the embedded systems, third-party dependencies, and internal service-to-service traffic where the real exposure usually lives. The third is treating this as a checkbox compliance exercise with no named owner, which guarantees it stalls the moment the person who started it moves to another project.
The Close
Nothing about this requires you to know what a lattice problem is. It requires you to know what your organization encrypts, where, and with what, which is an architecture and engineering exercise your team can run today. The algorithms will keep evolving. The inventory you build now is the asset that makes every future transition, this one and the ones after it, something you execute instead of something you scramble to react to.
Related Service
Learn more about how we can help with Security Architecture & Advisory.
Explore Security Architecture & Advisory Services →
