The 2030 Deadline Is Not About Quantum Computers Existing in 2030
Cryptography ran quietly underneath most enterprise security conversations for years. RSA and ECDSA lived on pages most executives would never read; the TLS handshake was a technical detail that was forgotten the moment a connection was up. That changed in 2024. NIST finalized the first post-quantum cryptography (PQC) standards, and the clock for enterprise infrastructure to complete the transition by 2030 started running.
The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) sets 2030 as the target year for U.S. national security systems to move to post-quantum cryptography. That timeline is being treated as a practical industry deadline. Vendors supplying national-security customers must comply. Enterprise customers follow the same standards because their auditors, regulators, and large counterparties follow them.
But there is a common misreading here: the 2030 deadline does not mean "the year quantum computers arrive."
Expert estimates of when a cryptographically relevant quantum computer might exist range from the late 2030s to "never," depending on the analyst. The 2030 deadline is about preparation time. Migrating the global PKI, every TLS endpoint, every certificate authority, every embedded device shipped with RSA hard-coded — that takes more than a decade. The work must begin long before the threat is operational; otherwise the migration will be incomplete when it is actually needed.
Add to that the "harvest now, decrypt later" (HNDL) threat. An adversary that records your encrypted traffic in 2026 can decrypt the recording years later, once they have quantum capability. If data must remain secret beyond 2030 — trade secrets, M&A communications, sealed legal documents, customer PII with long retention windows — post-quantum protection is needed now. The deadline applies to data secrecy lifetime, not to the quantum-computer arrival date.
PQC Migration in Numbers
What NIST Finalized in 2024
After a multi-year selection process that began in 2016, NIST finalized the first post-quantum cryptography standards in August 2024. Three algorithms emerged; each addresses a distinct cryptographic primitive that classical public-key algorithms provide. All three are lattice-based or hash-based — the families NIST selected after eliminating other candidates.
ML-KEM (FIPS 203)
Module-Lattice-Based Key Encapsulation Mechanism, formerly Kyber. The standard for key exchange — the step in TLS where a shared secret is established over a public channel. Replaces the RSA-based key exchange and ECDH that have been in use since the 1990s. ML-KEM-768 produces approximately 1.1KB of handshake data versus around 100 bytes for X25519. CPU cost is competitive with RSA-2048.
ML-DSA (FIPS 204)
Module-Lattice-Based Digital Signature Algorithm, formerly Dilithium. The standard for digital signatures; used in certificates, code signing, authentication, and any context where the recipient must verify the sender's identity. Replaces RSA and ECDSA. ML-DSA-65 signatures are about 3.3KB versus around 70 bytes for ECDSA. Signing performance is comparable to ECDSA.
ML-SLH (FIPS 205)
Stateless Hash-Based Signature Algorithm, formerly SPHINCS+. An alternative signature scheme with different trade-offs. Produces slower and larger signatures than ML-DSA; but is hash-based — its security rests on assumptions that are easier to defend than the lattice problems underneath ML-DSA. Most deployments will use ML-DSA for performance; ML-SLH is reserved for long-lived archive signing where conservative assumptions matter more.
Capabilities Enterprise ADCs Need to Carry
Enterprise application delivery controllers — load balancers, WAFs, SSL terminators, GTM systems — sit at the TLS termination boundary. That position makes PQC support a gating factor for the broader transition: if the ADC cannot speak PQC, nothing behind it can either.
ML-KEM in TLS 1.3 Key Exchange
The ADC must accept and negotiate ML-KEM as a key-exchange algorithm in the TLS 1.3 handshake. Most deployments will choose hybrid mode — ML-KEM combined with X25519 or P-256 — so hybrid group support is also required.
ML-DSA for Certificate Signatures
The certificates the ADC presents to clients and the ones it validates from upstream services both call for ML-DSA support. Certificate-chain validation, OCSP stapling, and SCT verification all must be ML-DSA-aware.
Larger Handshake Payload Capacity
ML-KEM-768 adds about 1.1 KB to the handshake; ML-DSA-65 signatures are about 3.3 KB. The ADC must process larger handshake packets; this directly affects MTU configuration, connection-rate budgeting, and DDoS mitigation tuning.
Certificate Lifecycle Tooling
Existing certificate management tools assume classical key and signature sizes. PQC certificates are larger; ACME workflows, certificate stores, and HSM integrations need updates that handle the new size profile.
Hybrid Mode by Default
Pure-PQC deployments are still early; the algorithms are newer and have limited cryptanalysis history. Hybrid mode (classical and PQC in the same handshake) is the conservative path: if one of the two components is secure, the connection is secure. Hybrid should be the default at least through 2028.
Performance Margin
ML-KEM's CPU cost can rival RSA-2048; ML-DSA signing is comparable to ECDSA. The practical performance impact is small but not zero. Capacity planning must allow for slightly higher TLS-handshake CPU cost during the hybrid transition.
Pure-PQC deployments rely on a single new algorithm family for confidentiality. If a future cryptanalysis result weakens ML-KEM, every connection that used only ML-KEM becomes retroactively vulnerable. Hybrid mode — combining ML-KEM with X25519 or P-256 — derives the session secret from both; the connection stays secure as long as one of the algorithms holds. The cost is the size of the hybrid handshake (the larger of the two contributions). The benefit is defense-in-depth against future unknown weaknesses in either family. Major browsers (Chrome, Firefox) and TLS libraries rolled out hybrid mode through 2024-2026; the IETF standardized hybrid group identifiers. For enterprise deployments, hybrid should be the default at least through 2028.
Operational Timeline for Enterprise Migration
Now (2026): Inventory Cryptographic Surfaces
List every TLS endpoint, certificate authority relationship, code-signing workflow, and long-lived confidentiality data flow. Migration scope cannot be planned without inventory. Most organizations discover surfaces they had forgotten — internal services, legacy clients, embedded devices, B2B integrations.
Now (2026): Enable PQC on Public-Facing TLS
For ADCs that support it, enable ML-KEM hybrid mode on public-facing TLS endpoints. The change is conservative: hybrid mode falls back to classical security if PQC is later weakened. Real production traffic gets the benefit immediately.
2026-2027: Pilot ML-DSA Certificates
Start issuing ML-DSA-signed certificates for non-critical workloads to validate certificate management tooling, monitoring, and operational procedures. Certificate-chain validation code paths get exercised before they carry load for critical services.
2027-2028: Extend to Internal Services
Expand hybrid TLS and ML-DSA certificates to internal east-west traffic. Internal services tolerate compatibility issues better during the pilot; long-tail compatibility problems surface before going public-facing.
2028-2029: Long-Tail Cleanup
Address embedded devices, legacy integrations, and partner-facing APIs that lack PQC support. Some vendors require pressure; some legacy systems require replacement. The long tail is where the migration time budget is actually consumed.
2030: Operational PQC
All new TLS connections use hybrid or pure PQC. Classical-only connections require an explicit exception and a documented end-of-life timeline. The migration is no longer a project but an operation — continuous cryptographic agility is the new normal.
What This Means for ADC Product Choices in 2026
Enterprise infrastructure decisions made in 2026 will live through the PQC migration window. An ADC selected today that lacks PQC support is a forced replacement before 2030 — a cost the buyer did not plan for. Vendor evaluation breaks down into three practical headings.
First, PQC support should be checked as a baseline capability, not as a roadmap item. "We will support ML-KEM in our 2027 release" and "ML-KEM is in the version we ship today" are not the same thing. Hybrid migration requires real production validation; that means the feature must exist now.
Second, the FIPS 140-3 validation status of PQC implementations matters for regulated sectors — government, defense, banking. Validation lags adoption, so it should be included in procurement timelines.
Third, the operational story may matter more than the cryptographic one: how the ADC handles certificate management workflows under PQC sizes, how it tunes for the larger handshake budget, how it reports PQC vs classical session splits. The mathematics is settled; operations are still being worked out across the industry.
TR7's modern technology positioning includes ML-KEM and ML-DSA support in current releases, not as a future feature gate. The architectural choice that enables this is the same one that enables HTTP/3 and zero-downtime upgrades: TR7 was built from a clean slate; it was not retro-patched onto an architecture predating these requirements. For organizations measuring PQC readiness as part of 2026 vendor evaluations, that ground-up posture is an input that makes the decision easier.
References & Sources
August 2024 release of FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (ML-SLH) following a multi-year selection process. https://csrc.nist.gov/projects/post-quantum-cryptography
Commercial National Security Algorithm Suite 2.0 sets 2030 as the migration target for U.S. national-security systems to post-quantum cryptography. https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3148990/
Full specification of ML-KEM (Kyber) including parameter sets, ciphertext sizes, and security properties. https://csrc.nist.gov/pubs/fips/203/final
Full specification of ML-DSA (Dilithium) including signature sizes, verification, and security analysis. https://csrc.nist.gov/pubs/fips/204/final
Internet draft defining hybrid post-quantum key exchange group identifiers for TLS 1.3. https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
Built for What's Next, Including 2030
TR7's enterprise ADC supports ML-KEM and ML-DSA in current releases — including hybrid TLS modes that combine classical and post-quantum algorithms. HTTP/3, QUIC, zero-downtime upgrades, and post-quantum cryptography are part of the same architectural commitment: building for what's next rather than patching what came before.
Explore TR7 Modern Technology