Azure App Service secure hostname

The formal announcement to removing the toggle has not been published as far as I can tell but the public documentation of https://learn.microsoft.com/en-us/azure/app-service/reference-dangling-subdomain-prevention?tabs=portal was recently updated to reflect this default portal behavior (recent https://github.com/MicrosoftDocs/azure-docs/commit/c04137f1efdc14a6b32ca2f02ba60c8e9ba1a2e8#diff-d01fbfa2b2ef70dfec7c5306b1850dab8738004f36b9cef841be8b67a1054a5bas of 2026-07-23). 

Azure portal now forces the "secure unique default hostname" for new apps. While you cannot disable it via the UI, you can still configure it via CLI/IaC at creation time. If you have automated deployments, remember to update your templates to handle this behaviour.

It has not made “secure hostname” mandatory for the default appservicename.azurewebsites.net format. The secure hostname requirement you are seeing is related to TLS/SSL certificate changes and industry compliance updates, not a removal of the standard azurewebsites.net hostname option, azurenamingconventions.com/blog/azure-app-service-function-naming

The secure unique default hostname is an App Service option designed to reduce subdomain-takeover risk. Instead of the predictable app name format, it includes a deterministic hash and region. Microsoft recommends it for new apps, while the classic hostname still exists for resources created without a domain-name scope.
The choice is made when the resource is created and cannot be enabled retroactively for an existing app. Portal behavior may therefore differ between old and new deployments. Check WEBSITE_DEFAULT_HOSTNAME or the app’s Overview page rather than assuming the classic name was also assigned.
Both default formats use Azure-managed TLS certificates, so “secure” here refers to unique ownership, not an absence of HTTPS on the classic name. For production, attach and validate a custom domain and avoid making application logic depend on either default hostname. Infrastructure code should read the deployed defaultHostName output rather than constructing a hostname from the app name.

Hi Hitarth,

I noticed the same behavior recently. From what I've seen, Microsoft appears to be moving toward Secure Hostnames by default as part of its secure-by-default initiative, so the toggle may no longer be available in newer deployments or regions.

The default *.azurewebsites.net endpoint should continue to function, but it's now provisioned with the secure hostname configuration automatically. If you're using Infrastructure as Code (Bicep, ARM, Terraform, or Azure CLI), it's also worth checking whether your deployment templates need to be updated to align with the new behavior.

I'd be interested to know whether anyone has seen an official Microsoft announcement or release note confirming this rollout, as I haven't found a definitive communication yet either.