Post-quantum cryptography support on Azion Platform
Azion Platform provides native support for post-quantum cryptography through TLS 1.3 with ML-KEM hybrid key exchange, protecting against future quantum computing threats.
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:
Output example:
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:
| Layer | Algorithm | Purpose |
|---|---|---|
| Classical | X25519 | Elliptic curve cryptography, extensively tested and secure against conventional adversaries |
| Post-quantum | ML-KEM-768 | NIST-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:
| Priority | Algorithm | Type |
|---|---|---|
| 1 | X25519MLKEM768 | Post-quantum hybrid |
| 2 | X25519 | Classical (elliptic curve) |
| 3 | P-256 (secp256r1) | Classical (NIST curve) |
| 4 | X448 | Classical (elliptic curve) |
| 5 | P-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
- Access any domain served through Azion
- Open Developer Tools (F12)
- Navigate to the Security tab
- Verify X25519MLKEM768 appears as the Key Exchange
Command-line verification
Test PQC negotiation:
Expected output:
Fallback testing
Verify classical fallback works correctly:
Expected output:
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.