Post-Quantum Cryptography: A 12-Month Playbook for Digital Trust Professionals

A network engineer capturing a packet trace today can hold onto that capture for a decade, and so can an adversary sitting on the same wire. That pattern, known as harvest-now, decrypt-later, is one of the strongest reasons post-quantum cryptography (PQC) has moved from research agenda to corporate risk registers. Encrypted traffic that looks secure right now can be captured now and decrypted later.

All it takes is a cryptographically relevant quantum computer (CRQC): a machine large enough to run Shor’s algorithm and break the RSA and elliptic-curve math that anchors most of today’s key exchanges and digital signatures.

PQC refers to cryptographic algorithms designed to remain secure against attacks from both classical and quantum computers. The National Institute of Standards and Technology (NIST) finalized its first set of algorithms in August 2024: ML-KEM (FIPS 203) for key exchange, ML-DSA (FIPS 204) for general-purpose signatures, and SLH-DSA (FIPS 205) as a hash-based signature fallback.

FN-DSA was selected as the fourth algorithm and is still in development as FIPS 206, with a final standard expected in late 2026 or early 2027. In March 2025, NIST selected HQC as a fifth algorithm, a code-based key encapsulation mechanism meant to back up ML-KEM if a weakness ever turns up in lattice-based math.

Regulators did not wait for certainty on quantum computing either. NIST’s draft Internal Report 8547 (IR 8547) proposes deprecating RSA, the Elliptic Curve Digital Signature Algorithm (ECDSA), and Diffie-Hellman variants after 2030 and disallowing them outright after 2035, dates fixed on the calendar rather than tied to any quantum milestone. The National Security Agency’s (NSA) Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) pushes harder for national security systems, requiring exclusive use of post-quantum algorithms for signing by 2030.

These deadlines hold regardless of when, or whether, a quantum computer capable of breaking RSA actually ships. This post lays out a twelve-month plan for launching that transition inside a real enterprise, covering what to inventory first, how to pilot a hybrid deployment, and what changes are needed in public key infrastructure (PKI) and governance along the way.

Why the Quantum Clock Is Already Running

The mechanics behind harvest-now, decrypt-later are simple. The exposure math behind it is not, and it comes down to a small set of technical facts that decide how urgent this actually is for your organization.

The attack needs no quantum computer to start. An attacker records encrypted traffic today, stores it cheaply, and waits. Once a CRQC exists, the recorded key exchange gets broken, and the plaintext recovered. The theft happens now. The loss lands later, whenever that CRQC arrives.

Shor’s algorithm is the actual threat, and it breaks public-key cryptography outright. A large fault-tolerant quantum computer running Shor’s algorithm can factor RSA keys and solve the discrete-log problem behind Diffie-Hellman and elliptic-curve cryptography (ECC), breaking all three completely rather than just weakening them. That risk sits almost entirely in the public-key layer, the exact layer that anchors PKI, Transport Layer Security (TLS), virtual private networks (VPNs), and code signing, making it the first place organizations need to focus their post-quantum migration efforts.

Data lifetime decides what moves first, not the arrival date of the quantum computer. Nobody can name the year a machine capable of running Shor’s algorithm at scale will exist. What matters instead is how long your data needs to stay confidential, because harvest-now, decrypt-later makes that data vulnerable today, long before any such machine exists. Financial records, health records, government secrets, and intellectual property that need ten to twenty years of secrecy or more are first in line for exactly that reason. Data with that kind of lifetime is exposed the moment it’s recorded, regardless of when a quantum computer capable of decrypting it eventually arrives.

Perfect Forward Secrecy (PFS) does not prevent harvest-now, decrypt-later. Even though TLS 1.3 uses Elliptic Curve Diffie-Hellman ephemeral (ECDHE), a CRQC could derive the ephemeral private key from a recorded handshake, reconstruct the session key, and decrypt archived traffic. PFS protects against compromise of long-term private keys, not against quantum attacks on the underlying key exchange algorithm itself.

