Your “Latest” Guide to PQC Readiness

Key Takeaways

• NIST finalized three post-quantum cryptography standards in August 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). A fourth algorithm, HQC, was selected in March 2025 as a backup key encapsulation mechanism, with a draft standard expected around 2026 and a final standard expected around 2027.
• NIST IR 8547 sets the broad federal timeline: RSA and ECC are deprecated for new use around 2030 and disallowed around 2035. CNSA 2.0 sets a faster timeline for national security systems, with preferred use of PQC algorithms starting in 2025 and exclusive use required between 2030 and 2033 depending on the system category.
• A cryptographic inventory, often delivered as a Cryptographic Bill of Materials (CBOM), is the prerequisite for migration planning. Without it, organizations cannot prioritize which systems to migrate first or measure progress.
• Migration runs in phases, discovery, prioritization, pilot, hybrid deployment, full cutover, and validation, not as a single algorithm swap on a single date.
• Hybrid and composite certificates, which combine a classical algorithm with a post-quantum algorithm in one certificate, are the practical bridge while relying-party software and hardware catch up to PQC support.

Published: March 2025. Updated: August 2026. Reviewed by Encryption Consulting’s PQC Advisory team.

What Does PQC Readiness Mean?

PQC readiness is an organization’s demonstrated ability to find, classify, and migrate every cryptographic asset that depends on algorithms a quantum computer could break, before that break becomes practical. Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to remain secure against both classical computers and future quantum computers. The National Institute of Standards and Technology (NIST) leads the global standardization effort for these algorithms.

Readiness is not the same as migration. An organization can be “ready” without having migrated a single system, as long as it has completed a cryptographic inventory, classified its data by sensitivity and retention period, and has a funded, staffed roadmap in motion. A ready organization is one that has removed the guesswork from the question “where are we exposed, and what do we do about it first?”

The urgency behind PQC readiness comes from a specific attack pattern: harvest now, decrypt later (HNDL). An adversary intercepts and stores encrypted data today, with no ability to read it, and waits for a cryptographically relevant quantum computer (CRQC) capable of breaking RSA and elliptic curve cryptography (ECC). Any data that must remain confidential for years or decades, health records, government communications, financial archives, is at risk under HNDL even though the quantum computer that decrypts it doesn’t exist yet. This is why readiness work starts now rather than when CRQCs arrive.

What Are the Current NIST PQC Standards and CNSA 2.0 Deadlines?

NIST finalized three post-quantum cryptography standards on August 13, 2024, following an eight-year, multi-round public evaluation that began in 2016 with 69 candidate algorithms. A fourth algorithm, HQC, was added as a backup in March 2025. The table below lists what’s standardized today.

Standard	Algorithm	Type	Status
FIPS 203	ML-KEM (based on CRYSTALS-Kyber)	Key encapsulation mechanism (key exchange)	Finalized August 2024
FIPS 204	ML-DSA (based on CRYSTALS-Dilithium)	Digital signature (primary)	Finalized August 2024
FIPS 205	SLH-DSA (based on SPHINCS+)	Digital signature (hash-based backup)	Finalized August 2024
NIST IR 8545 (planned)	HQC	Key encapsulation mechanism (backup to ML-KEM)	Selected March 2025; draft standard expected ~2026, final ~2027

NIST IR 8547, the transition guidance that accompanies these standards, sets the deprecation and disallowance timeline for classical algorithms: RSA and ECC are deprecated for new use around 2030, and disallowed for continued use around 2035. National Security Memorandum 10 (NSM-10) directs U.S. federal agencies to complete the shift to quantum-resistant cryptography by 2035.

For national security systems, the NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) sets a faster, category-specific timeline. The table below summarizes the milestones as published in the NSA’s CNSA 2.0 advisory.

System Category	Prefer CNSA 2.0 By	Exclusive CNSA 2.0 Use By
Software and firmware signing	2025	2030
Web browsers, servers, and cloud services	2025	2033
Traditional networking equipment (VPNs, routers)	2026	2030
Operating systems	2027	2033

