Post-Quantum Cryptography Migration: What Software Teams Should Do Now

What is post-quantum cryptography?

Post-quantum cryptography (PQC) is a set of public-key algorithms that run on ordinary computers but rest on mathematical problems that neither classical nor quantum computers are known to solve efficiently. Today most key exchange and signing on the internet uses RSA, Diffie-Hellman and elliptic curves, and all three fall to Shor’s algorithm once a large enough quantum computer exists. PQC replaces them. Symmetric ciphers such as AES-256 and hashes such as SHA-384 stay in place.

• NIST published the first three post-quantum standards on August 13, 2024: FIPS 203 (ML-KEM) for key exchange, FIPS 204 (ML-DSA) for signatures, and FIPS 205 (SLH-DSA) as a hash-based backup signature scheme.
• NIST’s transition report IR 8547 sets the direction: quantum-vulnerable algorithms such as RSA-2048 and ECDSA P-256 are deprecated after 2030 and disallowed after 2035.
• Data encrypted today can be recorded and decrypted later. This “harvest now, decrypt later” risk is why Cloudflare reported that more than half of human-initiated traffic on its network already used post-quantum key agreement by October 2025.
• Hybrid TLS, which pairs X25519 with ML-KEM-768 in one handshake, is the deployed path for transport encryption and is enabled by default in Chrome, Firefox, OpenSSL 3.5 and Apple platforms.
• Post-quantum certificates lag key exchange because ML-DSA signatures are far larger than ECDSA or Ed25519 signatures, so teams should migrate key exchange first and plan signatures second.
• The migration is an engineering program, not a library swap: inventory, crypto agility, hybrid deployment, vendor tracking and wire-level verification, in that order.

Why does a post-quantum cryptography migration matter now?

No quantum computer can break RSA-2048 today. The reason to act now is that resource estimates keep falling and the deadlines are already set. In May 2025 Google’s Craig Gidney showed that a 2048-bit RSA key could be factored in under a week with fewer than one million noisy qubits, down from the 20 million qubits he estimated in 2019. The Quantum Threat Timeline Report 2025 by Michele Mosca and Marco Piani, a survey of 26 experts for the Global Risk Institute, puts the chance of a cryptographically relevant quantum computer within 10 years at 28 to 49 percent and within 15 years at 51 to 70 percent, the highest 10-year estimate in the survey’s history.

A harvest now, decrypt later attack is one where an adversary records encrypted traffic today and decrypts it once a quantum computer becomes available. Mosca’s framing makes the exposure concrete: if the years your data must stay secret plus the years your migration will take exceed the years until a quantum computer arrives, the data is already at risk. Medical records, contracts, source code and payment histories need confidentiality measured in decades, which is why key exchange is the first thing to fix.

The NSA’s CNSA 2.0 suite names ML-KEM-1024 and ML-DSA-87 for national security systems, and the UK NCSC roadmap and the EU coordinated implementation roadmap converge on 2035, with the EU asking member states to start national transitions by the end of 2026 and to finish high-risk systems by 2030. If your product sells to governments, banks or critical infrastructure, procurement checklists will carry these dates before the quantum computer does.

Which NIST PQC standards replace RSA and elliptic curves?

The NIST PQC standards are three Federal Information Processing Standards published on August 13, 2024. Each has a formal name and the competition name most engineers still use.

• ML-KEM (Kyber), FIPS 203. A key-encapsulation mechanism: one party publishes a public key, the other encapsulates a fresh shared secret against it. ML-KEM is lattice-based and comes in three parameter sets, ML-KEM-512, ML-KEM-768 and ML-KEM-1024, in order of increasing security and decreasing speed. ML-KEM-768 is the common choice for TLS. It replaces ECDH and Diffie-Hellman key exchange.
• ML-DSA (Dilithium), FIPS 204. A lattice-based digital signature scheme in three sizes, ML-DSA-44, ML-DSA-65 and ML-DSA-87. It replaces RSA, ECDSA and Ed25519 signatures in certificates, code signing, tokens and firmware.
• SLH-DSA (SPHINCS+), FIPS 205. A stateless hash-based signature scheme whose security depends only on the hash function. Signatures are large and slow, so it is a conservative backup for roots of trust and firmware rather than a per-request signer.

