Guide
Post-Quantum Cryptography Migration: A Readiness Roadmap

Quantum computing is changing the foundations of the encryption that protects enterprise communications, identity, financial transactions, and long-lived data. A standards-based response, post-quantum cryptography (PQC), is now finalized and ready to deploy. What most organizations still lack is a clear, sequenced plan for moving from the algorithms running in production today to the quantum-safe algorithms they will need. This guide explains why PQC migration matters now, what the NIST standards contain, how to assess your readiness, and the practical roadmap that turns assessment into action.
Why PQC Migration Cannot Wait
The most common objection to starting today is that no computer can break RSA-2048 or elliptic-curve cryptography in 2026. That is true, and it is also why most organizations are underprepared. A large, fault-tolerant quantum computer running Shor’s algorithm would reduce the math behind RSA and elliptic-curve cryptography from effectively unsolvable to solvable, exposing any data those algorithms protect. Public estimates place that capability somewhere between 2030 and 2035 for critical systems, the window most national migration roadmaps now target.
The quantum threat is already concurrent because of ‘harvest now, decrypt later’ attacks. Adversaries capture encrypted traffic and stored ciphertext today (VPN handshakes, backups, intercepted email, archived databases) and hold it until quantum decryption becomes possible. Data does not need to be breakable today to be at risk from future quantum decryption. Long-lived information such as health records, financial data, intellectual property, and government secrets is the most exposed, because its sensitivity outlasts the transition window.
Migration planning also needs to account for a process that can take years, touching certificate authorities, TLS and SSH endpoints, VPN concentrators, code-signing pipelines, hardware security modules, embedded firmware, and every product that ships its own cryptographic library. The earlier SHA-1 to SHA-2 and TLS upgrades each took the better part of a decade, and PQC is broader, changing key sizes, signature sizes, and protocol behavior as well as algorithms. Most enterprises should plan for a multi-year program rather than a single project.
The readiness gap is wide. According to Forescout Research –Vedere Labs, 90% of systems are not quantum safe. Only about 6 percent of devices on the internet use PQC. That’s a sobering fact when paired with the following findings:
- Only 3% of identified servers running Dropbear – common in embedded devices – support PQC, highlighting slower adoption in constrained environments.
- Fewer than 8.5% of SSH servers support post-quantum encryption.
- Under 20% of communications use TLS 1.3, the only TLS version that supports PQC.

Most security teams still cannot produce a current inventory of where cryptography is used across their environment, which is the gap every migration has to close first.
In 2026, there were over 160 million SSH hosts on the internet supporting several different key exchange (KEX) algorithms, which are used to establish session keys for end-to-end encrypted communication. The most popular KEX algorithms running on those servers (see table below) are all variations of traditional and Elliptic Curve Diffie-Hellman (ECDH) and are all susceptible to quantum attacks.
| PQC KEX | #Hosts | %Hosts |
|---|---|---|
| [email protected] | 13,676,692 | 8.53% |
| sntrup761x25519-sha512 | 3,466,567 | 2.16% |
| mlkem768x25519-sha256 | 1,830,040 | 1.14% |
| [email protected] | 41,102 | 0.03% |
| mlkem1024nistp384-sha384 | 17,996 | 0.01% |
| mlkem768nistp256-sha256 | 11,433 | 0.01% |
| Other PQC | 245 | < 0.01% |
From an enterprise network standpoint, Vedere Labs data reveals that PQC support is uneven. For example, while 50% of IT devices use OpenSSH versions that support PQC, only 28% use PQC-capable OpenSSH for IoT, 16% for OT, and 6% for IoMT devices.

