Introduction

Azure Front Door provides a global edge for modern applications, combining content delivery, HTTP load balancing, TLS termination, acceleration, web application firewall capabilities, Azure DDoS protection, and access to Microsoft’s global network. Because many applications already terminate public TLS at the Front Door edge, it is a high-leverage point for post-quantum cryptography. You can learn more here.

The Azure Front Door team has enabled hybrid post-quantum key establishment for inbound TLS 1.3. Front Door can now negotiate TLS groups that combine classical elliptic-curve exchange with NIST-standardized ML-KEM.

When a client supports hybrid post-quantum TLS, the session uses quantum-resilient key establishment; otherwise, configurable classical fallback preserves compatibility if needed.

The immediate risk is harvest now, decrypt later (HNDL): adversaries can retain traffic captured today until a cryptographically relevant quantum computer can break its key establishment. Moving edge ingress to hybrid TLS 1.3 reduces this long-term confidentiality risk without requiring every Azure hosted application and Azure services behind AFD to change at once.

What the AFD team built

Azure Front Door terminates client-facing TLS at the edge and uses a separate connection to Azure services. PQC currently protects the client-to-Front Door TLS 1.3 segment; extending it to Azure service connections is the next engineering phase.

For the client-facing segment shown in red below, Front Door supports Post Quantum groups such as SecP256r1MLKEM768 and X25519MLKEM768 while retaining classical ECDHE groups for compatibility.

The default order prefers a mutually supported hybrid group, then falls back to approved classical groups.

How Azure Front Door works in this model

Clients connect to a nearby Azure Front Door point of presence, where Front Door terminates TLS, applies routing and WAF policy, accelerates and caches eligible content, and routes traffic across Microsoft’s network to Azure services.

This managed edge capability lets customers begin PQC migration without immediately updating every backend.

Over time, Azure Front Door will extend hybrid PQC TLS 1.3 From Azure Front Door Edge locations to Azure services/client applications connections as they roll out their support.

Cryptographic design

TLS 1.3 hybrid key establishment combines classical elliptic-curve exchange with ML-KEM. The session remains protected if either component remains secure, enabling migration without prematurely abandoning classical cryptography.

Managed Standard and Enhanced policies balance NIST-aligned elliptic curves (P-256 and P-384), internet compatibility, and customer control. A Custom policy permits explicit TLS group choices when needed.

Validation and performance

Validation used three gates: compatibility testing, synthetic load testing, and matched production A/B testing. Together they confirmed safe fallback, measured processor and handshake impact, and isolated the incremental ML-KEM cost.

Synthetic tests showed low CPU overhead (less than 1%) for the primary ML-KEM-768 groups, while matched production testing found no measurable CPU regression for X25519MLKEM768 against an X25519 control.

Customer configuration and rollout

TLS 1.3 hybrid PQC is enabled by default; no customer action is required. Customers can additionally configure AFD TLS policies - including protocol versions, groups, and cipher suites - to balance security and compatibility.

User Interface

Below is an example of the new UI in the Azure Portal, notice how you can select a custom policy so you can choose to support only PQC groups, only classic, or PQC and classic, depending on your security versus compatibility requirements.

 

Podcast Episode

In Azure Security Podcast episode 134, Michael interviews Vlad and Kunal from the AFD team about the PQC TLS 1.3 update. The episode is available in all the usual podcast sources, or you can go here: https://azuresecuritypodcast.azurewebsites.net/episodes/Episode0134.html 

Summary

Azure Front Door now supports. by default, TLS 1.3 hybrid ML-KEM key establishment, with classical fallback, managed customer policies, and staged compatibility and performance validation.

This mitigates the most critical harvest now, decrypt later (HNDL) risk of encrypted data going over the internet between the client to the AFD front-end, protecting your back-end Azure resources.

Thanks

Big thanks to all the people how reviewed this post and provided corrections, clarifications and input.

• Vlad Polyakov – Azure Front Door
• Jessie Jia – Azure Front Door
• Kunal Samant – Azure Front Door
• Varun Chawla – Azure Front Door
• Amit Srivastava – Azure Front Door
• Maks Gotkowicz – Cloud Solution Architect