Azure Application Gateway Keyless TLS Launches With Azure Key Vault Managed HSM

The update page itself gave us very little beyond the title and status. The mechanics below come from Microsoft Learn documentation and a GitHub tracking issue. Anything those sources don't confirm is marked as unconfirmed.

What "keyless" means here​

"Keyless TLS" does not mean TLS without keys. The private key still exists. It just isn't handed to the gateway as an exportable file.

Application Gateway's traditional Key Vault integration works differently. Gateway instances retrieve the certificate from Key Vault, install it locally for TLS termination, and poll Key Vault every four hours for renewed versions. That model has a hard limit. Application Gateway has supported software-validated certificates only, and HSM-validated certificates weren't supported. Key Vault certificates also needed an exportable private key for the gateway to use them.

The new path references a key held in Managed HSM instead. This closes a gap for teams whose policies say TLS private keys must live in a hardware boundary and never leave it.

How the configuration looks​

The Azure PowerShell reference for Add-AzApplicationGatewaySslCertificate shows the supported pattern. It adds two parameters:

• -HsmKeyId is the key identifier of a key stored in Managed HSM. This quote is not from the cmdlet page; see the paraphrase below.
• -HsmPublicCertData is the Base64-encoded public certificate data that corresponds to the key held in Managed HSM.

The documented example gets the gateway object with Get-AzApplicationGateway. It then passes a key URI to Add-AzApplicationGatewaySslCertificate. The URI has the form [url]https://myhsm.managedhsm.azure.net/keys/mykey/abc123[/url], which is the HSM host, a /keys/ path, the key name and the key version.

The older options are still in the same cmdlet. They are the PFX upload (-CertificateFile and -Password) and the Key Vault secret reference (-KeyVaultSecretId). Managed HSM is an addition, not a replacement.

A discrepancy worth knowing about​

The Learn example uses -HsmKeyId alone. A GitHub issue in the Azure CLI repository describes the underlying API change differently. It says API version 2025-07-01 introduced a new ApplicationGatewayManagedHsm model. It also asks the CLI to require --public-cert-data whenever --hsm-key-id is provided. That issue is a feature request, not official guidance. Still, if you script this, plan to supply the public certificate data. Check the current reference for your tool version.

The issue also notes that the PowerShell changes added -HsmKeyId and -HsmPublicCertData to the New, Set and Add SSL certificate cmdlets. The matching az network application-gateway ssl-cert CLI parameters were still being requested in that issue. Confirm your CLI version supports them before building automation around them.

About Managed HSM​

Microsoft describes Managed HSM as a fully managed, highly available, single-tenant service. The overview page says it uses FIPS 140-3 Level 3 validated HSMs. It also describes local RBAC that cluster administrators control, and private endpoint support for connecting from a virtual network.

This is useful background, but it does not prove that using the feature satisfies any particular compliance requirement. Your auditors decide that, not a launch banner.

What we couldn't confirm​

The sources I could reach don't cover several details that matter for a rollout:

• Supported Application Gateway SKUs. The older Key Vault integration is limited to the v2 SKU. That doesn't settle the Managed HSM path.
• Supported regions, key types and algorithms.
• The exact role assignments the gateway's identity needs on the HSM.
• Network and firewall requirements.
• Pricing and limits.
• Whether the four-hour renewal polling applies to HSM-backed keys.
• The procedure for binding the HSM-backed certificate to a listener.

The Key Vault managed-identity requirements, such as the single managed identity per gateway, are documented for the traditional model. Don't assume they carry over unchanged.

Practical advice for administrators​

1. Check your SKU. Confirm you are on a gateway SKU the new documentation lists as supported before planning a migration.
2. Plan the key and certificate pairing. Have the key in Managed HSM, the matching public certificate and the key URI ready.
3. Pilot on a non-production gateway. Test with a non-critical listener first. Rotation and renewal behavior is the part the documentation leaves least clear.
4. Define rotation ownership. The versionless-secret recommendation (automatic rotation when a newer version exists) applies to Key Vault secrets. Don't assume Managed HSM keys behave the same way.
5. Budget for it. Managed HSM is billed as a dedicated pool, and Microsoft points to the Key Vault pricing page for those rates. It is not a casual add-on for one internal site.
6. Watch the failure mode. For the traditional integration, Microsoft warns that if the gateway can't reach the vault or find the certificate, it can disable the listener. Treat HSM access as a dependency of your front door, and set up Resource Health and Advisor alerts.

Analysis​

This is a niche feature, and a welcome one. Most web workloads are fine with Key Vault certificates. Regulated sectors such as finance, government and healthcare often must show that a TLS private key never leaves hardware. Until now, Application Gateway forced those teams to terminate TLS elsewhere, for example on third-party appliances or Nginx and F5 fronts that already supported Managed HSM keyless setups. Native support lets them use a managed Azure service instead.

The trade-offs are the usual ones. You pay for a single-tenant HSM, and you add a dependency whose outage can take down HTTPS. Teams that don't have a hardware-custody mandate probably gain little. For teams that do, the missing details above are the first thing to settle with Microsoft's current deployment guide.