Regulators put dates on the calendar instead of waiting for certainty. NIST’s draft Internal Report 8547 (initial public draft, November 2024) proposes deprecating RSA, ECDSA, elliptic-curve Diffie-Hellman, and finite-field Diffie-Hellman after 2030 and disallowing them after 2035. Deprecated means the algorithm can no longer be chosen for new systems. Disallowed means it cannot be used at all, including in legacy systems still running it.

IR 8547 remains a draft, so wording could shift, but the 2030 and 2035 markers already line up with the 2035 federal migration target set by National Security Memorandum 10 in May 2022.

CNSA 2.0 makes it a contract term, not a guideline, for national security systems. CNSA 2.0 (September 2022) names exact algorithms and parameter sets: ML-KEM-1024 for key establishment, ML-DSA-87 for signatures, and the stateful hash-based schemes in NIST SP 800-208 for firmware. The rollout is staged by category: Software and firmware signing, along with networking equipment such as VPNs and routers, must reach exclusive use by 2030, while most other categories reach exclusive use by 2033.

For contractors and suppliers selling into that space, these dates become binding through mechanisms like DFARS clauses, CMMC certification, and RMF assessments, rather than applying automatically. The transition is already underway across the industry. Gartner warned in early 2025 that advances in quantum computing would make conventional asymmetric cryptography unsafe by 2029, and its Top Trends in Cybersecurity for 2026 report has since moved that estimate to 2030, aligning with NIST’s own proposal to deprecate RSA, ECDSA, and Diffie-Hellman after 2030 and disallow them after 2035.

At the same time, major technology providers have already moved past planning and into production. Google enabled hybrid post-quantum key exchange in Chrome by default in April 2024 and has been reported to be targeting 2029 for completing PQC migration across its internal infrastructure.

Cloudflare has set the same 2029 target publicly for its own network, stating its goal is full post-quantum readiness, including authentication, by that year. Meta has published a five-level PQC maturity model and reports it has already reached full quantum-resistant deployment across significant portions of its internal traffic, per its own engineering team’s April 2026 writeup, though Meta has not published a specific completion-year target the way Google and Cloudflare have.

Together, these developments show that PQC is no longer experimental. It has become an active engineering and operational priority, with 2029 emerging as the informal industry benchmark year even ahead of NIST’s own regulatory deadlines.

Replacing algorithms is only one part of the migration. Organizations first need visibility into where vulnerable algorithms are actually deployed, across certificates, TLS endpoints, applications, hardware security modules (HSMs), Secure Shell (SSH), VPNs, firmware, application programming interfaces (APIs), and embedded systems, before remediation can be scheduled or sequenced.

Understanding why the clock is ticking is only half the picture. The next question is how organizations can prepare for cryptographic change without turning every algorithm update into a major engineering effort.

Why Crypto-agility Matters

One of the biggest misconceptions about post-quantum migration is that it is simply a matter of replacing RSA or ECC with ML-KEM and ML-DSA. In reality, the harder problem is enabling systems to adopt new cryptographic algorithms without requiring applications to be redesigned every time standards evolve.

This capability is known as crypto-agility. It is the ability to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations. A crypto-agile system does not hardcode algorithms into business logic. Instead, it separates cryptographic choices from application code, allowing algorithms, key sizes, certificate profiles, and protocol configurations to evolve as standards change.

Crypto-agility matters because post-quantum migration will not be a one-time event. NIST has already expanded its portfolio beyond the initial standards by selecting HQC as a backup key encapsulation mechanism, while FN-DSA is progressing toward standardization. Future algorithms, implementation guidance, and parameter sets will continue to evolve as cryptanalysis advances. Organizations that build systems around a single replacement algorithm today risk repeating the same migration effort a few years from now.