This points to a clearly widening readiness gap across device types. Moreover, despite every device type showing noticeable growth, the rate of growth will likely slow as easy-to-upgrade systems migrate first, leaving more complex, legacy environments behind. Given the current pace, no asset class will be fully migrated by 2029 — with IoMT and OT devices facing the highest levels of residual exposure.
Understanding Post-Quantum Cryptography
Post-quantum cryptography refers to algorithms designed to stay secure against an attacker equipped with a large-scale quantum computer. The terms quantum-safe and quantum-resistant describe the same family. These are classical algorithms that run on the hardware you already operate; what changes is the underlying math. Where RSA depends on integer factorization and elliptic-curve cryptography depends on the discrete logarithm problem, PQC relies on problems such as structured lattices and hash-function security that have no known efficient quantum attack.
In August 2024, NIST finalized the first three PQC standards, which anchor the transition for most public and private deployments:
- FIPS 203 (ML-KEM, derived from CRYSTALS-Kyber): key establishment, the replacement for RSA key transport and elliptic-curve key agreement in protocols such as TLS, SSH, and IPsec.
- FIPS 204 (ML-DSA, derived from CRYSTALS-Dilithium): the general-purpose digital signature standard for code signing, certificate signing, and authenticated protocols.
- FIPS 205 (SLH-DSA, derived from SPHINCS+): a hash-based signature scheme used as a conservative hedge where the most minimal security assumption is required.
A fourth standard based on FALCON (FN-DSA) is in advanced standardization and will offer smaller signatures for cases where size is the binding constraint. The practical consequence for implementers is that PQC keys, ciphertexts, and signatures are larger than their RSA and elliptic-curve equivalents, which affects handshake sizes, certificate storage, HSM capacity, and embedded firmware images. None of this is insurmountable, but each is a deliberate engineering decision that needs planning.
Key PQC Algorithms
Four algorithms anchor the practical transition, covering the two primitives most enterprises depend on: key establishment for confidentiality and digital signatures for authenticity.
- ML-KEM (FIPS 203): the key encapsulation mechanism that replaces RSA and elliptic-curve key agreement. Parameter sets run from ML-KEM-512 to ML-KEM-1024, with ML-KEM-768 the common enterprise default. Performance is competitive with elliptic-curve and faster than RSA-2048.
- ML-DSA (FIPS 204): the general-purpose signature scheme. Signatures run roughly 2,400 to 4,600 bytes, well above the 64-byte elliptic-curve signatures most TLS deployments use today, which is a real design constraint for storage and protocols.
- SLH-DSA (FIPS 205): a stateless hash-based signature whose only assumption is the security of its hash function. It is larger and slower, so it suits conservative, infrequently rotated roles such as firmware and root-certificate signing.
- FALCON (FN-DSA, forthcoming): a compact lattice signature of roughly 700 to 1,300 bytes for size-constrained cases such as certificate chains and embedded devices. ML-DSA remains the default; FALCON is the choice when signature size genuinely matters.
What PQC Readiness Means
PQC readiness, or quantum readiness, is the state in which an organization knows where its cryptography lives, can identify which uses are exposed to the quantum threat, has a sequenced plan to migrate those uses, and can execute that plan without breaking the systems that depend on them. It is a continuum of capabilities, not a single milestone.
Readiness starts with knowing what to inventory. The cryptographic surface is wider than it appears and includes:
- Keys, and the systems that generate, store, and rotate them
- Certificates, and the authorities that issue them
- Protocols such as TLS, SSH, and IPsec, and the cipher suites they negotiate
- Hardware security modules and other crypto-bearing hardware
It also helps to separate concurrent exposure from future-only exposure. Long-lived data subject to harvest-now-decrypt-later, long-lived signatures, and embedded devices with multi-decade service lives are exposed now and should migrate first. Short-lived TLS sessions and fast-rotating keys can follow standard refresh cycles. The recurring obstacle behind all of this is visibility: cryptographic systems have operated as quiet, automated infrastructure for so long that few teams track them as a first-class concern. You cannot migrate what you cannot see, so a complete, continuously updated cryptographic inventory is the foundation everything else builds on.
The PQC Migration Roadmap
Migration is most manageable as a repeatable sequence rather than one large project. Seven steps move an organization from discovery to a validated, quantum-safe posture:
- Discover and inventory. Catalog every use of cryptography across IT, OT, and IoT: certificates, keys, protocols, cipher suites, and HSMs. National roadmaps and CISA both name this as the first step.
- Assess risk and prioritize. Rank assets by exposure, giving priority to long-lived data and the systems most vulnerable to harvest-now, decrypt-later.
- Evaluate vendors. Confirm whether the products already in your environment have published PQC roadmaps, and on what timeline.
- Plan the algorithm transition. Map each exposed use to a NIST-standardized replacement, and define owners, target dates, and rollback plans.
- Deploy hybrid cryptography. Run classical and post-quantum algorithms together during the transition, so security holds even if one scheme is later weakened.
- Update protocols and key management. Move to TLS 1.3 and modernize key management so algorithms can be rotated cleanly.
- Test and validate. Benchmark performance, confirm interoperability and compatibility, and verify against published test vectors before and after each change.
This sequence aligns with how a cryptographic posture program operates in practice: detect what encryption is in use, assess and prioritize what is exposed, control the risk on vulnerable systems during migration, and govern the rollout with consistent policy as the transition proceeds.
In 2026, the G7 Cyber Expert Group (CEP) released a coordinated roadmap for PQC in the financial sector. It established 2030-2035 as the critical window for migration. According to the roadmap, 2026 is the beginning of defining your PQC strategy.
The guidance targets financial institutions, but the implications extend far beyond banking. Every organization managing sensitive data – from government agencies to healthcare providers to critical infrastructure operators – faces the same threat in the quantum computing supremacy timeline.
The message is clear: ‘harvest now, decrypt later’ attacks are already underway, so the window to protect against quantum computing threats is closing faster than many realize.
Go deeper: Read “G7’s Post‑Quantum Cryptography Roadmap in Plain English”.
Building Crypto-Agility
Crypto-agility is the ability to change cryptographic algorithms, protocols, and libraries without re-architecting the systems that use them. It is the difference between a migration measured in weeks and one measured in years, and it is now treated as a baseline capability rather than an advanced one.
In practice, crypto-agility means designing systems so algorithms can be updated quickly, ideally through fast or remote updates, without redesigning every application or device. The reason it matters is structural. NIST deliberately selected algorithms from more than one mathematical family to avoid concentration risk, and PQC standards will keep evolving as new algorithms are added and weaknesses are found. Organizations that build agility into governance can respond when standards change, when a vulnerability surfaces, or when a new algorithm becomes required, instead of starting a fresh multi-year migration each time.
Common Challenges in PQC Migration
Most programs stall on the same few obstacles. The first is the absence of a formal PQC strategy: many cybersecurity teams have not assigned ownership or set a timeline. The second is hardware, because PQC keys and signatures are larger than their predecessors and many deployed HSMs were not provisioned for the additional storage and throughput. The third is the visibility gap, since most organizations still lack a full inventory of where encryption is used. The fourth is coordination, because migration requires aligned action across governance, risk, technology, and vendor relationships rather than one team working alone.
How Forescout Supports Quantum-Safe Readiness
Forescout helps you identify which of your encrypted traffic is most likely to be harvested today, understand the level of its exposure, and reduce that exposure before quantum decryption is viable. To do this, Forescout’s solution for PQC readiness treats it as a visibility problem first. Using the Forescout Vistaro™ platform with patented PQC technology and agentic AI, you benefit from patented, agentless technology that analyzes the cryptographic ciphers each device supports across IT, OT, and IoT, scores them against post-quantum safety standards, and surfaces encryption risk, even for unmanaged or evasive devices. All of this happens within the context of real network behavior. That cryptographic posture visibility then feeds the platform, where teams can prioritize at-risk assets, segment critical systems, limit exposure for vulnerable devices, and track PQC adoption over time. The result is the continuous, real-time inventory that every migration roadmap depends on.

