PQC Migration Timeline for SaaS Companies

Published

By Post Quantum Field · We verify claims against NIST publications, vendor changelogs, and IETF drafts. Experimental support is never presented as production-ready.

SaaS companies face a fundamentally different post-quantum migration challenge than enterprise IT departments. You control both ends of the server stack, you can deploy updates on your own schedule, and you do not need to coordinate with thousands of desktops and branch offices. But you have a constraint enterprises do not: your customers connect from a wild variety of clients, some of which will not support post-quantum cryptography for years.

This guide provides a practical, phased migration timeline for a typical SaaS company. It accounts for backward compatibility requirements, the current state of client-side PQC support, and the regulatory timeline that will eventually force the hand of laggards.

Why SaaS is different

Advantages you have over enterprises

You control the server stack. When you decide to enable PQC on your TLS termination, API gateways, or internal service mesh, you deploy it. There is no committee of business unit stakeholders debating whether the change might break a 15-year-old SAP integration.

You deploy continuously. SaaS companies typically ship multiple times per day. Cryptographic changes can be rolled out gradually, tested in canary deployments, and rolled back in minutes if something breaks.

Your infrastructure is modern. Most SaaS companies run on AWS, Google Cloud, or Azure, where specific PQC capabilities are available at different maturity levels across TLS, libraries, signing, KEM, and key-management workflows. That can reduce platform constraints, but provider adoption does not automatically make a SaaS workload quantum-safe.

You can observe client behavior. Through TLS handshake telemetry, you can see exactly which cipher suites and key exchange groups your clients negotiate. This gives you data on PQC readiness before you make any changes.

Constraints that make it harder

Your customers control the client. Even if your server offers X25519MLKEM768, clients running older TLS libraries will negotiate classical key exchange. You cannot force customers to upgrade.

API clients are sticky. Enterprise customers that integrate with your API often use pinned SDK versions, custom HTTP clients, or corporate proxies that may not support PQC cipher suites. Breaking their integration is unacceptable.

Backward compatibility is non-negotiable. Unlike an internal enterprise system where you can mandate client upgrades, a SaaS product must continue serving clients that do not support PQC while simultaneously providing PQC for clients that do.

Compliance timelines vary. Your customers operate in different jurisdictions with different PQC mandates. A US government customer may require PQC by 2027, while a small European startup may not think about it until 2033.

Data retention obligations. Some of your customers store sensitive data for decades. Traffic encrypted with classical key exchange today is vulnerable to harvest-now-decrypt-later attacks. You bear some responsibility for protecting that data in transit.

The phased timeline

This timeline assumes a mid-size SaaS company (100-1000 employees, modern cloud infrastructure, mix of self-serve and enterprise customers). Adjust based on your regulatory environment and customer base.

Phase 0: Assessment (Now through Q4 2026)

Duration: 2-3 months

Objective: Understand your current cryptographic posture and customer readiness.

Actions:

  1. Inventory your TLS termination points. Where does TLS terminate? Load balancers, CDNs, API gateways, reverse proxies? What software/version handles the handshake?

  2. Check your TLS library versions. Verify whether your stack already supports X25519MLKEM768:

    • OpenSSL 3.5+: Yes (default group)
    • BoringSSL: Yes
    • AWS-LC/s2n-tls: Yes
    • Go 1.24+: Yes (default)
    • Nginx with OpenSSL 3.5: Yes
    • Envoy with BoringSSL: Yes

  3. Measure client PQC support. Enable TLS handshake logging and analyze which clients already send X25519MLKEM768 key shares. As of mid-2026:

    • Chrome 124+ (April 2024): Default PQ key exchange
    • Firefox 132+ (November 2024): Default PQ key exchange
    • Safari/iOS 18+ (October 2025): PQ key exchange
    • curl with OpenSSL 3.5+: Supported
    • Python requests with recent OpenSSL: Supported
    • Enterprise Java clients: Depends on JDK version and TLS provider

  4. Identify sensitive data flows. Which API endpoints handle data with long confidentiality requirements (medical records, financial data, trade secrets, government data)? These are priority targets for PQC key exchange.

  5. Map your internal service mesh. Service-to-service communication (gRPC, internal REST, message queues) should be inventoried separately from external-facing TLS.

Phase 1: Enable hybrid key exchange on external endpoints (Q4 2026 - Q1 2027)

Duration: 3-4 months

Objective: Offer PQC key exchange to all clients that support it, without breaking any client that does not.