For most enterprises, the greatest obstacle is not choosing ML-KEM or ML-DSA. It is discovering where RSA and elliptic-curve cryptography are embedded across certificates, applications, APIs, HSMs, VPNs, SSH, firmware, cloud services, and third-party products. Without that visibility, migration planning becomes guesswork.

Successful post-quantum programs begin with discovery, inventory, and governance rather than immediate algorithm replacement. The following twelve-month playbook outlines one practical approach for building that foundation.

The 12-Month Playbook

The timeline for building crypto-agility and completing a full post-quantum migration varies by organization, but for most enterprises it is measured in years rather than months due to the size and complexity of their cryptographic environment.

The first year should focus on building the foundation for that transition by creating a comprehensive cryptographic inventory, validating post-quantum technologies through hybrid deployments, defining a practical PKI migration strategy, and establishing governance that supports future cryptographic changes.

The four phases below outline a practical roadmap, with each phase building on the last to prepare the organization for broader post-quantum adoption.

Month 1-3: Organize, Inventory, and Scope

The objective of this phase is simple: understand where cryptography exists across the organization and establish clear ownership for every asset that will eventually need to be migrated. Every later phase depends on this baseline.

To build that foundation, the organization should focus on the following activities:

• Establish a crypto transition working group with executive sponsorship, bringing together security architecture, PKI, identity, networking, DevOps, application teams, and compliance. Post-quantum migration requires coordination across the enterprise rather than ownership by a single team.
• Create a formal Quantum Risk entry in the enterprise risk register and assign executive ownership, typically under the Chief Information Security Officer (CISO) or an equivalent security leader.
• Build a comprehensive cryptographic inventory, structured as a Cryptographic Bill of Materials (CBOM): a standardized, machine-readable inventory of every cryptographic asset in a system, including algorithms and modes, key and certificate metadata, cryptographic libraries, protocols and versions, and the services or components that rely on each one.
• Identify every location where public-key cryptography is used, including TLS endpoints, VPNs, SSH, email security, code signing, firmware signing, mobile applications, APIs, cloud services, and third-party integrations. Record the algorithm, key size, certificate validity, protocol version, software library, and asset owner. This mapping is what makes migration planning possible, since a transition can only be scoped against what’s actually deployed.
• Map cryptographic workflows by identifying where certificates are issued, where TLS terminates, where digital signatures are generated, and where cryptographic decisions are enforced. Hardcoded algorithms and vendor-managed components should be flagged for early investigation.
• Classify data according to its confidentiality lifetime. Systems protecting long-lived data such as financial records, healthcare information, government data, and intellectual property should receive the highest migration priority because they are most exposed to harvest-now, decrypt-later attacks.
• Assess the organization’s crypto-agility by identifying applications that hardcode algorithms, require software changes for cryptographic updates, or lack support for configurable cryptographic policies. These systems are likely to become migration bottlenecks.
• Document application and business dependencies for each cryptographic asset so migration sequencing reflects operational impact rather than technical inventory alone.

Outcome: By the end of this phase, the organization should have a documented cryptographic inventory, clear ownership for critical assets, and a prioritized migration backlog.

Month 4-6: Pilot and Measure

With a cryptographic inventory and priorities in place, the next step is to validate your migration strategy through controlled hybrid deployments. The goal is to understand how post-quantum technologies perform in a controlled environment before planning broader adoption. Key activities include:

• Deploy a hybrid key exchange pilot using both classical and post-quantum algorithms, such as X25519MLKEM768, to maintain interoperability while introducing quantum-resistant protection.
• Measure operational impact by evaluating handshake size, latency, CPU utilization, memory consumption, certificate chain size, and user experience under realistic workloads.
• Validate interoperability across browsers, operating systems, load balancers, reverse proxies, HSMs, cloud platforms, and third-party applications to identify compatibility issues early.
• Demonstrate crypto-agility by replacing algorithms through configuration rather than application changes and validate algorithm rotation through continuous integration and continuous delivery (CI/CD) pipelines.
• Record any system requiring code changes or service redeployment to support new algorithms, as these systems represent future migration risks.
• Begin with developer-focused trust chains such as code signing, container signing, software artifact signing, and build pipelines before expanding into customer-facing services.
• Develop rollback procedures and operational runbooks for hybrid deployments before production adoption.

