Post-Quantum Cryptography in 2026: Where Browsers, CAs, and Enterprises Actually Stand

The Hype vs. The Reality

Post-quantum cryptography has been "coming soon" for years. In 2026, it's finally arriving — but unevenly. Some corners of the internet are well ahead. Others haven't started. Understanding where things actually stand is essential for planning your organization's PQC transition.

The Headlines vs. The Ground Truth

What the headlines say: "PQC is here! Browsers support it! Adopt now!"

What the data shows:

• ~40% of top websites support hybrid PQC key exchange
• Only ~8.6% of the top 1 million websites have PQC support
• Major browsers ship PQC by default, but server adoption lags
• No publicly trusted PQC certificates exist yet — only hybrid key exchange
• First PQC certificates expected in late 2026, broadly trusted in 2027+

The gap between "browsers support PQC" and "PQC is deployed everywhere" is enormous.

What's Actually Deployed Today

Browser Support: Strong

All major browsers now support hybrid post-quantum key exchange by default:

Hybrid key exchange means the connection uses both a classical algorithm (X25519) and a post-quantum algorithm (ML-KEM/Kyber768). If either is broken, the connection remains secure.

Server Support: Lagging

While browsers negotiate PQC key exchange automatically, servers must be configured to support it:

Top 100 websites:     ~40% support hybrid PQC
Top 1,000 websites:   ~25% support hybrid PQC
Top 1M websites:      ~8.6% support hybrid PQC
Enterprise internal:  < 2% (estimated)

The adoption curve heavily favors large tech companies (Google, Cloudflare, Meta, Amazon) who control significant portions of internet traffic. Smaller organizations and enterprise internal services are far behind.

Certificate Authority Support: Emerging

No publicly trusted CA currently issues post-quantum certificates. The timeline:

• Late 2026: First PQC certificates in testing/pilot programs
• 2027: Initial publicly trusted PQC certificates from major CAs
• 2028-2030: Broader PQC certificate availability

What's available today is hybrid key exchange, not hybrid certificates. The certificate itself (authentication) still uses classical algorithms (RSA or ECDSA). Only the key exchange (confidentiality) uses PQC.

The NIST Standards Landscape

Finalized Standards

NIST finalized three post-quantum cryptographic standards:

What Each Means for PKI

ML-KEM (FIPS 203): This is what browsers use today for hybrid key exchange. It protects the confidentiality of TLS connections against quantum attacks. Already deployed at scale.

ML-DSA (FIPS 204): This is what PKI certificates will use for post-quantum signatures. It protects the authentication of TLS connections. Not yet deployed in publicly trusted certificates.

SLH-DSA (FIPS 205): A conservative, hash-based signature alternative. Larger signatures but based on well-understood security assumptions. May be preferred for high-security applications.

The "Harvest Now, Decrypt Later" Threat

Why This Matters Today

The most immediate quantum threat isn't a quantum computer breaking your current certificates. It's adversaries recording encrypted traffic today to decrypt it once quantum computers become capable.

This is known as the "harvest now, decrypt later" (HNDL) attack:

2026: Adversary records encrypted TLS traffic
2030+: Quantum computer capable of breaking classical key exchange
2030+: Adversary decrypts all stored traffic

This is why hybrid PQC key exchange matters now, even though quantum computers can't break current encryption yet. Data encrypted with classical-only key exchange today could be vulnerable in the future.

Who Should Worry Most

Organizations handling data with long-term confidentiality requirements:

• Government and defense: Classified information with decades-long sensitivity
• Healthcare: Patient records protected by HIPAA for extended periods
• Financial services: Transaction data, trade secrets, customer information
• Legal: Attorney-client privileged communications
• Intellectual property: Trade secrets and R&D data

CNSA 2.0: The Government Mandate

NSA's Commercial National Security Algorithm Suite 2.0

The NSA's CNSA 2.0 establishes post-quantum cryptography requirements for National Security Systems (NSS):

While CNSA 2.0 formally applies to NSS, it sets the direction for the broader federal government and will influence private sector compliance requirements.

The Compliance Cascade

Government mandates create a compliance cascade:

1. NSS systems must adopt PQC per CNSA 2.0 timelines
2. Federal contractors will face PQC requirements through CMMC and FedRAMP
3. Regulated industries (finance, healthcare) will follow government lead
4. General enterprise will adopt as CAs and vendors enable PQC by default

What PKI Teams Should Do Now

Immediate Actions (2026)

1. Enable Hybrid PQC Key Exchange on Servers

If your web servers support it, enable PQC key exchange now. For NGINX:

# Enable PQC hybrid key exchange (OpenSSL 3.2+)
ssl_ecdh_curve X25519Kyber768:X25519:P-256;

For Apache with OpenSSL 3.2+:

SSLOpenSSLConfCmd Curves X25519Kyber768:X25519:P-256

2. Inventory Cryptographic Dependencies

Document where your organization uses cryptography:

• TLS certificates (RSA vs. ECDSA, key sizes)
• Code signing certificates
• VPN and IPsec configurations
• SSH keys and certificates
• API authentication (JWT signing algorithms)
• Data-at-rest encryption

3. Test PQC Compatibility

Verify your infrastructure handles PQC key exchange without issues:

• Some legacy middleboxes (firewalls, proxies) break on larger PQC handshakes
• Some application-layer TLS implementations may not support ML-KEM
• Load balancers may need firmware updates for PQC support

Near-Term Actions (2026-2027)

4. Plan Certificate Algorithm Migration

When PQC certificates become available:

• Identify which certificates to migrate first (public-facing, high-sensitivity)
• Test PQC certificate issuance in staging environments
• Validate certificate chain handling with PQC root and intermediate CAs
• Ensure CLM platform supports PQC certificate types

5. Engage Your Certificate Authorities

Ask your CAs:

• What is your PQC certificate issuance timeline?
• Will you support hybrid certificates (dual classical + PQC signatures)?
• How will PQC certificates affect pricing and automation?
• What ACME extensions will you support for PQC?

Medium-Term Actions (2027-2030)

6. Migrate to PQC Certificates

As CAs begin issuing publicly trusted PQC certificates:

• Start with hybrid certificates (classical + PQC) for maximum compatibility
• Monitor for PQC-related issues (certificate size, handshake performance)
• Plan full PQC migration for when hybrid is no longer necessary

The Short-Lived Certificate Advantage

Here's where the 47-day certificate timeline and PQC converge beautifully. Short-lived certificates make PQC migration dramatically easier:

• 47-day rotation means every certificate naturally gets replaced within 7 weeks
• Algorithm changes propagate automatically through renewal cycles
• Rollback is straightforward — just issue the next certificate with a different algorithm
• No need for massive, coordinated certificate replacement campaigns

Organizations that are automated for 47-day certificates will find PQC migration almost frictionless. Those still on manual annual renewals will face a painful dual transition.

How TigerTrust Prepares You for PQC

TigerTrust is built to support the PQC transition:

• Cryptographic inventory that identifies all certificate algorithms in use
• PQC readiness assessment that scores your infrastructure's quantum preparedness
• Automated migration that can rotate certificates to PQC algorithms through normal renewal cycles
• Multi-CA ACME support that works with PQC-capable certificate authorities as they come online
• Algorithm policy enforcement that ensures new certificates meet your cryptographic requirements

The quantum clock is ticking. Start your PQC readiness assessment today.