Post-quantum cryptography: a planning timeline for mid-market

In August 2024, NIST published the first finalised post-quantum cryptography standards: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures, SLH-DSA (FIPS 205) for stateless hash-based signatures. The migration from RSA and elliptic-curve cryptography to post-quantum equivalents is no longer a research topic: the standards exist, the libraries are maturing, the major vendors have public roadmaps.

For most mid-market organisations, the response is somewhere between do nothing yet and immediately replatform, and the right response depends on what you’re protecting and how long it has to stay confidential.

The threat model

The relevant threat is harvest now, decrypt later. An adversary captures encrypted traffic today, stores it, and decrypts it years later when a sufficiently capable quantum computer becomes available. Anything currently encrypted with RSA or ECDH that still needs to be confidential in (very approximately) 2035 or beyond is at risk.

For a mid-market financial services organisation, the categories of data that fall in scope:

• Customer records with long retention obligations (often 7 years; some 25+).
• Long-lived secrets: root signing keys, certificate authorities, code signing keys.
• Compliance and audit data with multi-decade retention.
• Strategic and M&A documents that retain confidentiality value indefinitely.

Categories that don’t really fall in scope:

• Session-bounded data: anything where the relevance ends in months not decades. Most operational traffic.
• Already-public information: marketing material, public disclosures, financial reports after release.
• Short-retention data: most logs and operational records past their retention window.

The threat model determines the urgency. Confidentiality of customer records for 7+ years pushes you toward earlier migration. Operational data with 1-year retention does not.

The realistic timeline

For mid-market organisations, the planning horizon we use:

Year	Activity
2025	Cryptographic inventory; vendor enquiry on roadmaps
2026	Vendor commitments; pilot of hybrid PQ/classical for high-value paths
2027	Production deployment of PQ for new high-confidentiality systems
2028	Migration of existing high-confidentiality systems
2029-2030	Default for new systems; broader migration
2031+	Long tail; legacy and embedded systems

This timeline assumes vendors continue current trajectories and no major breakthrough in quantum computing capability accelerates the threat. If either changes materially, the timeline compresses.

Step 1: Cryptographic inventory

The current task for most mid-market organisations is inventory. What cryptography do we use, where, for what? The answer is rarely complete in any organisation we review. For the operational detail on running the inventory, engineering cryptographic agility, and the attacks on encryption happening today, see our companion piece on managing cryptography in the post-quantum era.

The inventory captures:

• TLS endpoints: every HTTPS surface, internal and external. Cipher suites in use, certificate algorithms, certificate authorities.
• Internal CA: certificate authority topology, signing algorithms, root and intermediate certificate algorithms.
• Code signing: software, scripts, deployment artefacts. Signing key algorithms.
• VPN and IPsec: site-to-site, remote access. Key exchange and encryption algorithms.
• Database and file encryption at rest: KMS providers, key derivation functions, encryption algorithms.
• Email security: S/MIME, DKIM signing, TLS for transport.
• Identity: OAuth/OIDC token signing, SAML signing, federation key material.
• Cloud KMS: customer-managed keys, BYOK arrangements, HSM integrations.
• Embedded devices: IoT, OT, hardware tokens with embedded crypto.

The inventory is a multi-week exercise. The output is a register that becomes the spine of the migration program.

Step 2: Vendor commitments

For each major cryptographic provider in the inventory, the question is: what is your post-quantum roadmap? Most major vendors have public commitments by now. The key vendor categories:

• Certificate authorities: roadmap for PQ certificate issuance.
• TLS terminators / load balancers: support for PQ key exchange and PQ certificates.
• HSMs and cloud KMS: PQ algorithm support, key generation, signing.
• VPN / IPsec products: PQ in IKE.
• Browsers and runtime libraries: PQ support.
• Identity providers: PQ-aware token signing.

For each vendor, capture the roadmap, the migration path, and the expected support window. Vendors without a credible roadmap are risk. They go on a watchlist for replacement.

Step 3: Crypto-agility

The substantive technical work that pays off regardless of post-quantum specifically: making the cryptographic implementations agile. That means:

• The algorithm in use is not hard-coded. Configuration determines the algorithm.
• The system can negotiate algorithms with peers.
• Algorithm rotation does not require code changes; it requires configuration changes and (where applicable) certificate or key rotation.

Most modern TLS stacks are agile by default; older systems and bespoke implementations often are not. The migration cost for an agile system is hours; for a non-agile system, weeks to months.

Step 4: Hybrid PQ deployment

The interim posture, currently the consensus practice, is hybrid, combining classical (ECDH or RSA) with post-quantum (ML-KEM) so that the security depends on either algorithm holding. If one is broken, the other still protects.

Hybrid deployment is the production-ready path for the next several years. Pure PQ deployment is reserved for cases where the additional cost is justified by extreme threat sensitivity, typically not mid-market commercial.

The hybrid mode is supported by major TLS terminators, modern browsers, and key cloud providers as of late 2025. Deployment is largely configuration.

Step 5: Long-lived signing keys

Signing keys with multi-year validity (root CAs, code signing) are a separate concern from confidentiality. The risk is that a future PQ-capable adversary forges signatures that appear historical.

For these, the migration involves either:

• Re-issuing roots with PQ-compatible algorithms (ML-DSA / SLH-DSA).
• Maintaining classical and PQ root CAs in parallel during a transition period.

Code signing has additional complexity around the signature verification chain on existing devices. Older platforms may not support PQ verification, requiring careful planning around platform support.

What to do this quarter

For most mid-market organisations, the productive work this quarter is:

1. Run the cryptographic inventory.
2. Send the vendor enquiry letter to your major cryptographic providers: what’s your PQ roadmap, what’s the migration path, what support do you offer?
3. Identify the systems with the longest confidentiality obligation and prioritise them for the 2027 to 2028 migration window.
4. For new systems being designed now, require crypto-agility. Don’t bake in classical-only assumptions.

The rest of the program scales out over the following 24 months. There is no urgency to move beyond inventory and crypto-agility for the average mid-market environment. There is urgency to start that work, because the migration is real and the timeline is now measurable in single-digit years.

For organisations that need a structured cryptographic inventory and vendor risk assessment as part of broader security work, the Security Posture Assessment includes the cryptographic posture as one component of the engagement.