Actions:

  1. Update TLS configuration to include X25519MLKEM768 in the offered key exchange groups:
# Nginx with OpenSSL 3.5+
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1:secp384r1;
# Envoy proxy
tls_params:
  ecdh_curves:
    - X25519MLKEM768
    - X25519
    - P-256

  1. Deploy to canary first. Route 1-5% of traffic through the updated configuration and monitor for:

    • Handshake failure rates
    • Latency increases
    • Client error reports
    • Middlebox/proxy incompatibilities

  2. Communicate with enterprise customers. Some enterprises route traffic through corporate proxies that inspect TLS. The larger ClientHello from hybrid key exchange may cause issues with older inspection appliances. Provide advance notice and documentation.

  3. Monitor adoption metrics. Track what percentage of your inbound connections negotiate X25519MLKEM768 versus classical groups. This gives you a dashboard of real-world PQC adoption among your customer base.

  4. Handle edge cases. If specific clients consistently fail with PQC enabled:

    • Do not disable PQC globally
    • Consider client-specific TLS policies if your infrastructure supports it
    • Document the workaround and communicate a timeline for client upgrades

Success criteria: PQ key exchange available for all clients that support it. Zero regressions for clients that do not support it. Baseline metrics established.

Phase 2: Internal service mesh migration (Q1 - Q3 2027)

Duration: 6 months

Objective: Protect service-to-service communication with PQC key exchange.

Actions:

  1. Update mTLS certificates and key exchange for internal services. Since you control both ends of internal communication, you can mandate PQC support:
# Istio service mesh example
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT
  # TLS configuration handled at Envoy proxy level

  1. Upgrade service mesh sidecars to versions that support hybrid key exchange. Envoy-based meshes (Istio, Consul Connect, Linkerd) use BoringSSL or OpenSSL, which already support X25519MLKEM768.

  2. Update internal SDK clients. If your services communicate using custom SDK clients, update their TLS configuration to prefer hybrid key exchange.

  3. Database connections. Evaluate PQC for database wire encryption (PostgreSQL, MySQL). Most database drivers use OpenSSL, so hybrid support depends on the linked OpenSSL version.

  4. Message queues and event buses. Kafka, RabbitMQ, NATS connections should be upgraded similarly. These are internal communications where you control both ends.

Success criteria: All internal service-to-service traffic uses hybrid PQ key exchange. No classical-only connections between your own services.

Phase 3: Signing and key management (Q3 2027 - Q2 2028)

Duration: 9-12 months

Objective: Migrate digital signatures and key management to post-quantum algorithms.

Actions:

  1. API tokens and JWTs. Evaluate migrating token signing to ML-DSA or composite (ML-DSA + ECDSA) algorithms. This requires that token verifiers (your own services and potentially customer systems) support the new algorithms.

    Caution: If customers verify your JWTs on their end, you cannot change the signing algorithm without coordinating with them. Consider a dual-signing period where tokens carry both classical and PQC signatures.

  2. Webhook signatures. If you sign webhooks sent to customer endpoints, the same dual-signing approach applies. Provide both signature headers and allow customers to verify either.

  3. Data-at-rest encryption keys. Evaluate whether your key hierarchy should incorporate PQC:

    • Key wrapping with ML-KEM for new master keys
    • Gradual re-wrapping of existing data encryption keys
    • Key rotation schedules that introduce PQC key material

  4. Code signing and build artifacts. Sign your release artifacts with ML-DSA (in addition to existing signatures) so that customers can verify software integrity in a post-quantum future.

  5. Cloud KMS integration. Map signing, KEM operations, TLS transport, and key import separately. Google Cloud KMS offers GA PQ signatures and Preview quantum-safe import for software-backed keys. Use the latter for a controlled pilot, not as evidence that an HSM-backed or complete workload migration is finished. See the Google Cloud PQC support guide.

Success criteria: All new signing operations use post-quantum or hybrid algorithms. Legacy signatures continue working for backward compatibility. Key management infrastructure supports PQC key material.

Phase 4: Customer-facing PQC requirements (Q2 2028 - Q4 2029)

Duration: 18 months

Objective: Begin encouraging and eventually requiring customers to support PQC.

