In this blog post Post-Quantum TLS on Azure App Service and Functions Explained we will examine why encrypted traffic that appears safe today may still create a long-term data risk, what Microsoft has changed and what CIOs should do next.
The immediate concern is not that quantum computers are breaking business encryption today. It is that an attacker could collect encrypted traffic now, retain it and try to decrypt it years later when more powerful quantum computers become available.
This matters when your applications process information that must remain confidential for a long time. Health records, legal documents, financial data, government information, intellectual property and customer identities are all potential targets.
What post-quantum TLS means in plain English
Transport Layer Security, or TLS, creates the secure connection between a device and an online application. It provides the familiar browser padlock and stops someone monitoring the network from easily reading or changing information in transit.
CPI Consulting helps organisations design, build and secure Azure AI solutions, from Azure OpenAI and Microsoft Foundry to agents, governance and production deployment.
Visit CPI ConsultingBefore information can be exchanged, the device and Azure perform a digital handshake. This handshake creates temporary secret keys that are used to encrypt the session.
Traditional handshakes rely on mathematical problems that are difficult for today’s computers. A sufficiently capable quantum computer could potentially solve some of those problems much faster.
Post-quantum TLS changes the key-establishment part of the handshake. Azure now combines a conventional method with ML-KEM, a newer method designed to resist attacks from both conventional and quantum computers.
This is known as a hybrid key exchange. It avoids abandoning proven security overnight while adding another layer intended to withstand future quantum attacks.
What Microsoft has changed
As of November 2026, Azure App Service supports hybrid post-quantum key exchange for compatible TLS 1.3 clients in the public Azure cloud. App Service is Microsoft’s managed platform for hosting websites, web applications and application programming interfaces, commonly called APIs.
Azure Functions hosted on the standard App Service infrastructure also receive this capability. Azure Functions runs small pieces of code in response to events, such as submitting a form, processing an order or receiving data from another system.
For compatible connections, Microsoft handles the new handshake at the App Service front end, which is the Azure-managed entry point receiving internet traffic before it reaches your application code.
In practical terms, most organisations do not need to rewrite their applications or purchase a special post-quantum certificate. Compatible devices can negotiate hybrid protection automatically, while incompatible devices continue using an approved conventional connection.
Custom domains are supported as well. The capability strengthens the key exchange and does not require a new type of website certificate.
Why Azure Functions needs a closer look
The phrase “Azure Functions supports post-quantum TLS” needs context. It applies when the Function App uses App Service front ends to receive an HTTPS request.
Functions running on Azure Container Apps use a different entry point and are not covered by this App Service capability. Non-HTTP functions, such as code triggered only by a queue or timer, also have a different traffic path to assess.
CIOs should therefore avoid accepting a simple “yes, Functions is protected” answer. Ask which hosting model is in use, which endpoints are publicly accessible and where TLS connections start and finish.
Post-quantum protection applies to individual connections
Many Azure applications contain several separate encrypted connections. Protecting one does not automatically protect the others.
User device -> Azure App Service front end -> Application code -> Database or external APIThe new App Service capability protects the first connection when the user’s device supports the required TLS 1.3 hybrid method. It does not automatically prove that outbound calls from the application to databases, payment platforms or other APIs use post-quantum protection.
Outbound security depends on the application runtime, operating system, software library and destination service. These dependencies need their own review.
The same principle applies when Azure Front Door sits in front of the application:
User device -> Azure Front Door -> App Service or Function AppThose arrows represent two separate TLS sessions. Our plain-English guide to post-quantum TLS on Azure Front Door explains the first connection in more detail.
The connection from Front Door to the application origin must still be reviewed separately. Teams should also prevent users from bypassing Front Door and accessing the App Service endpoint directly where the architecture requires all traffic to pass through the edge security controls.
What this capability does not solve
Post-quantum TLS is useful, but it is not complete quantum readiness.
- It does not make every client compatible. The browser, application or device must support TLS 1.3 and the compatible hybrid key exchange.
- It does not protect stored data. Database records, backups, file storage and archived documents require separate encryption and key-management planning.
- It does not make certificate signatures post-quantum. The website certificate may still use conventional digital signatures even when the session uses hybrid key exchange.
- It does not secure every internal connection. Each connection between gateways, applications, APIs and databases must be assessed.
- It does not replace normal security controls. Identity protection, patching, access restrictions, Microsoft Defender and web application firewalls remain essential.
Organisations protecting private keys separately should also understand the difference between key exchange and key storage. Our article on how keyless TLS raises the bar for Azure web application security covers that part of the security model.
Do not force TLS 1.3 without testing
Azure App Service supports TLS 1.3, while new applications generally use TLS 1.2 as their minimum accepted version. A minimum of TLS 1.2 does not prevent a modern client from negotiating TLS 1.3.
Raising the minimum to TLS 1.3 can improve consistency, but it can also disconnect older business systems, embedded devices, integration partners and legacy software. That can turn a security improvement into an operational outage.
Test client compatibility before making TLS 1.3 mandatory. Pay particular attention to mobile applications, warehouse devices, payment integrations, older Windows systems and third-party services that call your APIs.
Teams should also identify any applications that still permit TLS 1.0 or 1.1. Microsoft plans to stop accepting these older versions for inbound App Service and Function connections on 31 May 2027, so this work should already be on the retirement plan.
A practical business scenario
Consider a 200-person healthcare services company with a customer portal hosted on App Service. The portal sits behind Azure Front Door, sends documents to storage and calls an external billing platform.
Enabling hybrid protection at Front Door helps secure the customer’s connection to the edge. App Service support can strengthen compatible direct inbound connections, but it does not automatically confirm post-quantum protection between every component.
The correct response is not an expensive rebuild. It is to map the traffic paths, restrict any unnecessary public endpoints, test client compatibility and prioritise the records that must remain confidential for ten or more years.
The business outcome is a defensible transition plan without unnecessary disruption or spending.
Five questions CIOs should ask now
- Which App Services and Function Apps handle long-lived sensitive data? Start with health, financial, legal, identity and intellectual property systems.
- Are the Function Apps using App Service hosting or Azure Container Apps? The answer changes which platform entry point must be assessed.
- Which users and systems currently connect with TLS 1.3? Measure compatibility instead of assuming every modern-looking device supports the same features.
- Where does TLS terminate? Document Front Door, gateways, App Service, APIs, databases and external providers as separate connections.
- Can the team prove hybrid negotiation? Configuration screenshots alone are not enough. Use controlled testing and retain evidence for security and risk reviews.
How this fits Australian security planning
Post-quantum TLS is not a shortcut to Essential Eight compliance. The Essential Eight is the Australian Government’s set of baseline strategies for reducing common cyber risks, including patching, multi-factor authentication, application control and reliable backups.
Post-quantum planning complements those controls rather than replacing them. Australian Signals Directorate guidance encourages organisations to identify where public-key cryptography is used, assess how long protected data remains valuable and build a staged transition plan.
The sensible goal for 2026 is crypto-agility, meaning the ability to change encryption methods without rebuilding the entire business system. An accurate inventory and clear ownership are more valuable than rushing to enable every new feature.
What leaders should do next
Microsoft’s App Service and Functions update is a useful step because much of the work happens in the managed Azure platform. For compatible inbound connections, organisations can gain stronger long-term protection without rewriting application code.
The main risk is overestimating what has been achieved. Hybrid key exchange protects a specific part of a specific connection. It does not automatically cover stored data, outbound traffic, certificate signatures or every service behind the application.
CloudProInc combines more than 20 years of enterprise IT experience with hands-on work across Azure, Microsoft 365, Defender and Wiz. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations map these connections, identify meaningful gaps and plan changes without turning quantum readiness into an oversized technology project.
If you are unsure which of your Azure applications already benefit from post-quantum TLS, or where sensitive traffic remains exposed, we are happy to take a practical look with you — no strings attached.