Outcome: By the end of this phase, the organization should understand the operational impact of hybrid cryptography, identify compatibility gaps, and validate that algorithm changes can be performed without disrupting production services.

Month 7-9: Modernize PKI and Contracts

Once the pilot has validated the technology, the focus shifts to preparing the underlying PKI, vendor ecosystem, and procurement processes for long-term post-quantum adoption. Key activities in this phase include:

• Design a dual-stack PKI capable of supporting both classical and post-quantum certificates during the migration period.
• Prioritize migration of long-lived trust anchors such as root and intermediate certificate authorities (CAs), whose validity periods may extend beyond planned deprecation dates for classical algorithms.
• Recognize current implementation constraints. ML-DSA protects digital signatures but does not provide quantum-safe key establishment, which still requires ML-KEM. Existing certificate hierarchies generally require parallel deployment rather than in-place upgrades.
• Evaluate composite and hybrid certificates where appropriate to maintain interoperability during the transition.
• Update procurement requirements so new products and services support FIPS 203, FIPS 204, and FIPS 205, while also demonstrating crypto-agility.
• Engage vendors to understand their PQC roadmaps, firmware availability, supported libraries, and upgrade timelines. External dependencies frequently determine migration schedules.
• Develop migration strategies for constrained environments such as the Internet of Things (IoT) and operational technology (OT), where long hardware lifecycles may require gateway protection, firmware upgrades, or planned hardware replacement.

Outcome: By the end of this phase, the organization should have a modernized PKI strategy, improved vendor visibility, and procurement processes aligned with post-quantum requirements.

Month 10-12: Scale and Institutionalize Governance

The final phase focuses on expanding successful pilots into production while embedding post-quantum readiness into day-to-day operations, governance, and lifecycle management. Key activities in this phase include:

• Expand hybrid or PQC deployments into production, prioritizing business-critical services based on the risk assessment completed during the discovery phase.
• Track measurable migration metrics, including PQC-ready endpoints, hybrid-enabled services, migrated certificate hierarchies, crypto-agile applications, and code-signing pipelines.
• Establish policies, standards, and operational procedures covering algorithm selection, certificate profiles, key management, logging, monitoring, incident response, and lifecycle management.
• Integrate cryptographic inventory updates into normal operational processes so newly deployed systems are automatically included in future migration planning.
• Continue monitoring standards and vendor guidance as PQC algorithms, implementations, and regulatory requirements evolve.
• Design systems for future algorithm replacement by avoiding hardcoded cryptographic dependencies and maintaining crypto-agility across applications and infrastructure.

Outcome: By the end of the first year, the organization should have established repeatable processes, measurable progress, and the operational foundation needed to scale post-quantum migration over the coming years.

Measuring Post-Quantum Readiness

Completing a few pilot deployments or issuing a handful of post-quantum certificates does not necessarily mean an organization is ready for the transition. A successful migration is measured by the organization’s ability to discover, manage, and adapt cryptography as technologies and standards continue to evolve. The following metrics provide a practical way to evaluate progress throughout the program.