Actions:

  1. Publish PQC support documentation. Provide guides showing customers how to connect with PQC-capable clients.

  2. Add PQC compliance to enterprise tier agreements. For customers in regulated industries, offer PQC compliance attestation as a premium feature.

  3. Deprecation notices for classical-only connections. Begin communicating that classical-only TLS connections will eventually be deprecated. Follow a standard deprecation cycle:

    • Announcement (18 months before enforcement)
    • Warning headers on classical-only connections (12 months before)
    • Rate limiting or reduced SLA for classical-only connections (6 months before)
    • Hard requirement (enforcement date)

  4. Provide migration tooling. If you distribute client SDKs, update them to support PQC and make the updated SDK the default download.

  5. Audit trail and compliance reporting. Offer customers visibility into whether their connections use PQC, for their own compliance reporting.

Success criteria: Majority of customer traffic (>80%) uses hybrid PQ key exchange. Clear deprecation timeline communicated for classical-only connections.

Phase 5: Classical deprecation (2030-2032)

Duration: 2 years

Objective: Remove support for classical-only connections where regulatory and customer readiness allows.

Actions:

  1. Enforce PQC for new customers. All new integrations must use PQC-capable clients.

  2. Gradual enforcement for existing customers. Work with the remaining classical-only customers to upgrade. For the few that genuinely cannot upgrade (legacy embedded systems, extremely old Java clients), provide documented exceptions with risk acknowledgment.

  3. Remove classical key exchange groups. Once customer telemetry shows negligible classical-only traffic, remove X25519-only and P-256-only from offered groups.

  4. Align with regulatory deadlines. NIST IR 8547 targets 2030 for deprecation of 112-bit classical algorithms and 2035 for disallowance. Your timeline should align with these dates for customers that require regulatory compliance.

Success criteria: All customer connections use at least hybrid PQ key exchange. Classical-only connections are explicitly denied.

Handling backward compatibility

The backward compatibility challenge is the central tension of SaaS PQC migration. Here are the concrete strategies:

TLS group negotiation

TLS 1.3 key exchange group negotiation handles backward compatibility automatically. If you offer [X25519MLKEM768, X25519, P-256] and the client only supports [X25519, P-256], the handshake selects X25519. No errors, no failures, no user-visible impact.

This means enabling PQC on your server side is completely backward-compatible. You are adding capability, not removing it.

API versioning for signatures

If you need to change signature algorithms for tokens or webhook payloads, use API versioning:

# Webhook payload with dual signatures
X-Signature-ECDSA: <classical signature>
X-Signature-MLDSA: <post-quantum signature>
X-Signature-Algorithm: ecdsa-p256,ml-dsa-65

Clients that understand PQC verify the ML-DSA signature. Clients that do not verify the ECDSA signature. You remove the classical signature only after all clients have confirmed PQC support.

Feature flags and gradual rollout

Use feature flags to control PQC behavior per customer:

if customer.pqc_enabled:
    sign_with_algorithm("ml-dsa-65")
else:
    sign_with_algorithm("ecdsa-p256")

This lets you migrate customers individually based on their readiness.

Cost and resource estimation

For a mid-size SaaS company, the PQC migration cost is primarily engineering time, not infrastructure spend:

PhaseEstimated effortInfrastructure cost
Phase 0 (Assessment)2-4 engineer-weeksMinimal (logging)
Phase 1 (External TLS)4-8 engineer-weeksTLS library updates, possible CDN config
Phase 2 (Internal mesh)8-16 engineer-weeksService mesh upgrades
Phase 3 (Signing/KMS)12-20 engineer-weeksKMS changes, token infrastructure
Phase 4 (Customer-facing)8-12 engineer-weeksDocumentation, tooling
Phase 5 (Deprecation)4-8 engineer-weeksCustomer communication

Total: 38-68 engineer-weeks spread over 4-6 years.

The bandwidth cost of hybrid TLS is approximately 1.1 KB additional per handshake. For a service handling 10 million connections per day, that is roughly 11 GB of additional bandwidth daily. At cloud CDN pricing, this is negligible.

What to tell your customers

Different customer segments need different messages:

Self-serve customers (small businesses, developers)

“We have enabled post-quantum encryption on all connections. If you use a modern browser or recent SDK version, your traffic is automatically protected against future quantum computing threats. No action required on your end.”

Enterprise customers (IT procurement teams)

“Our platform supports hybrid post-quantum key exchange (X25519MLKEM768 per RFC 10024) for all TLS connections. We can provide a compliance attestation for your security audits. Your integration will continue working with classical TLS while you upgrade your client libraries on your own timeline.”

