When NIST finalized its first post-quantum cryptography standards, many organizations heard a simple instruction: replace RSA and elliptic-curve cryptography with the new quantum-resistant algorithms. That framing is appealing because it sounds like a procurement decision with a clear endpoint. It is also wrong, or at least dangerously incomplete. You cannot replace what you cannot find, and most enterprises do not know where, how, and why they use cryptography across their estate.
This article argues that post-quantum (PQC) migration begins with an assessment, not an algorithm. The standards matter, the deadlines are real, and the harvest-now-decrypt-later threat is already in motion. But the first concrete step that every credible authority recommends is the same: build a cryptographic inventory and assess your exposure. We will cover why the timeline has become urgent, what the assessment-first approach involves, the risks of skipping it, and how to sequence a migration that is driven by evidence rather than by an algorithm name.
Why This Matters Now
Three forces have turned post-quantum migration from a research topic into a near-term program: the standards are finalized, the deprecation deadlines now carry policy weight, and the harvest-now-decrypt-later threat means sensitive data is already exposed. Together they make the timeline concrete rather than hypothetical.
The standards are final
The waiting period is over. On 13 August 2024, NIST released the final versions of its first three post-quantum standards: FIPS 203, FIPS 204, and FIPS 205. FIPS 203 specifies ML-KEM, a module-lattice key-encapsulation mechanism derived from CRYSTALS-Kyber, intended as the primary standard for general encryption. FIPS 204 specifies ML-DSA for digital signatures, derived from CRYSTALS-Dilithium, and FIPS 205 specifies the stateless hash-based signature scheme SLH-DSA, derived from SPHINCS+.
They became effective on 14 August 2024. The algorithms are no longer a research target; they are publishable, validatable standards. Adoption in the market is uneven: ML-KEM for key establishment is already shipping in major cloud platforms and browsers, while ML-DSA signature support lags, creating a half-migrated reality in which data in transit resists harvest-now-decrypt-later capture but authentication still leans on classical RSA and ECC.
The deadlines now have teeth
Standards came with a timeline. In November 2024 NIST published the initial public draft of NISTIR 8547, Transition to Post-Quantum Cryptography Standards, which sets out how quantum-vulnerable algorithms will be retired. The draft indicates that classical public-key algorithms providing 112 bits of security, such as RSA-2048, are to be deprecated after 2030 and disallowed after 2035, with the intent that all quantum-vulnerable public-key cryptography is phased out by 2035. For national security systems the schedule is more aggressive: the NSA’s CNSA 2.0 suite sets 2030 as the mandatory migration target for those environments.
Policy has reinforced the technical timeline. Executive Order 14306, issued in June 2025, directed CISA to publish a list of product categories where PQC-capable products are widely available, and CISA released that list in January 2026 to guide agencies toward PQC-capable procurement. The direction of travel for the wider market is unmistakable.
Harvest now, decrypt later means the clock already started
The most important reason not to wait is that adversaries do not have to. Under the harvest-now-decrypt-later threat, attackers capture encrypted data today and decrypt it once a cryptographically relevant quantum computer exists. Long-lived sensitive data such as regulated health records, financial histories, and multi-year contracts encrypted under RSA or ECC today is already at risk of future decryption. For any data whose confidentiality must outlast the arrival of quantum computing, the migration is not a future project; it is a current data-posture decision.
Why Assessment Comes First
Before choosing algorithms, it helps to understand why every credible roadmap front-loads discovery. Post-quantum migration is a replacement program rather than a patch, the authoritative guidance is unanimous that it begins with a cryptographic inventory, and that inventory is increasingly captured in a structured Cryptography Bill of Materials. The sections below take each in turn.
Migration is a replacement program, not a patch
The scale of PQC migration is unlike prior cryptographic transitions. Every asymmetric algorithm in use must eventually be replaced, and the new algorithms are not drop-in substitutes. PQC keys, signatures, and handshake messages are generally larger than their RSA or ECC equivalents, which affects certificate chains, bandwidth, latency, and HSM capacity.
Concretely, an ML-DSA-65 signature is roughly 3.3 KB and an ML-KEM-768 public key about 1.2 KB, against a 64-byte ECDSA P-256 signature and a 256-byte RSA-2048 key, so the overhead compounds across large certificate populations. NIST itself cautions that past transitions, such as moving away from SHA-1, took years and in some cases more than a decade, and that the PQC transition is larger because all cryptographic algorithms are in scope. A program of that magnitude cannot start with algorithm selection; it must start with knowing what is there.
Every authoritative roadmap starts with inventory
This is not a matter of interpretation. The joint guidance from CISA, NSA, and NIST on quantum readiness is explicit that establishing a quantum-readiness roadmap and preparing a cryptographic inventory is what enables an organization to begin the quantum risk assessment and provides visibility into where applications and functions depend on public-key cryptography. NIST’s NCCoE migration project is structured the same way: its first workstream is cryptographic discovery, focused on using inventory tools to learn where and how cryptography is being used to protect data and systems.
The federal mandate reflects the same logic. OMB memorandum M-23-02 directed agencies to inventory their cryptographic systems as part of the transition, and NISTIR 8547 reinforces that understanding current cryptographic use through an inventory is essential before prioritizing updates. Put plainly, the recommended sequence everywhere is discovered, then assess, then prioritize, then migrate.
Why discovery is genuinely hard
Cryptography is not conveniently catalogued. It is buried in application code, embedded in libraries, negotiated at runtime in protocol sessions, configured in deployment files, and baked into hardware. A cryptographic asset can be an algorithm with a specific key size and mode, a key or certificate, a protocol such as TLS or SSH, or the library that implements it. Capturing that spread requires tooling that can scan source, binaries, containers, network services, and cloud configuration, not a one-time questionnaire. This is exactly why the assessment is the hard part, and the algorithm choice is the easy part. Discovery, not algorithm selection, is where most of the program’s effort goes.
The Cryptography Bill of Materials
The emerging standard for representing this inventory is the Cryptography Bill of Materials, or CBOM. A CBOM is to cryptography what a software bill of materials is to software components: a structured, machine-readable inventory of every cryptographic asset and its relationships. The concept was spearheaded by the OWASP CycloneDX project as an extension of the SBOM standard, and native cryptographic support arrived in CycloneDX 1.6, now published as the ECMA-424 standard. Because a CBOM is a CycloneDX document, it slots into the tooling and pipelines that already handle SBOMs.
A CBOM typically captures four categories of asset: algorithms with their key size, mode, and curve; keys and certificates with their length, format, and location; protocols such as TLS and SSH; and the libraries or providers that implement them. CycloneDX distinguishes between libraries that implement an algorithm and applications that use one, which is what lets a security team reason about actual exposure rather than mere presence. Agile cryptography requires understanding what cryptography you are using, which implies a crypto inventory that records location and associated vulnerabilities. The CBOM is the artifact that assessment produces and that the rest of the migration consumes.
Risks of Skipping the Assessment
Treating PQC as an algorithm swap rather than an assessment-driven program creates predictable failures.
| Risk of algorithm-first thinking | What happens | Consequence |
|---|---|---|
| Blind spots remain | Cryptography in libraries, protocols, and hardware is missed. | Quantum-vulnerable assets survive the migration undetected. |
| Misallocated effort | Teams migrate visible systems while high-risk data goes unaddressed. | Budget spent without reducing the most material exposure. |
| No risk-based priority | Without exposure data, everything looks equally urgent. | Paralysis, or migration in the wrong order. |
| Harvest-now data left exposed | Long-lived secrets are not identified and protected first. | Data captured today remains decryptable in the future. |
| Compliance cannot be evidenced | No inventory means no proof of due diligence. | Audit and regulatory findings as deadlines approach. |
Crypto-agility is the real objective
There is also a strategic risk in treating migration as a one-time event. PQC is itself still evolving; NIST continues to evaluate additional signature and key-establishment algorithms. NIST selected the code-based HQC in March 2025 as a backup key-encapsulation mechanism, and FN-DSA (FALCON) is expected as FIPS 206, so the standardized set is still growing.
An organization that hard-codes a single replacement without building the inventory and abstraction to change again will face the same scramble at the next transition. The assessment is what makes crypto-agility possible, because it produces the map that lets you locate and change cryptography on demand rather than rediscovering it each time. NIST has even published a crypto-agility maturity model, built on the Cybersecurity Framework 2.0, to help organizations measure their progress toward that goal.
An Assessment-First Migration Path
The following sequence reflects the consensus across NIST, CISA, and NSA guidance, adapted for enterprise execution.
- Establish governance and ownership: Designate an executive sponsor and a PQC program lead, typically the CISO or CTO, and convene a cross-functional group spanning security architecture, risk, procurement, and the business lines, because the transition touches all of them.
- Build the cryptographic inventory: Deploy discovery tooling across source code, dependencies, containers, network services, and cloud, and make scans a routine part of CI/CD rather than a one-off. Capture the result as a CBOM so it is machine-readable and reusable. Encryption Consulting’s CBOM Secure automates this discovery across source, dependencies, containers, and cloud, producing that CBOM rather than a one-off questionnaire.
- Assess exposure and prioritize by risk: Rank assets by the sensitivity and lifetime of the data they protect, putting harvest-now-decrypt-later candidates and long-lived secrets at the top. A short-lived certificate poses far less risk than the same algorithm protecting data that must stay confidential for decades. A PQC Assessment turns the inventory into this risk-ranked roadmap.
- Engage vendors and the supply chain: Ask hardware, software, and cloud providers about their PQC roadmaps and product versions, and fold that readiness into procurement and risk decisions. Vendor migration timelines often simplify your own inventory, because a known PQC-capable version tells you what will change and when.
- Plan for hybrid and interoperability: Expect transitional deployments that combine a classical and a post-quantum mechanism and test them in non-production first. Hybrid key establishment, pairing a classical exchange with ML-KEM, is the widely recommended transition approach while the ecosystem matures.
- Pilot, then scale in sequence: Move from development and test to limited production pilots to scaled rollout, starting with the highest harvest-now risk and the longest confidentiality requirements. Validate performance assumptions about key sizes, latency, and HSM capacity through pilots before committing broadly. HSM-as-a-Service can supply PQC-capable capacity for those pilots without new hardware.
- Build for agility and keep monitoring: Maintain the inventory continuously, track NIST, CISA, and NSA updates as further algorithms and profiles are published, and architect systems so cryptography can be changed again without another full rediscovery.
How Encryption Consulting Can Help
Encryption Consulting makes an assessment-first migration practical through automated cryptographic discovery. CBOM Secure discovers, inventories, and centrally manages cryptographic assets across the estate, cataloging algorithms, keys, certificates, and the protocols that use them, and produces the machine-readable CBOM that a risk-based migration consumes. A PQC Assessment then turns that inventory into a prioritized, risk-ranked roadmap aligned to the harvest-now-decrypt-later threat and the NIST deprecation timeline, while PKI-as-a-Service and HSM-as-a-Service carry out the certificate, key, and hardware transitions. To see exactly where quantum-vulnerable cryptography lives in your estate, talk to Encryption Consulting about a cryptographic discovery and PQC readiness assessment.
Conclusion
The temptation to treat post-quantum migration as an algorithm swap is understandable, because algorithm selection is concrete and the standards are now final. But ML-KEM and ML-DSA are the destination, not the journey. Every authoritative roadmap, from CISA, NSA, and NIST joint guidance to the NCCoE migration project and the federal inventory mandates, begins in the same place: discover where cryptography lives, assess your exposure, and prioritize by the risk to data that must outlast the arrival of quantum computing.
To outlast the quantum threat, start with an assessment, not an algorithm. Build a cryptographic inventory, capture it as a CBOM, rank your exposure with harvest-now-decrypt-later data first, and design for crypto-agility so you can transition again as the standards continue to evolve. The organizations that will navigate the 2030 and 2035 deadlines smoothly are not the ones that picked an algorithm fastest, but the ones that knew exactly what they had to change and changed it in the right order.
