Azion Platform delivers production-ready post-quantum cryptography (PQC) across all TLS 1.3 connections. The platform operates with TLS libraries updated to support NIST-standardized algorithms (FIPS 203 — ML-KEM), ensuring your applications remain secure against both current and emerging quantum computing threats.


How post-quantum cryptography works on Azion

Post-quantum key exchange negotiation is active for all TLS 1.3 connections on the Client → Azion path. Modern browsers supporting ML-KEM (Chrome 131+, Edge 131+, Firefox 135+, and recent Safari versions) automatically negotiate the hybrid algorithm when connecting to domains served through Azion.

You can verify PQC activation using OpenSSL:

Terminal window
echo "Q" | openssl s_client -connect www.azion.com:443 -tls1_3 2>&1 | grep "group"

Output example:

Negotiated TLS1.3 group: X25519MLKEM768

Hybrid key exchange model

Azion implements the X25519MLKEM768 hybrid model, the industry-standard approach adopted by major technology providers. This model combines two cryptographic layers:

LayerAlgorithmPurpose
ClassicalX25519Elliptic curve cryptography, extensively tested and secure against conventional adversaries
Post-quantumML-KEM-768NIST-standardized algorithm (FIPS 203), resistant to quantum computer attacks

If either layer becomes compromised in the future, the other continues protecting the session. The connection remains as secure as the strongest of the two layers.

Certificate considerations

TLS certificates (RSA or ECDSA) remain unchanged—public certificate authorities don’t yet issue post-quantum certificates. This is expected to change around 2027+. Certificate security is less urgent than key exchange because certificates protect against active adversaries with quantum computers (which don’t exist today). Key exchange prioritization mitigates the “harvest now, decrypt later” risk.


Algorithm priority order

Azion negotiates key exchange algorithms in the following priority order:

PriorityAlgorithmType
1X25519MLKEM768Post-quantum hybrid
2X25519Classical (elliptic curve)
3P-256 (secp256r1)Classical (NIST curve)
4X448Classical (elliptic curve)
5P-384 (secp384r1)Classical (NIST curve)

X25519MLKEM768 receives priority because mainstream browsers send key shares for this group by default in their ClientHello messages. If a different group received priority (such as SecP256r1MLKEM768), the server would need to issue a HelloRetryRequest, adding a complete round-trip and increasing latency for each new connection.


Backward compatibility

Post-quantum cryptography support is fully backward compatible:

  • PQC-capable clients (modern browsers) automatically negotiate X25519MLKEM768
  • Non-PQC clients transparently fall back to X25519 or P-256
  • No connections are refused—the server accepts the best algorithm both parties support

Minimum TLS version

You can configure TLS 1.2 as the minimum accepted version while still accepting TLS 1.3. Post-quantum cryptography operates exclusively within TLS 1.3—there’s no ML-KEM key exchange mechanism in TLS 1.2 or earlier versions.

Ensure to inform that, when selecting TLS1.2 as minimum, only TLS1.3 connections will be protected with PQC once it relies on 1.3 version. TLS1.2 will falback normally to a respective cipher set configured for the workload.


Edge to Origin support

Azion supports PQC negotiation on the Application → Origin path, provided your origin server accepts TLS 1.3 with X25519MLKEM768. If the origin doesn’t support PQC, automatic fallback to classical key exchange occurs.


Testing and verification

You can validate post-quantum cryptography activation through multiple methods:

Browser verification

  1. Access any domain served through Azion
  2. Open Developer Tools (F12)
  3. Navigate to the Security tab
  4. Verify X25519MLKEM768 appears as the Key Exchange

Command-line verification

Test PQC negotiation:

Terminal window
echo "Q" | openssl s_client -connect your-domain.com:443 -tls1_3 2>&1 | grep "group"

Expected output:

Negotiated TLS1.3 group: X25519MLKEM768

Fallback testing

Verify classical fallback works correctly:

Terminal window
echo "Q" | openssl s_client -connect your-domain.com:443 -tls1_3 -groups X25519 2>&1 | grep "group"

Expected output:

Negotiated TLS1.3 group: X25519

This confirms that classical fallback functions properly for clients without PQC support.


Security implications

Harvest now, decrypt later

Post-quantum key exchange addresses the “harvest now, decrypt later” threat model. Adversaries can currently record encrypted traffic and store it for future decryption when quantum computers become available. By implementing PQC today, you protect current communications against future quantum attacks.

Defense in depth

The hybrid model provides defense in depth. Even if quantum computers unexpectedly advance faster than predicted, or if classical cryptography faces new vulnerabilities, the dual-layer approach ensures continued protection.

No configuration required

PQC activates automatically for all TLS 1.3 connections. No manual configuration, certificate changes, or application modifications are necessary. Azion’s global network handles algorithm negotiation transparently.