CNSA 2.0 applies directly to national security systems, but many regulated and commercial organizations align to it as a leading indicator of where broader compliance expectations are headed. If your organization is a defense contractor, works with classified systems, or supplies to government agencies, confirm which of these deadlines applies to your specific system classification rather than assuming the general NIST IR 8547 timeline covers you.

What Cryptographic Inventory Do You Need Before Migrating?

A cryptographic inventory, a complete list of every algorithm, key, certificate, and library in use across your environment, is the prerequisite for every later migration decision. Skipping it doesn’t skip the work; it just guarantees you’ll discover gaps mid-migration instead of before it.

Building the inventory involves three connected activities:

• Cryptographic discovery: Scan network protocols, applications, source code and build pipelines, and infrastructure for quantum-vulnerable algorithms (RSA, ECC, Diffie-Hellman) and their key sizes.
• Cryptographic inventory: Consolidate discovery results into a Cryptographic Bill of Materials (CBOM) that records where each algorithm is used, what data it protects, and which systems and vendors depend on it. Some cryptography is embedded in purchased products and invisible to network scanning; that requires direct vendor disclosure.
• Data classification: Rank systems by the sensitivity of the data they protect and how long that data must stay confidential. Data with multi-decade retention requirements (health records, long-term government or financial data) carries the highest HNDL exposure and should migrate first.

Encryption Consulting’s CBOM Secure automates this discovery and inventory work, producing a CycloneDX-format CBOM that becomes the single source of truth for migration prioritization and progress tracking.

What Algorithm and Interoperability Caveats Should You Plan For?

PQC algorithms are not drop-in replacements for RSA and ECC. Before committing to a migration timeline, plan around three practical constraints.

• Larger keys and signatures: ML-KEM-768 uses a 1,184-byte public key versus roughly 32 bytes for an equivalent classical elliptic-curve key. ML-DSA-65 produces a public key of 1,952 bytes and a signature around 3,309 bytes, far larger than an ECDSA P-256 signature. Bandwidth-constrained protocols, embedded devices, and legacy TLS handshake paths need to be tested for these size increases before rollout, not after.
• Uneven vendor and library support: Support for FIPS 203/204/205 varies across HSM firmware, TLS libraries, browsers, and CA software as of this writing. Confirm PQC support directly with each vendor in your stack before designing a migration plan that assumes universal readiness.
• Relying-party compatibility during the transition: Not every system that verifies your certificates or signatures will support PQC algorithms on the same day. Hybrid and composite approaches, covered next, exist specifically to bridge this gap.

How Do Hybrid and Composite Certificates Bridge the Transition?

A hybrid or composite protocol combines a classical algorithm and a post-quantum algorithm in the same key establishment or signature operation, so the result stays secure as long as at least one of the two component algorithms remains unbroken. In key establishment, a classical method such as ECDH runs alongside ML-KEM; in digital signatures, a classical algorithm such as ECDSA runs alongside ML-DSA in a composite (also called hybrid) certificate defined by ongoing IETF LAMPS working group specifications.

Composite certificates let a relying party that only supports classical algorithms verify the classical component, while a relying party updated for PQC verifies the post-quantum component, from the same certificate. That means migration can start before every relying party in your ecosystem has been updated, instead of waiting for a synchronized cutover that may never arrive on schedule. Treat the composite phase as transitional: define, for each certificate type, what percentage of relying parties must support pure ML-DSA before you retire the classical component.

What Are the Phased Migration Steps?

A PQC migration succeeds when it runs as a sequenced program, not a single cutover event. The steps below are the master framework; Encryption Consulting’s PQC Advisory service expands this into a detailed nine-phase roadmap tailored to your environment.

1. Cryptographic discovery and inventory. Build the CBOM described above before making any migration decisions.
2. Risk-based prioritization. Rank systems by data sensitivity, retention period, and HNDL exposure; the highest-risk, longest-retention systems migrate first.
3. Algorithm and architecture planning. Decide, per certificate or key-establishment type, whether to deploy pure PQC or a hybrid/composite approach, and confirm vendor support for the chosen algorithms.
4. Pilot deployment. Issue PQC or hybrid certificates and keys in a controlled, non-production environment and validate interoperability with representative relying parties.
5. Staged hybrid rollout. Expand deployment certificate type by certificate type or system by system, monitoring relying-party compatibility at each stage.
6. Full cutover and legacy retirement. Once relying-party coverage for a given type reaches your defined threshold, move from hybrid to pure PQC and retire the classical algorithm for that type.
7. Continuous monitoring and governance. Maintain the CBOM as a living inventory, track algorithm distribution across your estate, and revisit the plan whenever NIST, NSA, or the CA/Browser Forum updates guidance.