Regulated industry customers (government, healthcare, finance)

“We are aligned with the NIST IR 8547 transition timeline. Our infrastructure supports post-quantum key exchange today and will meet the 2030 deprecation and 2035 disallowance deadlines. We offer PQC compliance documentation for FedRAMP, HIPAA, and SOC 2 audits.”

Common mistakes to avoid

  1. Waiting for all customers to be ready. You will never reach 100% customer PQC readiness before you deploy. The TLS negotiation mechanism handles backward compatibility automatically. Deploy PQC server-side now.

  2. Making PQC opt-in for the server. PQC key exchange should be the default server configuration, not something each customer must request. Opt-out (for specific legacy integrations) is acceptable; opt-in is wrong.

  3. Ignoring the harvest-now-decrypt-later threat. The data your customers send today may be decrypted in 10-15 years by a quantum computer. Every day you delay PQC key exchange is a day of traffic exposed to this future risk.

  4. Over-engineering the signature migration. Start with key exchange (Phase 1), which is transparent and risk-free. Do not block TLS migration on the more complex signature migration.

  5. Forgetting internal traffic. Service-to-service communication often carries the same sensitive data as external API calls. If you protect external connections but leave internal traffic classical, you have a gap.

  6. Breaking existing integrations. Never remove classical cipher suites without a long deprecation cycle and customer communication. The goal is adding PQC, not removing classical (yet).

Frequently asked questions

Do I need to change my application code to support PQC TLS?

No. PQC key exchange is handled at the TLS library level. If you update your TLS termination software (Nginx, Envoy, your cloud load balancer), your application code remains unchanged. Clients that support PQC will negotiate it automatically.

What percentage of my traffic is already PQC-protected?

As of mid-2026, approximately 50-60% of browser traffic supports X25519MLKEM768 (Chrome, Firefox, Safari). For API clients (SDKs, curl, custom integrations), the percentage is lower and depends on which TLS library versions your customers use. You can measure this through TLS handshake logging on your load balancers.

What if a customer’s corporate proxy blocks PQC?

Some corporate HTTPS inspection proxies cannot handle the larger TLS ClientHello from hybrid key exchange. These proxies typically cause the connection to fail or downgrade. Chrome and Firefox include fallback mechanisms that retry without PQC. For API clients without built-in fallback, the customer needs to update their proxy or whitelist your endpoints.

Should I get FedRAMP authorization with PQC?

If you serve US government customers, demonstrating PQC support strengthens your FedRAMP authorization. CISA and NIST are actively promoting PQC migration for federal systems. While PQC is not yet mandatory for FedRAMP, being ahead of the requirement is a competitive advantage.

What about data at rest?

This guide focuses on data in transit (TLS). For data at rest, PQC is less urgent because symmetric encryption (AES-256) is already quantum-safe. The risk lies in the key management layer: if key wrapping uses RSA or ECDH, those wrapped keys could be unwrapped by a quantum computer. Migrate only when your KMS supports the exact workflow and protection level. Google Cloud’s quantum-safe import Preview can protect imported key material with ML-KEM or X-Wing, but currently targets software-backed keys rather than Cloud HSM.

Our SDK is open source. How do we handle PQC there?

Update your SDK’s default TLS configuration to prefer hybrid key exchange groups. For most languages, this means bumping the TLS library dependency and ensuring the configuration does not pin classical-only cipher suites. Release the updated SDK with migration documentation and a deprecation notice for older versions.

How does this interact with certificate rotation?

PQC key exchange is independent of your TLS certificate algorithm. You can use hybrid key exchange with your existing RSA or ECDSA certificates. Certificate algorithm migration (to ML-DSA or composite certificates) is a separate, later concern that depends on CA/Browser Forum standardization for public-facing certificates.

Sources

Related articles

Hybrid Cryptography Explained

Why hybrid mode combines classical and post-quantum algorithms, how long it lasts, the key RFCs and IETF drafts, and when organizations can drop classical.

Cloudflare Post-Quantum Setup

Cloudflare enables PQ key exchange by default for client-to-edge traffic. But origin connections need manual configuration. Here is the full picture.

Crypto Agility Explained

Crypto agility is the ability to swap cryptographic algorithms without rewriting applications. What it means practically and why PQC makes it urgent.

How to Test Your Post-Quantum Cryptography Implementation

Practical guide to testing PQC deployments: interop tools, OQS test server, browser dev tools, and TLS handshake capture.