Kyber and ML-KEM are not interchangeable. NIST made small technical changes during standardization, and Google’s security blog explained in September 2024 that Chrome 131 would drop the draft Kyber codepoint and move to the final ML-KEM codepoint rather than run both. A library that still speaks draft Kyber needs an upgrade, not a rename.

What changes in TLS, digital signatures and key management?

Hybrid TLS is the deployed path for transport encryption

Hybrid TLS is a TLS 1.3 handshake that runs a classical key exchange and a post-quantum key exchange together and derives the session key from both, so an attacker must break both to read the traffic. The IETF specification for hybrid key agreement in TLS 1.3 defines X25519MLKEM768 and two NIST-curve variants, with the shared secret formed by concatenating the ML-KEM and elliptic-curve secrets. It is the group Chrome, Firefox, Go, OpenSSL 3.5 and, since October 2025, Apple’s platforms negotiate by default, and the one Cloudflare’s 2025 report credits for taking post-quantum key agreement past half of human web traffic on its network.

For a software team, most of the transport layer therefore migrates through dependency upgrades: the TLS library, the reverse proxy, the load balancer and the CDN. What does not migrate by itself is anything that pins supported groups in configuration, terminates TLS in an older appliance, or inspects handshakes with middleboxes that reject a larger ClientHello. An ML-KEM-768 encapsulation key is 1,184 bytes under FIPS 203, against 32 bytes for X25519, which is enough to split the hello across packets and expose fragile network gear.

Signatures and certificates are the hard part

Post-quantum signatures are where the migration slows down. Cloudflare’s 2024 analysis counts roughly six signatures and two public keys in a typical browser TLS handshake, and an ML-DSA-44 signature is 2,420 bytes against 64 bytes for Ed25519, so a fully post-quantum certificate chain adds around 15 to 17 kilobytes to every new connection. Cloudflare’s measurements put the slowdown from that extra data at about 15 percent. As of October 2025 no publicly trusted post-quantum web certificates existed: the IETF had not finalized hybrid certificate formats, hardware security module support was incomplete, and the CA/Browser Forum had not approved issuance. Early certificates are expected in 2026 and broad availability is unlikely before 2027.

That does not mean signatures wait. Where your team controls both signer and verifier, ML-DSA can go in now: service-to-service authentication, signed build artifacts, firmware, signed webhooks and short-lived tokens. Public web certificates are the last mile, not the first.

Key management and stored data

Key management is where long-lived data lives. Data at rest is usually protected by envelope encryption: a symmetric data key wraps the payload, and a key-encryption key in a key management service wraps the data key. AES-256 is safe against known quantum attacks, so the exposure is not the payload but any place where a data key, a backup key or a database secret is wrapped, exported or transported with RSA or ECDH. Those operations need ML-KEM or a hybrid, and a key that wraps ten years of backups is a ten-year exposure if the wrapped material was ever captured.

How should a software team plan a PQC migration?

A PQC migration for a software team runs in five stages. They overlap, but the order matters because each produces the information the next one needs.

1. Build a cryptographic inventory

A cryptographic inventory is a list of every place your product uses public-key cryptography, with the algorithm, key size, library, version, owner and the lifetime of the data it protects. Most teams find it in five places: TLS termination, tokens and sessions, code and artifact signing, key wrapping for data at rest, and third-party SDKs. The NIST National Cybersecurity Center of Excellence’s Migration to Post-Quantum Cryptography project documents a discovery approach that combines code scanning, host agents and network traffic analysis, because no single tool finds everything. Record the data lifetime beside each entry: that column turns the inventory into a priority list.

2. Design for crypto agility

Crypto agility is the property that an application can change its cryptographic algorithms, key sizes and libraries through configuration and dependency updates rather than code rewrites. In practice it means no algorithm names hard-coded in application code, one cryptographic module per language, key and certificate identifiers that carry the algorithm with them, and integration tests that assert the negotiated algorithm rather than only that the connection succeeded. Agility is also what lets you move again if a lattice scheme is weakened, which is the whole argument for hybrids.

3. Deploy hybrid key exchange first

Turn on X25519MLKEM768 at every TLS endpoint you control, starting from the edge. OpenSSL 3.5, released in April 2025 as a long-term support version maintained until April 2030, ships ML-KEM, ML-DSA and SLH-DSA and prefers the hybrid group by default, so for many stacks this is a version bump plus a check that nothing downstream overrides the group list. Do the same for internal traffic: service meshes, database connections, message brokers and VPNs carry the same long-lived data and are usually terminated by software you can upgrade.