How Do You Test and Validate a PQC Migration?

A migration is not validated until it has evidence behind it, not just a completed rollout checklist. Build these into every phase:

• Interoperability testing: Confirm that every relying-party system in scope, browsers, internal applications, partner integrations, IoT and OT devices, can actually verify the new algorithm or hybrid certificate before it goes to production.
• Performance and latency benchmarking: Measure the real-world impact of larger PQC keys and signatures on TLS handshake time, code-signing throughput, and constrained-device performance, particularly for high-volume or latency-sensitive systems.
• Rollback planning: Pre-authorize the conditions under which a pilot or staged rollout reverts to the classical or hybrid state, so a compatibility failure in production doesn’t become an incident response scramble.
• Audit evidence: Keep dated records of inventory snapshots, pilot results, and sign-off decisions. This evidence supports both internal governance reviews and external compliance audits.

What Does a PQC Readiness Implementation Checklist Look Like?

• Complete a cryptographic discovery scan across network protocols, applications, code repositories, and infrastructure.
• Build and maintain a CBOM that maps each cryptographic asset to the data and systems it protects.
• Classify data by sensitivity and required confidentiality period to identify highest HNDL exposure.
• Confirm PQC algorithm support with every HSM, TLS library, CA, and cloud provider in your stack.
• Decide, per certificate and key-establishment type, on a hybrid/composite versus pure-PQC approach.
• Pilot PQC or hybrid deployment in a non-production environment with representative relying parties.
• Define and document rollback criteria before each staged rollout begins.
• Track algorithm distribution and relying-party compatibility as ongoing, measurable metrics.
• Assign governance ownership (who approves profile changes, who tracks the CBOM, who reports migration status).
• Revisit the roadmap whenever NIST, NSA, or CA/Browser Forum guidance changes.

Where Does Your Organization Fall on the PQC Readiness Maturity Scale?

Use the stages below to place your organization honestly, then act on the recommended next step rather than the stage label alone.

Stage	What It Looks Like	Recommended Next Action
Unaware	No cryptographic inventory exists; no one owns PQC readiness	Start cryptographic discovery immediately and assign an owner
Assessing	Inventory is underway; exposure and gaps are being mapped	Classify data by sensitivity and retention; identify highest-risk systems
Planning	A migration roadmap and algorithm policy are drafted	Select hybrid/composite approach per system type; assign governance roles
Migrating	Pilot and staged rollout are in progress	Expand rollout in priority order; monitor relying-party compatibility
Validated	Migration is complete and tested across the estate for a given scope	Move to continuous governance; monitor emerging standards (HQC, CNSA 2.0 updates)

What Are the Limitations of This Guide?

This guide is a starting point, not a substitute for an assessment of your specific environment. A few limitations are worth stating directly:

• HQC is not yet a final standard. NIST expects a draft around 2026 and a final standard around 2027; details could still change before then.
• Vendor and library support for FIPS 203/204/205 varies widely and changes often. Timelines in this guide describe the standards, not any specific product’s roadmap; confirm support directly with your vendors.
• The 2030, 2033, and 2035 dates reflect current NIST and NSA guidance. They are not predictions of when a cryptographically relevant quantum computer will exist; that timing remains uncertain, and guidance could shift if it changes.
• This guide is not legal or compliance advice. Sector-specific and contractual deadlines (defense, financial services, healthcare) can be stricter than the general timelines described here.

What Would Encryption Consulting Recommend?

Start where the risk actually is, not where it’s easiest to start. Most organizations we work with underestimate how much cryptography is hidden in purchased products and legacy systems until they run a real discovery scan. Our recommended sequence:

