In this blog post Azure Application Gateway Keyless TLS Without Slowing Delivery we will explain how organisations can strengthen certificate security without pushing encryption work back onto application servers or creating a bottleneck for delivery teams.
The problem is easy to miss. Your customer portal may use HTTPS, your certificates may be centrally managed and Azure Application Gateway may protect incoming traffic. Yet the private key behind that certificate can still become a high-value target if it is copied, exported or exposed through a poorly controlled deployment process.
Keyless TLS changes where that risk sits. TLS, the technology that creates an encrypted HTTPS connection, still terminates at Azure Application Gateway. However, the certificate’s private key remains inside Azure Key Vault Managed HSM, a dedicated hardware-backed service designed to protect important encryption keys.
What Application Gateway keyless TLS actually does
Azure Application Gateway distributes web traffic, applies routing rules and can run a web application firewall, or WAF, which checks requests for common attacks. Traditionally, the gateway needs access to a certificate containing both its public information and its private key.
With the established Azure Key Vault certificate model, Application Gateway retrieves the certificate and installs it locally for TLS termination. Keyless TLS uses a different model. The gateway receives the public certificate, but the private key is never exported from Managed HSM.
When a browser or system connects, Application Gateway asks Managed HSM to perform the required digital signing operation. Managed HSM returns the result, the encrypted connection is established and the private key stays inside the protected hardware boundary.
Customer or partner
|
| HTTPS connection
v
Azure Application Gateway and WAF
|
| Request to sign the TLS handshake
v
Azure Key Vault Managed HSM
|
| Signature returned, private key never exported
v
Application Gateway routes the request to the applicationThis is not the same as moving all traffic processing into the HSM. Only the sensitive private-key operation is sent there. Application Gateway continues handling traffic inspection, routing and delivery.
Why private key custody matters
If someone obtains a certificate’s private key, they may be able to impersonate a service, support convincing phishing infrastructure or decrypt traffic in certain circumstances. Certificate expiry is visible and usually monitored. Private-key exposure can be much harder to detect.
Keyless TLS reduces the number of places where the private key can exist. It does not need to sit in a deployment package, certificate file, automation script or local gateway certificate container.
The business outcome is a smaller security blast radius. A compromised administrator account, deployment server or exported backup does not automatically provide access to the private key.
This distinction is especially important for customer portals, payment applications, healthcare platforms, government-facing services and business-to-business APIs where certificate misuse could create contractual, regulatory and reputational consequences.
Security without giving up Application Gateway benefits
A common security proposal is to keep the private key on the application server. That may protect it from the gateway, but it can also spread certificate management across multiple servers and return encryption work to the application environment.
Application Gateway centralises the initial TLS connection. This lets it reuse secure sessions, inspect requests and remove much of the encryption processing from backend servers, allowing those servers to concentrate on running the application.
Keyless TLS preserves that delivery model. The gateway can still apply WAF protections, route requests based on the web address and forward traffic to different backend services. Organisations can also re-encrypt traffic between the gateway and backend when end-to-end encryption is required.
For technology leaders, this means stronger key protection does not require redesigning the application or changing how customers reach it.
Will the HSM slow down customer traffic
There is no honest security answer that says performance no longer needs testing. Keyless TLS adds a dependency during the initial connection because Application Gateway must reach Managed HSM for a signing operation.
That does not mean every page, API request or file download waits for a new signing operation. Secure connections can be reused, reducing the number of complete TLS handshakes required. Application Gateway also continues to offload encryption processing from backend servers.
The right question is not whether keyless TLS adds any work. It is whether the complete design meets the response-time, capacity and availability requirements of the service.
A controlled pilot should measure:
- New connection and TLS handshake times under realistic load.
- Customer response times before and after the change.
- Failed signing operations and denied HSM requests.
- Application Gateway capacity during traffic spikes.
- The effect of certificate renewal and configuration changes.
- What happens when the gateway cannot access Managed HSM.
Because new connections depend on the HSM signing operation, loss of identity permissions, network access or HSM availability can become a service outage. Stronger key custody therefore needs monitoring, tested recovery procedures and clear ownership.
A practical 200-person business scenario
Consider a 200-person financial services company with an Azure-hosted customer portal. Its security team wants hardware-protected certificate keys, but the application team releases updates several times a week and does not want certificate handling added to every deployment.
The company pilots keyless TLS on one non-production listener. Application Gateway receives a user-assigned managed identity, which is a passwordless Azure identity for the gateway itself. Role-based access control then permits that identity to use one specific HSM key rather than giving it broad access.
Load testing confirms that the portal remains within its performance target. Diagnostic logging records signing activity, while alerts identify denied or failed operations. The application code and release pipeline do not need to store the private key.
The result is not simply “better encryption”. The private key is removed from the delivery pipeline, security and application teams have clearer responsibilities, and releases can continue without engineers manually moving certificate files.
What your technical team needs to prepare
Microsoft’s current implementation requires Application Gateway v2, Azure Key Vault Managed HSM, a user-assigned managed identity and carefully scoped permissions. Certificate generation also uses a supported Linux environment, OpenSSL and Microsoft’s Managed HSM TLS offload library.
That makes this an architecture change rather than a portal checkbox. A practical implementation plan should include the following steps.
- Choose the right applications. Start with systems where private-key exposure would create serious commercial, privacy or compliance consequences.
- Map the current certificate process. Identify who purchases, generates, exports, renews and deploys certificates today.
- Separate responsibilities. The team operating Application Gateway should not automatically have unrestricted control of the HSM.
- Apply minimum permissions. Give the gateway access only to the key operations and specific keys it needs.
- Test failure scenarios. Remove access temporarily in a controlled environment and confirm that alerts and recovery procedures work.
- Document renewal and rollback. Certificate expiry, key rotation and emergency replacement must not rely on one person remembering a manual process.
How it fits Australian compliance requirements
Keyless TLS does not make an organisation Essential Eight compliant by itself. The Essential Eight is the Australian government’s set of eight priority cyber risk-reduction strategies, and certificate key custody is not a separate Essential Eight control.
It can, however, support broader security governance and Australian Information Security Manual expectations for managing cryptographic keys throughout their generation, storage, use, access, recovery and destruction.
The audit trail can also help answer questions that often arise during customer assurance reviews: Where does the private key live? Can it be exported? Which system can use it? Who can change those permissions? Are failed operations monitored?
If your concern extends beyond keeping a key inside Azure, our article on external key management in Azure explains the additional sovereignty, cost and availability questions involved when key control moves outside Microsoft’s infrastructure.
Keyless TLS should also not be confused with mutual TLS, which verifies the connecting client as well as the server. For partner-facing services, our Azure Front Door mutual TLS playbook covers that separate authentication problem.
Start with risk, not the feature
Not every website needs keyless TLS. Managed HSM introduces cost, operational responsibility and another critical dependency. For a low-risk internal application, the complexity may outweigh the benefit.
For high-value customer platforms and regulated workloads, the case can be much stronger. The goal is to keep the most sensitive certificate material out of deployment systems while retaining central traffic protection and reliable application delivery.
As a Microsoft Partner and Wiz Security Integrator, CloudProInc combines more than 20 years of enterprise IT experience with practical Azure, Defender and cloud security work. If you are unsure whether keyless TLS fits your risk profile, we are happy to review your current certificate and Application Gateway design with you — no strings attached.