Quantum computers could very soon undermine the public-key cryptography that secures financial transactions, health records, and other sensitive data moving over TLS today. When that happens, encrypted information protected by vulnerable cryptography could become accessible.
Encrypted traffic can be intercepted and stored today, with the expectation that it will be decrypted once a sufficiently capable quantum computer exists. This is known as “harvest now, decrypt later.” The value of the captured data lasts as long as it stays confidential.
For businesses handling financial records, health data, and other regulated information, quantum risk falls squarely inside the confidentiality window that data requires. PQC (Post-Quantum Cryptography) closes that window.
AppTrana now supports X25519MLKEM768, a hybrid post-quantum TLS key exchange that pairs the established X25519 algorithm with ML-KEM-768. The goal is to let organizations begin using quantum-resistant key exchange without requiring every client or origin they connect to be upgraded first.
X25519MLKEM768: A NIST and IETF-Standardized Approach
NIST finalized ML-KEM under FIPS 203 in 2024 as part of its post-quantum cryptography standardization effort. ML-KEM-768 is one of three parameter sets defined by that standard.
On the TLS side, X25519MLKEM768 is standardized by the IETF in RFC 10024 (2026), one of three hybrid key agreement mechanisms combining ML-KEM with ECDHE. Browsers including Chrome have already been shipping this hybrid mechanism since 2024, and major CDN and edge providers have enabled it by default. This is a mechanism the broader TLS ecosystem is actively converging on.
The reason it is a hybrid mechanism rather than a pure ML-KEM deployment is deliberate: the resulting session secret depends on both algorithms. Therefore, an attacker would need to break both algorithms to compromise the handshake. Morever, ML-KEM is the newer standard and hasn’t accumulated the same track record as X25519. Teams get post-quantum protection this way without relying solely on an algorithm that is still being battle-tested in production.
How X25519MLKEM768 TLS Negotiation Works
When a TLS-capable client connects to an application behind AppTrana, it advertises the key exchange groups it supports. If a client advertises X25519MLKEM768 and the AppTrana endpoint is configured to support it, AppTrana selects the hybrid key exchange for that session, combining X25519 and ML-KEM-768 to derive the session secret.
If a client only advertises classical key exchange groups, which is still the case for many browsers, API clients, and legacy systems, AppTrana negotiates a supported classical mechanism instead. And if hybrid negotiation is offered but doesn’t complete successfully for some reason, TLS negotiation falls back to a classical group rather than failing the connection outright. In every case, connectivity is preserved; only the strength of the key exchange changes based on what both sides support.
End-to-End PQC: Why Two TLS Connections Matter
As traffic passes through AppTrana on its way from client to origin, it crosses two separate TLS connections, both relevant to PQC coverage:
Client to AppTrana: Once enabled, this connection is hybrid-protected for any client that supports X25519MLKEM768. Clients that don’t yet support it continue using classical TLS without disruption.
AppTrana to Origin: If your origin’s TLS stack also supports X25519MLKEM768, AppTrana negotiates the hybrid key exchange on this connection too. If it doesn’t, this connection continues on classical TLS while the client-facing connection is already protected.
One point worth noting for rollout planning: the client-to-AppTrana connection gets hybrid protection once enabled, currently available on request with plans to make it the default over time and requires no changes on the origin side. Full end-to-end PQC is the next stage, extending the same hybrid negotiation to the AppTrana-to-origin connection once the origin’s TLS stack supports it.
Hybrid post-quantum protection is currently available on request. Customers who want it enabled at the AppTrana edge can reach out to support to get started
X25519MLKEM768 in Action: Real-World Use Cases
Here is how that plays out across a few common architectures and data types:
Payment and banking APIs – A payments platform behind AppTrana handles account numbers and transaction records that need to stay confidential well past the life of any single API call. As mobile apps and partner integrations pick up X25519MLKEM768 support, those sessions are automatically upgraded to hybrid key exchange at the AppTrana edge, no application code changes and coordinated release with every partner required.
Patient portals and healthcare APIs – A healthcare provider’s patient portal serves a mix of modern browsers and older devices still in clinical use. AppTrana negotiates hybrid PQC where supported and falls back to classical TLS elsewhere, so the rollout doesn’t force an IT team to standardize every device before turning anything on.
Multi-tenant SaaS platforms – B2B SaaS product with enterprise contracts specifying long-term data confidentiality can enable hybrid negotiation at the edge immediately. Origin-side readiness is tracked separately, as the infrastructure team upgrades TLS libraries on backend services at its own pace. There is no dependency on customer-side changes.
Internal APIs carrying source code or design data – A technology company moving proprietary code or research data between internal services through an AppTrana-fronted API gateway can extend hybrid PQC from the edge to the origin. This just requires confirming the origin’s TLS stack supports X25519MLKEM768. Once it does, AppTrana negotiates the hybrid key exchange automatically.
What to Check on the Origin Server
For organizations pursuing end-to-end coverage, origin readiness comes down to a few concrete questions:
- TLS version: hybrid PQC requires TLS 1.3.
- SSL/TLS library support: the origin’s TLS implementation needs to support X25519MLKEM768 specifically.
- Server configuration: the algorithm needs to be enabled and permitted in the origin’s TLS configuration.
- Network path compatibility: firewalls, load balancers, and other TLS-intermediating devices should be tested against the larger handshake size that hybrid key exchange introduces.
That is exactly why a controlled, monitored rollout makes sense.
Chrome’s rollout of hybrid post-quantum key exchange ran into this directly. ML-KEM key material is much larger than a traditional X25519 share, and some older network middleboxes couldn’t handle the bigger handshake. This is a strong case to roll out PQC in a controlled, monitored way rather than treating it as a simple configuration toggle.
Verifying the Negotiated Key Exchange
Once PQC is available for a given site, the negotiated key exchange can be confirmed directly. In Chrome, this is visible under DevTools, Security, Connection, where a successful hybrid negotiation shows X25519 + MLKEM768. Display details vary by browser, so the negotiated result should be treated as the source of truth for whether a given session used hybrid PQC.
A Staged Approach to Adoption
A practical rollout doesn’t require treating PQC as a single cutover event:
- Identify long-lifespan data – Determine which applications handle information that needs to stay confidential for years.
- Inventory TLS dependencies – Map the TLS capabilities of clients, API consumers, load balancers, proxies, origin servers, and network security devices.
- Enable hybrid negotiation at the edge – Compatible clients begin benefiting immediately; incompatible clients are unaffected.
- Assess and upgrade origin infrastructure where end-to-end coverage is required.
- Validate both connections, client-to-AppTrana and AppTrana-to-origin, rather than assuming edge support implies full coverage.
- Monitor for compatibility issues as handshake sizes increase, particularly on older network infrastructure.
Start Your Post-Quantum TLS Migration Today
Migrating cryptographic infrastructure takes time: TLS libraries need upgrading, network equipment needs testing, and clients and partners need to adopt compatible implementations at their own pace. That process needs to start well before a cryptographically relevant quantum computer becomes an operational concern.
With X25519MLKEM768 support, AppTrana lets organizations begin that transition at the application edge now. They can extend it toward origin infrastructure as that infrastructure becomes ready. Neither step requires a disruptive migration or breaks compatibility with the systems they still depend on.
Start your free trial of AppTrana today and see hybrid post-quantum TLS protection in action.