• Run a cryptographic discovery and inventory first. CBOM Secure automates discovery across your network, applications, and infrastructure and produces the CBOM your migration plan will be built on.
• Build your roadmap with PQC Advisory. Our PQC Advisory Services translate the CBOM into a phased, nine-phase migration roadmap, including scope validation, hybrid/composite architecture decisions, pilot design, and compliance alignment with NIST IR 8547 and CNSA 2.0.
• Modernize certificate lifecycle management. CertSecure Manager gives you the visibility to track algorithm distribution across your certificate estate as migration progresses, instead of relying on spreadsheets.
• Protect the keys behind your PQC algorithms. HSM-as-a-Service provides FIPS-validated key protection as you generate and manage new PQC and hybrid keys during the transition.

If you’ve already completed your inventory and want to go deeper on specific parts of the journey, see our PQC Security Maturity Model to self-assess across governance, discovery, and pilots; our 75-question PQC readiness assessment to surface concrete gaps; and our guide to PQC program governance roles and RACI to staff the program correctly from the start.

Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified, and our PQC Advisory work is grounded in the same standards this guide cites: NIST FIPS 203/204/205, NIST IR 8547, and CNSA 2.0.

Conclusion

PQC readiness is not a single algorithm swap you can schedule for one weekend. It’s a program: know what cryptography you actually have, prioritize by real risk, plan for hybrid and composite bridges where relying parties aren’t ready, migrate in stages, and validate every step with real evidence. NIST’s standards are final. The deadlines, 2030 for deprecation, 2033 to 2035 for disallowance depending on your system category, are set. The only open variable is how early your organization starts the inventory that everything else depends on.

If you’re ready to start that inventory or need help sequencing a migration roadmap, talk to Encryption Consulting’s PQC Advisory team.

Frequently Asked Questions

What is the difference between PQC readiness and PQC migration?

PQC readiness is the state of knowing exactly what you need to migrate and having a funded, staffed plan to do it. PQC migration is the execution of that plan: issuing PQC or hybrid keys and certificates, updating systems, and retiring classical algorithms. You can be ready without having migrated a single system yet, as long as the inventory and roadmap exist and work is actively underway.

Do we need to migrate everything before 2030?

NIST IR 8547 sets 2030 as the point RSA and ECC are deprecated for new use, and 2035 as the point they’re disallowed entirely, for systems that follow general NIST guidance. National security systems under CNSA 2.0 face earlier deadlines, as early as 2030 for software and firmware signing. Prioritize by data sensitivity and retention period rather than treating every system as equally urgent; long-lived, highly sensitive data should migrate well ahead of any deadline.

What is harvest now, decrypt later, and why does it matter now?

Harvest now, decrypt later (HNDL) describes an adversary intercepting and storing encrypted data today with the intent to decrypt it once a cryptographically relevant quantum computer exists. Because a CRQC’s exact arrival date is unknown, any data that must stay confidential for years or decades is already exposed under this pattern, even though no quantum computer can break it yet. That’s the reason PQC readiness work starts before quantum computers are practical, not after.

Are hybrid or composite certificates required, or optional?

Neither NIST nor the CA/Browser Forum currently mandates hybrid or composite certificates outright, but most organizations use them as a practical bridge because relying-party support for pure PQC algorithms isn’t universal yet. Whether you need them depends on how much of your relying-party ecosystem you control and how quickly it can be updated; internal systems you fully control may be able to move directly to pure PQC.

How long does a PQC readiness program typically take?

For most enterprise environments, cryptographic discovery and inventory takes several months, roadmap and pilot design takes a few more, and staged rollout across a full certificate and key estate can run one to two years depending on scope and relying-party diversity. Organizations that start discovery now have time to run a methodical, low-risk program; those that wait until a deadline is imminent will be migrating under pressure with untested relying-party compatibility.

References

• NIST, “Announcing Issuance of Federal Information Processing Standards (FIPS) 203, 204, and 205,” Federal Register, August 14, 2024: federalregister.gov
• NIST, “NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption,” March 2025: nist.gov
• NIST IR 8547, “Transition to Post-Quantum Cryptography Standards”: nvlpubs.nist.gov
• National Security Agency, Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) advisory
• National Security Memorandum 10 (NSM-10) on quantum-resistant cryptography migration