• Cryptographic visibility: Measure the completeness of the organization’s continuously maintained Cryptographic Bill of Materials (CBOM). A mature CBOM should provide up-to-date visibility into certificates, keys, algorithms, cryptographic libraries, protocols, HSMs, trust stores, APIs, cryptographic dependencies, ownership, and business criticality across the enterprise.
• Migration coverage: Continuously track where hybrid or post-quantum cryptography has been deployed across TLS endpoints, VPN gateways, PKI services, SSH infrastructure, code-signing pipelines, cloud workloads, and machine-to-machine communications. The objective is to demonstrate increasing adoption across business-critical systems rather than isolated pilot environments.
• Crypto-agility: Evaluate whether cryptographic algorithms, parameter sets, certificate profiles, and protocol configurations can be updated through configuration or policy changes rather than application code modifications. Systems that require software redevelopment or service redeployment for every cryptographic change should be treated as migration bottlenecks.
• Vendor readiness: Assess the post-quantum maturity of operating systems, browsers, HSMs, cloud platforms, network appliances, SDKs, and third-party applications. Vendor roadmaps, firmware availability, supported cryptographic libraries, and interoperability commitments often determine migration timelines more than internal engineering work.
• PKI readiness: Evaluate whether the PKI can support hybrid and post-quantum deployments through modern certificate templates, updated certificate profiles, automated lifecycle management, quantum-ready trust hierarchies, and support for emerging standards as they become available.
• Operational readiness: Verify that governance, monitoring, incident response, lifecycle management, and operational runbooks have been updated to support both classical and post-quantum cryptography. Teams should also have clearly defined ownership, change management workflows, and regular reporting to demonstrate measurable progress throughout the migration.

These indicators shift the conversation from “How many certificates have we replaced?” to “How prepared are we to manage cryptographic change?” That distinction matters because post-quantum migration is not a one-time project. It is the beginning of an ongoing cryptographic lifecycle.

Common Pitfalls That Stall Post-Quantum Migration

Even organizations with a clear roadmap can struggle if they approach post-quantum migration with the wrong assumptions. Most delays are not caused by the algorithms themselves, but by gaps in visibility, planning, and operational readiness. The following pitfalls appear consistently across enterprise migration programs.

• Treating PQC as a certificate replacement project: Replacing RSA or ECC certificates with post-quantum alternatives is only one part of the migration. Cryptography also exists in applications, cryptographic libraries, VPNs, SSH, APIs, HSMs, firmware, databases, cloud services, and third-party products. Focusing only on certificates leaves significant portions of the environment exposed.
• Starting migration without a complete cryptographic inventory: Organizations frequently begin pilot deployments before understanding where vulnerable algorithms are actually being used. Without a continuously maintained CBOM or equivalent inventory, migration priorities become guesswork, critical assets are overlooked, and remediation efforts become reactive rather than planned.
• Ignoring application and vendor dependencies: Internal applications are only part of the challenge. Browsers, operating systems, load balancers, HSMs, cloud platforms, identity providers, network appliances, and commercial software all have their own post-quantum adoption timelines. A migration plan that does not account for external dependencies is unlikely to stay on schedule.
• Assuming hybrid deployments are the final destination: Hybrid cryptography is designed as a transition mechanism to balance interoperability with quantum resistance. It reduces migration risk while ecosystems mature, but it should not be treated as the long-term end state. Organizations should plan for eventual adoption of standardized post-quantum algorithms as support becomes widespread.
• Building solutions without crypto-agility: Hardcoding algorithms into applications or requiring software redevelopment for every cryptographic update creates long-term operational risk. Future standards will continue to evolve, making crypto-agility a fundamental design requirement rather than a feature added later.
• Treating migration as a one-time project: Post-quantum migration does not end after the first deployment. New standards, implementation guidance, cryptanalysis, and vendor capabilities will continue to evolve. Organizations need continuous discovery, governance, lifecycle management, and periodic reassessment to keep cryptographic environments secure over time.
• Waiting for every standard and vendor implementation to mature: Some organizations delay planning until they believe the ecosystem is fully settled. By then, the discovery, inventory, governance, and modernization work still remains. These foundational activities are technology-agnostic and can begin today, regardless of when production deployments are scheduled.

Successful post-quantum programs are rarely distinguished by how quickly they replace algorithms. They succeed because organizations build the visibility, governance, automation, and crypto-agility needed to adapt as cryptographic standards continue to evolve. That preparation makes each future transition significantly easier than the last.

How Encryption Consulting Can Help

