Who: SaaS vendors, buyers (procurement/security), platform and DevOps teams. What: an updated, actionable playbook to move from pilot to production for post-quantum cryptography (PQC). When: July 2026. Where: edge TLS (CDNs, API gateways), code-signing and CI/CD artifacts, KMS/HSM key wrapping, and inter-service mTLS. Why: “harvest-now, decrypt-later” risk combines with procurement pressure and maturing hybrid tooling — delaying action costs customers and contract renewals.

Context: PQC is now transition engineering

NIST’s post-quantum cryptography program (initiated in 2016) narrowed algorithm choices in 2022 — most commonly referenced are CRYSTALS-Kyber for key establishment and CRYSTALS-Dilithium for signatures, with alternate signatures (Falcon, SPHINCS+) used in some deployments. The technical debate over “which math” is largely settled; the practical work is now integration, interoperability, and operations.

Since April 2026 we’ve seen three practical shifts relevant to SaaS teams:

  • Procurement pressure intensified: larger enterprise customers and regulated buyers now request PQC roadmaps and SLAs during renewals.
  • Toolchains have matured: open-source signing toolchains and container-signing projects published experimental PQC extensions and guidance, lowering friction for dual-signing pilots.
  • KMS/HSM vendors are publishing firmware and roadmap dates for PQC or hybrid-wrapping support; that makes practical migration planning possible rather than theoretical.

Details: where you’ll feel the change first

1) TLS and hybrid handshakes

Edge TLS is the obvious user-visible surface. The pragmatic pattern remains hybrid key exchange: perform a classical key exchange (for existing compatibility) alongside a PQC key-encapsulation mechanism so sessions remain secure if one primitive is later broken. Hybrid increases handshake payloads and CPU work; expect handshake bytes to grow by hundreds to a few thousand bytes, and signature verification to cost more CPU in some client environments.

What to do now (July 2026): inventory every TLS termination point (CDN, load balancer, ingress controller, service mesh). If your provider lacks a hybrid-TLS option, demand a dated roadmap and SLA. Run a pilot that measures handshake latency, CPU, and client error rates against representative mobile and IoT clients within 90 days.

2) Code signing and CI/CD artifacts

Signed updates, container images, and CI/CD attestations create long-lived evidence that attackers can harvest. Dual- or multi-signing (classical + PQC) is the practical interim: preserves compatibility while giving future-proof verification.

What to do now: enable dual-signing for critical releases during your pilot. If you use Sigstore, cosign, or similar tools, adopt OCI manifest extensions that preserve signature metadata and track their PQC extension roadmaps. Test verification in constrained environments (edge devices, firmware, air-gapped systems).

3) Key management, HSMs, and long-lived data

Symmetric crypto (AES-family) remains robust against known quantum attacks; the problem is wrapped symmetric keys protected today with RSA/ECC. For data retained 5+ years (healthcare records, legal archives, regulated financial records), wrapped keys are a harvest target.

What to do now: map where asymmetric wrapping is used. Ask your KMS/HSM vendor for firm firmware-roadmap dates for PQC or hybrid-wrapping support. If they can’t commit, prepare re-wrapping playbooks: automated export, re-wrap under PQC-protected keys, and rotate certificates during maintenance windows.

Impact: who must move and on what timetable

SaaS vendors

Who this is for: security leads, platform engineering, product teams shipping to regulated customers or handling long-retention data.

  • 90-day sprint: complete a cryptographic inventory listing RSA/ECC usage across TLS, signing, KMS, SDKs, and mTLS.
  • 3–6 month pilot: run hybrid-TLS and dual-signing pilots; measure latency, CPU cost, payload sizes, and client compatibility. Involve at least one representative customer in each pilot.
  • 6–24 month rollout: deploy hybrid or PQC-wrapped keys at external trust boundaries first (edge TLS, API auth, customer-managed keys). Internal mTLS and non-customer-facing systems can follow after validation.

SaaS buyers (IT, security, procurement)

Buyers should make PQC part of vendor-risk assessments and RFPs.

  • Add concrete questions to renewals: Where are RSA/ECC primitives used? Do you support hybrid PQC for TLS and signing? Provide dates and SLAs for PQC enablement.
  • Align requirements with data longevity: vendors handling data retained 5+ years need firmer commitments than SaaS products storing ephemeral session data.
  • Insist on crypto agility: require certificate rotation automation and clear algorithm negotiation strategies so migration is a configuration change, not a re-architecture.

Reactions and industry movement

Vendors and open-source projects are shifting from proof-of-concept to documented pilots and playbooks. KMS/HSM vendors are responding with firmware roadmaps; signing toolchains are offering PQC extensions; and procurement teams are starting to make PQC timelines a gating factor in renewals. In short: your vendor stack’s PQC readiness now constrains your roadmap as much as your internal priorities do.

"Treating PQC as a checkbox is no longer safe. This is program-level work: inventory, pilots, automation, and customer communication," — Alex Rivera, Technology Editor, SaaS Review Hub.

Practical checklist: July 2026 — next 90–365 days

  1. 0–90 days: complete crypto inventory; update threat model to include "harvest-now, decrypt-later"; add PQC clauses to procurement templates.
  2. 90–180 days: pick pilot scope (edge TLS + signing), select representative customers and clients, instrument metrics (handshake time, CPU, error rates), and run regression tests on constrained devices.
  3. 180–365 days: run dual-signing/dual-wrapping pilots with HSM/KMS vendors; publish a customer-facing PQC roadmap with target dates, supported algorithms, and operational boundaries.
  4. Ongoing: bake crypto agility into new designs, require vendor PQC SLAs, and prioritize long-retention workloads for earlier conversion.

What’s next to watch (rest of 2026)

  • Vendor production rollouts and SLAs for hybrid TLS and KMS integrations.
  • Public benchmarks from early adopters measuring handshake overhead and verification latency on real workloads.
  • Contractual norms: expect enterprises to require PQC roadmaps in security addenda.

FAQ

What exactly is post-quantum cryptography (PQC)?

PQC refers to public-key algorithms designed to resist attacks by scalable quantum processors. The goal is to replace or augment current public-key methods (RSA, elliptic-curve cryptography) where attackers could harvest encrypted data now and decrypt it later if quantum capabilities arrive.

Do I need to change symmetric encryption (like AES)?

Generally no. Symmetric algorithms such as AES are not broken by the same quantum attacks that threaten RSA/ECC; organizations usually focus PQC work on key exchange and signatures. That said, long-retention scenarios may justify stronger symmetric keys and stricter key-lifecycle controls.

What is a “hybrid” approach and why use it?

Hybrid crypto combines a classical primitive (e.g., ECDHE) with a PQC primitive (e.g., CRYSTALS-Kyber) so a session remains secure if either primitive holds. It’s a hedging strategy while client ecosystems and tooling mature.

Who should own PQC inside a SaaS company?

PQC is cross-functional: security/cryptography teams should lead inventory and risk modeling; platform engineering and DevOps should run pilots; legal and procurement must update contracts; product managers should communicate timelines. Treat it as a program, not a single-team project.

Alex Rivera is Technology Editor at SaaS Review Hub. He’s been dismantling and explaining complex systems since childhood; when not inventorying TLS endpoints, he argues with his smart home about firmware updates.