Azure Front Door now Supports Post-Quantum Resilient Hybrid TLS 1.3

Azure Front Door acts as a global edge solution for today’s applications, bringing together content delivery, HTTP load balancing, TLS termination, acceleration, web application firewall features, Azure DDoS protection, and easy access to Microsoft’s worldwide network. Many applications already handle public TLS at the Front Door edge, making it a strategic place for post-quantum cryptography. You can find out more about it here.

The Azure Front Door team has introduced hybrid post-quantum key establishment for inbound TLS 1.3. This innovation allows Front Door to negotiate TLS groups that blend classical elliptic-curve exchanges with the NIST-standard ML-KEM.

If a client supports hybrid post-quantum TLS, the session leverages quantum-resilient key establishment. If not, a configurable classical fallback option ensures compatibility when necessary.

A pressing concern is the “harvest now, decrypt later” (HNDL) threat: attackers can store data captured today until a powerful quantum computer becomes available to crack its key establishment. By shifting edge ingress to hybrid TLS 1.3, we lessen this long-term confidentiality risk without needing every Azure-hosted application and Azure service behind Azure Front Door to be updated simultaneously.

Azure Front Door handles the termination of client-facing TLS at the edge, employing a distinct connection to Azure services. Currently, post-quantum cryptography (PQC) secures the TLS 1.3 connection between clients and Front Door. The next engineering step is expanding this protection to Azure service connections.

For the client-facing section depicted in red below, Front Door endorses Post Quantum groups like SecP256r1MLKEM768 and X25519MLKEM768, whilst still accommodating classical ECDHE groups for compatibility.

Clients connect to a nearby Azure Front Door point of presence, where TLS is terminated. At this point, Front Door enforces routing and WAF policies, promotes content acceleration and caching, and directs traffic across Microsoft’s network to Azure services.

This managed edge functionality allows users to initiate the PQC migration without the immediate need to update all backend services.

Over time, Azure Front Door will broaden hybrid PQC TLS 1.3 support from its edge locations to connections with Azure services and client applications once they implement necessary changes.

The hybrid key establishment in TLS 1.3 blends classical elliptic-curve exchanges with ML-KEM. This duality maintains the session’s protection as long as either component stays secure, thus facilitating a smoother migration without prematurely discarding classical cryptography.

Managed Standard and Enhanced policies find a balance among NIST-compliant elliptic curves (P-256 and P-384), compatibility with the internet, and customer control. A Custom policy option allows users to define specific TLS groups when required.

We conducted validation through three steps: compatibility testing, synthetic load testing, and A/B testing in closely matched production environments. Together, these confirmed safe fallback mechanisms, measured processor impacts, and isolated the incremental costs associated with ML-KEM.

Synthetic testing demonstrated low CPU usage (under 1%) for the primary ML-KEM-768 groups. Moreover, matched production tests revealed no significant CPU regression for X25519MLKEM768 compared to the X25519 control.

Hybrid TLS 1.3 with PQC is enabled by default, requiring no action from customers. However, users can adjust Azure Front Door’s TLS policies—including protocol versions, groups, and cipher suites—to optimise for both security and compatibility as needed.

Take a look at the new UI within the Azure Portal below. Here, you can choose a custom policy that allows you to select between supporting only PQC groups, only classical options, or both, depending on your security versus compatibility needs.

In the Azure Security Podcast episode 134, Michael chats with Vlad and Kunal from the Azure Front Door team regarding the PQC TLS 1.3 update. You can catch the episode on your favourite podcast platform or follow this link: https://azuresecuritypodcast.azurewebsites.net/episodes/Episode0134.html.

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

This development effectively reduces the significant risk of HNDL (harvest now, decrypt later) concerning encrypted data transmitted over the internet between clients and the Azure Front Door frontend, thereby safeguarding your backend Azure resources.

We extend our heartfelt gratitude to contributors who reviewed this post and helped with suggestions and clarifications.

• 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