The algorithm decision is already made. NIST made it for you when it published FIPS 203 in August 2024 and named ML-KEM the standard mechanism for establishing a shared secret key that survives a quantum computer.
So why are most security teams still stuck?
Because the hard part of post-quantum cryptography migration was never the math. It is the inventory. You cannot replace what you cannot see, and almost no one can produce a current, accurate list of where their quantum-vulnerable cryptography actually runs. TLS terminators, code-signing pipelines, VPN concentrators, hardware roots of trust, embedded device keys baked in at the factory. The crypto is everywhere and it is documented nowhere.
This piece is about that gap. Not the lattice theory. The operational sequence: how you build a cryptographic inventory that holds up under audit, how you map it to the deadlines that are now counting down, and how you keep it true after the spreadsheet goes stale the day you save it.
What did FIPS 203 actually standardize, and why does the one-year mark matter now?
FIPS 203 is the Module-Lattice-Based Key-Encapsulation Mechanism Standard. It specifies a single mechanism, ML-KEM, that lets two parties establish a shared secret key over a public channel. That shared secret then feeds your symmetric crypto for encryption and authentication. In the standard's own framing, a KEM is a set of three algorithms: KeyGen, Encaps, and Decaps.
The reason this matters: the key-establishment schemes most of your stack relies on today, the ones specified in NIST SP 800-56A and SP 800-56B, are vulnerable to attacks from a sufficiently capable quantum computer. FIPS 203 says so directly. ML-KEM is the approved alternative, and its security rests on the computational difficulty of the Module Learning With Errors problem, which is presently believed to be hard even for an adversary holding a large-scale fault-tolerant quantum computer.
ML-KEM ships in three parameter sets, in order of increasing security strength and decreasing performance:
→ ML-KEM-512 — security category 1 → ML-KEM-768 — security category 3 → ML-KEM-1024 — security category 5
All three are approved to protect sensitive, non-classified communication systems of the U.S. Federal Government. The algorithm itself is derived from CRYSTALS-KYBER, the candidate NIST selected through its Post-Quantum Cryptography Standardization project.
The one-year mark matters because the standard is no longer a draft you can defer. It is published, citable, and validatable. Federal applications already have a "shall use" obligation for approved key establishment, and the private-sector regulatory and contractual pressure that follows federal crypto standards is now arriving on schedule, not in theory.
Why is a cryptographic inventory the first move, and what makes it harder than an asset scan?
A cryptographic inventory is the prerequisite for everything else. Migration planning, risk prioritization, auditor evidence, board reporting. None of it is possible without a defensible answer to one question: where do we use which cryptography, for what, and how long does that data need to stay confidential?
An asset scan tells you what machines exist. A cryptographic inventory tells you what algorithms those machines negotiate, which is a different and harder problem.
What breaks a naive inventory:
→ Crypto is negotiated, not configured. A TLS endpoint does not "have" an algorithm. It offers a menu and agrees one per handshake. Your inventory has to capture what is actually negotiated in production, not what the config file theoretically permits.
→ Keys outlive systems. A code-signing key issued five years ago still validates artifacts today. A root CA private key may have a twenty-year horizon. The asset that generated the key may be long decommissioned while the key's blast radius is still live.
→ Embedded and third-party crypto is opaque. Firmware, IoT devices, appliances, and SaaS dependencies carry cryptography you did not choose and frequently cannot change. You still own the risk.
→ The standard's own caveat applies to your estate. FIPS 203 is explicit that conformance to the standard does not by itself ensure that a particular implementation is secure. Inventorying "we use ML-KEM" is not the finish line. How it is implemented, how randomness is generated, how keys are destroyed, all of that is on the implementer.
That last point is operational, not academic. FIPS 203 requires that the randomness feeding KeyGen and Encaps come from an approved random bit generator with a security strength matched to the parameter set: at least 128 bits for ML-KEM-512, at least 192 bits for ML-KEM-768, and at least 256 bits for ML-KEM-1024. It also requires that the decapsulation key be kept private and destroyed when it is no longer needed. An inventory that records the algorithm but ignores the RBG and key-destruction posture is recording a label, not a control.
How do the CNSA 2.0 timelines (2030 / 2035) translate into work you must start this year?
The deadlines that frame migration urgency are not in FIPS 203 itself. They come from NSA's Commercial National Security Algorithm Suite 2.0 and the broader industry guidance that has formed around it. The commonly cited shape: NSA's CNSA 2.0 guidance points organizations toward beginning quantum-resistant adoption through the late 2020s, with a target of exclusive reliance on post-quantum algorithms across national-security systems by 2035, and earlier dates for specific categories such as software and firmware signing around 2030.
Treat those as directional context, not as numbers from the FIPS 203 text. What is not directional is the arithmetic.
If sensitive data you transmit today must stay confidential for ten years, and a migration program realistically takes three to five years across a large estate, then data encrypted in 2026 under a quantum-vulnerable key is already inside the window where it could be harvested now and decrypted later. The deadline is not when quantum computers arrive. It is when your data's confidentiality requirement minus your migration duration crosses today's date.
Run the sequence:
- Classify by confidentiality lifetime. For each data category, record how long it must remain secret. Health records, trade secrets, M&A files, and state-adjacent data routinely exceed a decade.
- Subtract your realistic migration duration. Be honest about scale. An enterprise with embedded systems and third-party dependencies is not migrating in eighteen months.
- Flag everything where lifetime minus migration time is already negative. That is your harvest-now-decrypt-later exposure, and it is the work that cannot wait for a 2030 or 2035 calendar entry.
- Map the rest to the external timelines so signing infrastructure and key-establishment channels line up with the dates your sector and contracts will enforce.
The work that starts this year is steps one and two. They require no new algorithms, no vendor, and no budget line. They require the inventory.
Where is quantum-vulnerable crypto hiding in your estate, TLS, code-signing, VPNs, and embedded keys?
The honest answer is: in more places than your last architecture diagram shows. The four that consistently surprise teams:
→ TLS everywhere. Not just your front-door web servers. Internal service mesh, database connections, message brokers, load balancer backends, and every API call between microservices negotiates key establishment. The quantum-vulnerable step is the key exchange, which is precisely what ML-KEM replaces.
→ Code-signing and firmware-signing. This is the highest-leverage hiding spot. A forged signature in a quantum future can authorize malicious code as trusted. Signing keys have long lifetimes and the verification chain often reaches deep into devices you no longer control.
→ VPNs and remote access. IPsec and TLS-based tunnels establish session keys on every connection. Long-lived configurations and appliance firmware make these slow to change.
→ Embedded and hardware keys. Keys provisioned into devices at manufacture, HSM-backed roots of trust, smart cards, and IoT fleets. These are often immutable in the field, which turns a migration problem into a hardware-refresh problem.
The discovery techniques differ per category: passive network observation for negotiated TLS, certificate and PKI inventory for signing chains, configuration extraction for VPN appliances, and SBOM plus vendor attestation for embedded and third-party crypto. No single scanner covers all four. A real inventory is a join across several sources, which is exactly why it tends to live as a stale spreadsheet.
How do you prioritize migration when you can't rip-and-replace everything at once?
You cannot migrate the whole estate at once, and you should not try. Prioritization is a function of two axes: the confidentiality lifetime of the data the cryptography protects, and the blast radius if that cryptography is broken.
A practical ranking:
- Long-lived secrets in transit and at rest. Anything with a multi-year confidentiality requirement that traverses a network is harvest-now-decrypt-later bait. Highest priority.
- Signing infrastructure with downstream trust. Root and intermediate signing keys whose compromise lets an adversary forge trusted code or identities. High blast radius even if the data itself is short-lived.
- Authentication and session establishment for critical systems. The channels into your crown-jewel systems.
- Short-lived, low-sensitivity traffic. Ephemeral session data with no long confidentiality requirement. Migrate last.
Where you can, deploy hybrid key establishment, running a classical algorithm and ML-KEM together so the session is secure if either holds. This is the dominant transition pattern because it hedges against both a quantum break of the classical algorithm and an undiscovered weakness in the new one. FIPS 203 standardizes the ML-KEM component of that pairing; how you combine it with a classical KEM is an integration decision your inventory should record explicitly per channel.
What does crypto-agility mean in practice, and how do you prove it to an auditor?
Crypto-agility is the property that you can change cryptographic algorithms without re-architecting the systems that use them. It is not a product. It is a discipline that shows up in concrete places:
→ Algorithm choice is configuration, not hard-coded. → Key and certificate lifecycles are managed centrally, not per-application. → You can answer "what would break if we disabled algorithm X tomorrow" from data, not from a meeting. → Adding a new approved algorithm is a deployment, not a rewrite.
Proving it to an auditor is where most programs fall down, because the evidence is a moving target. An auditor does not want your migration slide deck. They want to trace a claim to a control to a current state. "We use ML-KEM-768 on this channel" needs to resolve to: which parameter set, what RBG strength behind it, how the decapsulation key is protected and destroyed, when the inventory entry was last verified, and which obligation that control satisfies.
That is a traceability problem, and it is the same shape as every other compliance traceability problem. The reason it is hard is that the underlying state changes constantly. Certificates rotate. Endpoints get reprovisioned. A spreadsheet captured last quarter is wrong this quarter, and an auditor who finds one stale entry stops trusting the whole document.
How can a source-grounded GRC platform turn the migration inventory into a living control, not a spreadsheet?
The migration inventory fails the moment it becomes a snapshot. The estate moves; the document does not. What you need is the inventory expressed as a continuous query against current state, mapped to the obligations that actually apply to you.
This is the model Aigis runs for regulatory obligations generally, and post-quantum migration is the same problem wearing a different hat. Every obligation traced to a verbatim quote from the source text. Every control bound to the obligation it satisfies. Every count derived from live data, not retyped into a slide.
Applied to crypto migration:
→ Your cryptographic estate maps to the requirements that govern it, with each requirement traced to its source, FIPS 203 for the ML-KEM specifics, your sector and contractual obligations for the deadlines. → The inventory is a query, so the dashboard cannot disagree with the underlying data, because it is built from it. → When a deadline moves or a new obligation lands, the affected controls re-materialize. Not a thirty-framework re-mapping. The clauses actually touched. → The audit pack is a query, not a project. When the assessor asks for your post-quantum posture, you run it.
Source-grounded, not AI-opinion. No AI hallucinations about which deadline applies. The migration stops being a one-time spreadsheet and becomes a posture you can defend in front of a regulator, a board, or a plaintiff.
For the mechanics of how the estate-to-obligation mapping works, see our notes on risk management, continuous compliance, and control mapping.
FAQ: ML-KEM, hybrid modes, and harvest-now-decrypt-later, answered
What is ML-KEM, in one line? It is the key-encapsulation mechanism standardized in FIPS 203 for establishing a shared secret key that is believed to remain secure against an adversary with a quantum computer. Its security is tied to the Module Learning With Errors problem. It comes in three parameter sets: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, at security categories 1, 3, and 5 respectively.
Should I deploy ML-KEM alone or in hybrid mode? Hybrid, in most cases. Running a classical key-establishment algorithm alongside ML-KEM means the session stays secure if either component holds. FIPS 203 standardizes the ML-KEM half; the pairing strategy is your integration decision, and your inventory should record which channels run hybrid versus pure ML-KEM.
What is harvest-now-decrypt-later, and is it really a 2026 problem? It is the strategy of capturing encrypted traffic today and decrypting it once a capable quantum computer exists. It is a 2026 problem for any data whose required confidentiality lifetime, minus your realistic migration duration, already crosses today. The threat model and the CNSA 2.0 timelines are NSA and industry guidance, not text from FIPS 203, but the arithmetic is yours to run.
Is conforming to FIPS 203 enough to call my crypto secure? No, and the standard says so. Conformance does not guarantee a secure implementation. You still owe an approved random bit generator at the matched security strength, correct private handling and destruction of the decapsulation key, and the required input checking on encapsulation and decapsulation. The algorithm is necessary, not sufficient.
See how Aigis maps your cryptographic estate to post-quantum deadlines as a continuous query. Start at agrc.ai.