4. Track vendors and dependencies

Every SDK, payment gateway, identity provider, hardware security module and managed database in the inventory has its own migration. Ask each vendor three questions in writing: which post-quantum algorithms they support today, when hybrid key exchange becomes the default on their endpoints, and when they will issue or accept ML-DSA certificates. Record the answers in the inventory, revisit them quarterly, and require NIST-standardized algorithms and a published transition date in new contracts.

5. Verify on the wire, not in the config

A configuration that enables ML-KEM is not evidence that ML-KEM is negotiated. In a paper I co-authored with Vishnu Ajith and Muhammed Sihan Haroon (IACR ePrint 2026/834), we classified endpoints as classical-only, post-quantum-only or hybrid by parsing the ServerHello key share group at the byte level instead of trusting the deployment. Across 38 production endpoints and a three-node cloud testbed, the first phase flagged an application server as classical-only even though the application itself was PQC-capable, because the TLS frontend in front of it had never been upgraded. That gap between application-layer and transport-layer configuration is common, and it only shows up when you inspect the handshake.

Where do the cloud providers stand on quantum-safe cryptography?

A quantum-safe cloud is one whose managed services negotiate post-quantum key exchange on their endpoints and offer post-quantum algorithms in their key management service. All three major providers now do both, with different defaults and regional coverage, so check the documentation for the service and region you use.

• AWS offers hybrid ML-KEM key agreement on the endpoints of KMS, Certificate Manager, Secrets Manager, IAM, S3 and CloudFront, and its KMS added ML-DSA signing keys in June 2025, with Private CA following in November 2025. Its s2n-tls library and AWS-LC module carry the implementations.
• Microsoft ships ML-KEM and ML-DSA in SymCrypt, the library behind Windows, Azure and Microsoft 365, and exposes them through the Windows Cryptography API: Next Generation. Its August 2025 roadmap targets early adoption by 2029 and a completed transition across its services and products by 2033.
• Google Cloud made ML-DSA, SLH-DSA-SHA2-128s and ML-KEM generally available in Cloud KMS in July 2026, after previewing ML-KEM and the X-Wing hybrid in October 2025 with a commitment to post-quantum protection for its own connections in 2026.

If your data at rest is wrapped by a cloud key management service, that wrap operation is already inside the provider’s post-quantum cryptography migration, and your job is to confirm it rather than rebuild it. Your remaining exposure is the code you own: the TLS your services terminate, the tokens you sign, the keys you export and the libraries you pin.

What are the common pitfalls in a post-quantum migration?

• Treating the post-quantum cryptography migration as a single upgrade. The inventory, not the library, is the deliverable of the first quarter.
• Assuming the platform did it. A hybrid-capable application behind a classical proxy is classical on the wire, as the ePrint study above found on its own testbed.
• Pure post-quantum key exchange in production. Hybrid is the default in Cloudflare, OpenSSL and every major browser during the transition, because lattice cryptanalysis is young.
• Skipping data lifetime. A marketing site has little to lose to harvest now, decrypt later; a health record store or a code-signing key has decades.
• Waiting for certificates. Public post-quantum certificates are a 2027 problem; internal signatures, artifact signing and key exchange are a 2026 problem.

How does Sigi Technologies build with crypto agility?

Sigi Technologies does not sell post-quantum cryptography as a product and claims no security certification. What Sigi offers is custom software development and DevOps and cloud engineering that build the agility described above into a product from the start: TLS configuration owned in infrastructure as code with supported groups set explicitly, key management delegated to the cloud provider’s key service rather than hand-rolled, dependency upgrades scheduled rather than deferred, and deployment checks that assert what the wire negotiates. That is the difference between a migration that is a series of version bumps and one that is a rewrite.

Related reading

For the compliance side of payments and account data, read the guide to how to build a fintech app. For long-lived personal data and the governance around it, see CQC compliant care software and UK GDPR. For dependency upgrades, TLS configuration and pipeline checks on a product that already ships, see adding DevOps to a live product. For an AWS deployment Sigi contributed to, with infrastructure as code and CI pipelines, see the 3DLogistiX warehouse platform case study. If your product must pass a bank or government security review, see Sigi’s custom software development service, the DevOps and cloud service, or contact the team with your cryptographic inventory as it stands.