The 12-month playbook above builds the foundation, but completing a full post-quantum migration is a multi-year effort, and most organizations face the same challenges along the way: incomplete visibility into cryptographic assets, uncertainty around application and vendor dependencies, evolving regulatory expectations, and the operational complexity of modernizing PKI without disrupting business services. Successfully navigating that transition requires more than replacing algorithms. It requires a structured approach that combines discovery, governance, planning, and the crypto-agility to sustain change as standards mature.

PQC Advisory Services

Encryption Consulting’s PQC Advisory Services help organizations plan and execute every stage of their post-quantum migration journey. We begin by discovering cryptographic assets and dependencies across enterprise environments, including certificates, keys, algorithms, cryptographic libraries, HSMs, cloud platforms, applications, APIs, containers, source code repositories, and CI/CD pipelines.

Using this inventory, our consultants evaluate exposure to quantum-vulnerable cryptography, identify migration priorities based on business risk, and develop practical risk-based migration roadmaps aligned with NIST standards, industry guidance, and organizational objectives. We also help organizations with vendor readiness assessments, proof-of-concept validation, interoperability testing, hybrid cryptography deployments, crypto-agile PKI architecture design, and enterprise-scale implementation programs.

Before scaling any migration, we run pilot deployments on a small set of representative, non-critical systems to validate real-world performance, interoperability, and operational impact. These pilots surface integration issues early, so the lessons learned can be built into the broader rollout rather than discovered during it.

This structured approach enables organizations to move from fragmented cryptographic visibility to a governed, measurable, and sustainable PQC migration program.

CBOM Secure

Discovery is the foundation of every successful post-quantum migration, and maintaining that visibility requires more than a one-time assessment. Encryption Consulting’s CBOM Secure provides continuous discovery and inventory of cryptographic assets across enterprise infrastructure, cloud environments, applications, and cryptographic services.

Unlike a point-in-time inventory, CBOM Secure continuously generates and consumes Cryptographic Bills of Materials (CBOMs) while tracking certificates, keys, algorithms, and cryptographic dependencies across the environment. It provides visibility into what is deployed, where it is running, and how those dependencies evolve over time.

The platform supports policy-driven governance by validating cryptographic configurations against organizational standards, identifying deviations, and highlighting security, operational, and compliance risks. For organizations preparing for PQC migration, CBOM Secure helps identify systems that rely on quantum-vulnerable algorithms, prioritize remediation efforts, and establish the continuous cryptographic governance required to achieve long-term crypto-agility.

Whether your organization is just beginning to assess quantum risk or is already planning enterprise-wide migration, Encryption Consulting combines deep cryptographic expertise with purpose-built solutions to help you discover cryptographic assets, modernize PKI, build crypto-agile architectures, and execute a practical, measurable transition to PQC.

Conclusion

The organizations that navigate this transition successfully will not be the ones that accurately predict when a cryptographically relevant quantum computer arrives. They will be the ones that build the capability to adapt as standards, threats, and business requirements evolve. In that sense, post-quantum readiness is less about selecting the right algorithm today and more about establishing the processes, governance, and crypto-agility needed to support continuous change.

The standards are in place, regulatory expectations are becoming clearer, and vendors are steadily expanding support. The remaining challenge is execution.

The first year should therefore focus on building a strong foundation rather than attempting a complete migration. Develop a comprehensive cryptographic inventory, prioritize systems based on business risk and data sensitivity, validate hybrid deployments in controlled environments, modernize PKI to support future algorithms, and incorporate post-quantum readiness into procurement and governance processes. Just as importantly, establish continuous visibility and lifecycle management so cryptographic assets remain discoverable as the environment changes.

Ultimately, PQC migration is not a one-time technology refresh. It is the beginning of a long-term shift toward continuous cryptographic governance. Organizations that invest in visibility, automation, and crypto-agility today will be better positioned to adopt future standards, respond to emerging threats, and manage cryptographic change with confidence throughout the years ahead.