Next Steps
Three actions create momentum without waiting for perfect information:
- Conduct a cryptographic inventory this quarter so you know where encryption lives.
- Form a cross-functional PQC working group spanning security, infrastructure, and vendor management.
- Engage your key vendors on their PQC roadmaps, and pilot hybrid approaches in non-critical systems to build experience before high-stakes migrations begin. To understand your specific exposure, start by making your cryptographic posture visible across every connected asset.
To help, watch this webinar for an executive-level discussion on preparing for PQC. Learn how to identify quantum-vulnerable cryptography, understand which exposures pose the greatest business risk, and prioritize remediation efforts across complex IT, OT, IoT, and IoMT environments.
See all of Forescout’s PQC coverage:
- Before Q‑Day, Visibility Is the First PQC Move
- G7 Sets Quantum Deadline: Roadmap Signals Industry Urgency for All
- The Future of Encryption in a Quantum Cryptography World
- Forescout Unveils Breakthrough Patented Technology to Detect Non-Quantum-Safe Encryption Across IT, OT, and IoT
- Post-Quantum Cryptography: The Real Risks of Not Adopting It
Frequently Asked Questions
What does PQC stand for?
PQC stands for post-quantum cryptography: cryptographic algorithms designed to remain secure against attackers using large-scale quantum computers. The terms quantum-safe and quantum-resistant are used interchangeably. PQC algorithms run on today’s classical hardware; only the underlying mathematics changes.
When will quantum computers break current encryption?
No quantum computer can break RSA or elliptic-curve cryptography today. Credible estimates place that capability in roughly the 2030 to 2035 range for critical systems, though the date remains uncertain. The point is the asymmetry: data harvested now can be decrypted later, so waiting carries risk regardless of the exact timeline.
How long does PQC migration typically take?
Plan for a multi-year program. Comparable transitions, SHA-1 to SHA-2 and the move to modern TLS, each took close to a decade, and PQC is broader in scope.
Should we replace all classical cryptography immediately?
No. RSA and elliptic-curve cryptography remain secure against today’s classical attacks. A hybrid approach that runs classical and post-quantum algorithms together is the recommended path during the transition. Prioritize long-lived data and high-exposure systems first.
How do hybrid approaches reduce migration risk?
Hybrid deployments run a classical algorithm and a post-quantum algorithm together, so a session is at least as secure as the stronger of the two. They provide defense in depth if either scheme is later weakened, preserve interoperability with peers that still support only classical algorithms, and let teams gain operational experience with PQC before committing to PQC-only. The trade-off is added complexity in cipher-suite negotiation and slightly larger handshakes.
Which NIST algorithm should we prioritize?
For most enterprises, ML-KEM (FIPS 203) for key establishment and ML-DSA (FIPS 204) for signatures are the general-purpose defaults. SLH-DSA (FIPS 205) suits conservative, infrequently rotated trust anchors, and the forthcoming FALCON-based standard fits cases where signature size is the binding constraint.
