Compliance

Enforce encryption in transit across Azure services

One capability across Redis, App Service and Functions: make sure no service answers an unencrypted request, so credentials, tokens and payloads never travel as plaintext that anyone on the path can read.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-aks-https-only azure-api-app-ftps-required azure-api-app-https-only azure-api-app-latest-tls azure-apim-encrypted-protocols-only azure-app-service-https-only azure-function-app-ftps-required azure-function-app-https-only azure-function-app-latest-tls azure-redis-secure-connections azure-service-fabric-cluster-protection-level azure-sql-tls-minimum-version azure-web-app-ftps-required azure-web-app-latest-tls azure-windows-web-servers-secure-protocols

Encryption in transit: the basics

What does an Azure service that accepts a plaintext connection actually expose?

Encryption in transit means every connection to a service is wrapped in TLS, so nothing it sends or receives crosses the network as plaintext. The failure shows up in a handful of distinct shapes rather than one setting. An Azure Cache for Redis can have its non-SSL port 6379 left enabled, so a client can connect without TLS at all. A web app on App Service can accept plain HTTP instead of redirecting to HTTPS. A Function App can do the same on the endpoints that trigger it. Each is its own Defender for Cloud recommendation, but the underlying risk is identical: a service that answers an unencrypted request, and therefore exposes whatever travels over it to anyone able to observe the path.

Microsoft Defender for Cloud turns each of these into its own recommendation, all mapped to the same Microsoft Cloud Security Benchmark control, DP-3, encrypt sensitive data in transit. 'Redis Cache should allow access only via SSL', 'Web Application should only be accessible over HTTPS' and 'Function App should only be accessible over HTTPS' read as three unrelated findings on three different service types, but they are one job: make sure nothing in the estate will speak plaintext on the wire. A subscription running a cache, a couple of web apps and a few functions can fail several of these at once.

Most of this exposure is drift, not intent. A Redis cache created from a template that never set 'enableNonSslPort' to false, a web app deployed before 'HTTPS only' was switched on, a function whose host config never enforced a redirect. The work is to find every service in the estate that will accept an unencrypted connection, turn the plaintext door off, set a sane minimum TLS version so old, weak protocol versions cannot be negotiated either, and then make the safe state the only state a new resource can be created in.

In this lesson you will learn how Azure services express whether they accept an unencrypted connection, how to find every service in a subscription that still will, and how to enforce TLS everywhere without breaking the few clients that have not yet been updated. The Controls this lesson covers section lists every Defender for Cloud recommendation in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The downgrade nobody noticed

The danger with encryption in transit is rarely that an attacker breaks TLS; it is that the service quietly offered a way around it. A cache that leaves its non-SSL port open, or an app that still answers plain HTTP, gives an attacker on the path a downgrade to plaintext without breaking anything. This is why 'HTTPS only' redirects are not enough on their own: a redirect still sends the first request over HTTP, so the only fully safe posture is to refuse the unencrypted connection outright and pair it with HSTS. Azure now defaults new Redis caches to a minimum TLS of 1.2 and new web apps toward HTTPS, but every resource created before those defaults still needs to be checked and closed explicitly.

Finding plaintext-capable services across a subscription

Sam is the security lead at a scale-up preparing for its first ISO 27001 audit. Defender for Cloud shows encryption-in-transit findings spread across a Redis cache, a couple of web apps and several functions, all in a subscription that pre-dates the team's current guardrails.

Rather than work the findings one by one, Sam starts by listing which web apps still accept plain HTTP, so the genuinely live services can be separated from drift before anything changes.

Start by listing the web apps that do not have 'HTTPS only' enabled. These are the ones still answering plain HTTP.

$ az webapp list --query "[?httpsOnly==\`false\`].{name:name, rg:resourceGroup, https:httpsOnly}" -o table

Name Rg Https

---------------- --------------- -------

checkout-prod rg-payments False

marketing-site rg-web False

# checkout-prod accepts plain HTTP and handles card data. Close it first.

A web app that both answers plain HTTP and handles sensitive data is the highest-value target in this group. Fix these before the low-risk marketing sites.

How Defender for Cloud decides a service will speak plaintextdeep dive

Each recommendation resolves to one property on the resource. For Azure Cache for Redis it is 'enableNonSslPort': when it is true, the cache listens on the unencrypted port 6379 alongside the TLS port 6380, so a client can connect with no encryption at all. For a web app or a Function App it is 'httpsOnly': when it is false, the service answers plain HTTP and does not redirect to HTTPS, so the request, and anything in it, crosses the network as plaintext. A companion setting, 'minTlsVersion' on the site config and 'minimumTlsVersion' on Redis, governs how weak a TLS version the service will still negotiate, so a resource can be HTTPS only yet still accept a downgraded TLS 1.0 handshake if that floor is left low.

Defender for Cloud evaluates these against the Microsoft Cloud Security Benchmark on a periodic cycle, so a fix does not flip the recommendation to Healthy instantly. The control-plane change itself is immediate, but the posture catches up on the next assessment. This matters when you are gathering audit evidence against a deadline.

The strongest position combines the resource setting with an Azure Policy backstop. Microsoft ships built-in deny and audit policies, 'Web Application should only be accessible over HTTPS', 'Function apps should only be accessible over HTTPS' and the Redis SSL enforcement policy, all grouped under MCSB DP-3. Assigning them means no individual resource can be created in the plaintext-capable state again. Turning those policies on is the difference between checking that nothing speaks plaintext today and guaranteeing that nothing can be created to speak it tomorrow.

What is the impact of leaving plaintext connections open?

The direct impact is interception. Anything that crosses an unencrypted connection, a Redis AUTH password or a session token, a login posted over plain HTTP, an API key in a header, can be read by anyone able to observe the path: a compromised network device, a malicious Wi-Fi hotspot, a misconfigured proxy. A stolen credential is worse than a single leaked record, because it can be replayed: an attacker who reads a Redis password or a session token off the wire gains whatever access it grants until it is rotated or expires.

The second-order impact is the downgrade. A service that merely redirects HTTP to HTTPS still sends that first request in plaintext, and a service with a low minimum TLS version can be pushed onto a weak, breakable protocol version by an attacker on the path. Refusing the unencrypted connection outright, closing the non-SSL port and setting a modern TLS floor, removes the downgrade path entirely, which is why enforcement beats redirection.

On the compliance side, every modern framework, ISO 27001, SOC 2, HIPAA, PCI DSS and the UK and EU data-protection regimes, expects evidence that data in transit is encrypted. PCI DSS is explicit about it for cardholder data, and HIPAA treats transmission security as an addressable safeguard. A passing set of encryption-in-transit recommendations across every subscription is the cheapest and most defensible artefact you can hand an auditor.

How do you enforce TLS safely?

Work the capability as one loop rather than chasing individual findings. The order matters: find and update the clients that still connect over plaintext before you close the door, so you do not drop a live connection.

1. Inventory every plaintext-capable service

List the Redis caches with the non-SSL port enabled, the web apps and functions without 'HTTPS only', and any resource sitting below a TLS 1.2 floor. Treat this inventory as the source of truth, not the Defender finding count, because the same capability spans several different resource types.

2. Find the clients that still use plaintext

Before closing the non-SSL Redis port, confirm no application still connects on 6379, and update any that do to the TLS port 6380. Before raising the TLS floor, check that no old client pins TLS 1.0 or 1.1. This is the only step that can break a live service, so do it first.

3. Close the plaintext doors, highest impact first

Disable the non-SSL Redis port, set every web app and Function App to HTTPS only, and set a minimum TLS version of 1.2 across the board. Prioritise the services carrying credentials and sensitive payloads over low-risk internal ones. Each change is a single command per resource and takes effect immediately.

4. Ratchet it shut with Azure Policy

Assign the built-in deny policies so no new web app, function or cache can be created that accepts an unencrypted connection, and pair 'HTTPS only' with HSTS on the apps so browsers refuse to downgrade. Back this with audit policies for the minimum TLS version, so the safe configuration is enforced rather than merely encouraged.

# Close the highest-impact plaintext doors first: the Redis non-SSL port,
# then HTTPS-only + a modern TLS floor on every web app.

# Redis: disable the non-SSL port 6379 and require TLS 1.2 (clients use 6380).
for cache in $(az redis list --query "[?enableNonSslPort].name" -o tsv); do
  rg=$(az redis list --query "[?name=='$cache'].resourceGroup" -o tsv)
  az redis update --name "$cache" --resource-group "$rg" \
    --set enableNonSslPort=false minimumTlsVersion=1.2
  echo "$cache: non-SSL port disabled, min TLS 1.2"
done

# Web apps: enforce HTTPS only and raise the TLS floor.
for app in $(az webapp list --query "[?httpsOnly==\`false\`].name" -o tsv); do
  rg=$(az webapp list --query "[?name=='$app'].resourceGroup" -o tsv)
  az webapp update --name "$app" --resource-group "$rg" --https-only true
  az webapp config set --name "$app" --resource-group "$rg" --min-tls-version 1.2
  echo "$app: HTTPS only, min TLS 1.2"
done

# Functions follow the same pattern with az functionapp update --set httpsOnly=true.

# Ratchet it shut: assign the built-in deny policy for web apps over HTTPS only.
az policy assignment create \
  --name require-https-webapp \
  --policy a4af4a39-4135-47fb-b175-47fbdf85311d \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"

Quick quiz

Question 1 of 5

Defender for Cloud shows findings for a Redis cache, two web apps and several functions, all about encryption in transit. What is the most efficient way to think about them?

Keep learning

Go deeper on how each Azure service expresses whether it will accept an unencrypted connection, across the settings in this capability.

You can now treat encryption in transit as one capability rather than a scatter of findings across different service types: inventory every service that will accept an unencrypted connection, update any plaintext clients first, close the non-SSL ports and HTTP endpoints highest-impact first with a TLS 1.2 floor, and ratchet the estate shut with Azure Policy. The Controls this lesson covers section below links every recommendation in this group to its deep page and fix.

Back to the library

Encryption in transit: the cost and risk view

A zero-Azure-cost capability that removes a whole class of credential-theft and interception liability

Encryption in transit is one of the cheapest controls in the estate to satisfy: turning off the non-SSL Redis port, switching a web app or function to HTTPS only, and raising the minimum TLS version cost nothing in Azure spend. There is no premium tier and no per-request charge for TLS on these services. The only cost sits in the few cases where an old client still connects over plaintext or pins an outdated protocol version and has to be updated before the door is closed, which is engineering time on the client side rather than an Azure bill.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. A Redis cache holding session tokens reachable over its non-SSL port carries a far higher expected loss than a function with no sensitive payload, yet both surface as a single red finding. Map the failures to what actually flows over each connection and prioritise by what an interception would expose, not by recommendation count.

The insurance arithmetic is one-sided. The remediation is a setting change plus, in a few cases, a client update. The downside of leaving plaintext on is the documented cost of an intercepted credential or leaked payload: an attacker who reads a token or password off the wire can replay it, and the resulting incident brings the same regulatory fines, breach notification, forensics and reputational damage as any other data exposure.

This lesson is for the finance partner who sees encryption-in-transit findings on the security report and wants to know what the right response is and what it costs. It covers why these controls are essentially free to fix in Azure spend, where the only real cost sits (updating an old client), and how to turn a list of red findings into a risk-ordered remediation plan based on what each connection actually carries.

Fun fact

The downgrade nobody noticed

How a finance partner frames the encryption-in-transit decision

Sam is the finance partner supporting the platform team's ISO 27001 push. The security report lands with nine encryption-in-transit findings spread across a Redis cache, two web apps and several functions in an older subscription. The instinct is not to wave through a remediation budget; it is to ask what is actually behind each red finding. Turning off the non-SSL Redis port, switching a web app to HTTPS only and raising the minimum TLS version change nothing on the Azure bill, so the spend question is narrow: the only real cost is engineering time, and a touch more where an old client still connects over plaintext or pins an outdated TLS version and has to be updated before the door can be closed.

Sam asks the team to map each failing service to what flows over its connections. The Redis cache holds session tokens, one web app is the checkout service handling card data, and the rest are internal functions and a static marketing site. The list is reframed on the risk register: the cache and the checkout app are high expected-loss items to close today at zero Azure cost, the one legacy client still talking to Redis over the plaintext port is a small, bounded update to schedule first, and the internal functions and marketing site are low-value drift to sweep up. The finance pack reads: 'Every finding closes at no incremental Azure spend; one legacy client needs a bounded update before we shut the plaintext port; the only thing standing between us and a clean posture is engineering time, not budget.'

Why plaintext on the wire belongs on the risk register

The cost model here is asymmetric in a way that is rare for security work. Enforcing TLS costs nothing in Azure spend, and leaving a plaintext path open creates an unbounded tail risk. Each failing recommendation is a connection over which a credential or a payload could be intercepted, and while the probability per request is low, the probability across every plaintext-capable service over years is not.

The documented cost of an intercepted-credential incident includes mandatory notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, and customer churn, and a leaked credential often becomes the entry point for a much larger breach. Against that, the remediation is a setting change plus, in a few cases, a bounded client update. The finance role is to attach expected loss to each failing connection, based on what flows over it, so the work is prioritised by what an interception would expose, not by the order the report lists it.

What finance can do about the encryption-in-transit gap

Finance cannot flip a TLS flag, but it owns the framing that turns a scatter of red findings into a risk-ordered plan with no incremental Azure spend and a clearly bounded set of exceptions. Three levers.

1. Establish that the closures are zero-cost and the only cost is a client update

Make explicit that every encryption-in-transit finding costs nothing in Azure spend to fix: disabling the non-SSL Redis port, switching to HTTPS only and raising the TLS floor does not move the bill. The only real cost is engineering time, concentrated where an old client still connects over plaintext or pins an outdated TLS version and has to be updated first. Budget those few client updates as discrete lines and treat everything else as a setting change, so nobody can claim the whole capability is a spending decision.

2. Order the work by what each connection carries, not by finding count

A Redis cache holding session tokens reachable over its non-SSL port and an internal function with no sensitive payload both show up as a single red finding, but their expected loss differs by orders of magnitude. Ask the team to map each failing service to what flows over its connections and prioritise the credential- and payload-carrying ones first. The metric that belongs on the cost-and-security review is the count of encryption-in-transit findings weighted by the sensitivity of what each connection carries, not the raw total.

3. Treat any legacy plaintext client as a tracked, time-boxed exception

If an old client genuinely cannot yet use TLS and the plaintext path has to stay open a little longer, that should be a recorded, finance-visible exception with an owner and a date by which the client will be updated and the door closed. The distinction between 'we reviewed this, the client is on a migration plan, and the door closes on this date' and 'we never noticed the port was open' is exactly what makes the posture defensible at audit and in the aftermath of any incident.

Quick quiz

Question 1 of 5

A security report shows nine encryption-in-transit findings across a cache, two web apps and several functions. As the finance partner, what is the right starting assumption about their Azure-spend cost to remediate?

Keep learning

Go deeper on how each Azure service expresses whether it will accept an unencrypted connection, across the settings in this capability.

You have finished the finance view of enforcing encryption in transit. You know the cost model is one-sided: every finding closes at no Azure spend, the only real cost is the engineering time to update a few legacy plaintext clients, and the downside of leaving plaintext open is the documented and unbounded cost of an intercepted credential that becomes the door to a larger breach. Next time encryption-in-transit findings land, you will order them by what each connection carries, ring-fence and time-box any legacy plaintext path, and ask for it on the record rather than asking how much remediation will cost.

Back to the library

Encryption in transit: the headline

Whether any service in the estate will hand over data or credentials over an unencrypted connection

Encryption in transit is the control that decides whether a credential or a customer record can be read off the wire by anyone sitting on the network path. A cache that accepts a non-SSL connection, or a web app that answers plain HTTP, is one observed request away from leaking whatever it carries, and the report shows this as a scatter of separate findings across different service types.

The leadership question is not 'are we compliant today?' It is 'can any part of the estate be made to speak plaintext, by accident or by an attacker downgrading the connection?' The defensible end state is that TLS is enforced everywhere, the unencrypted ports and HTTP endpoints are off, a modern minimum TLS version is set, and Azure Policy denies the creation of any new resource that would reopen a plaintext path.

None of this is a cost decision. Enforcing TLS is essentially free in Azure terms. It is a governance decision about whether plaintext on the wire is prevented by design or only by everyone remembering to set one flag on every service they deploy.

A short read for the leader who needs to know what an unencrypted connection exposes, why enforcing TLS is a governance decision rather than a budget one, and what a defensible end state looks like across every service type in the estate.

Fun fact

The downgrade nobody noticed

What it looks like when plaintext is prevented by design, not luck

After a security review flagged that the company's payment web app would still answer a plain HTTP request, the CEO asked the obvious question: could a customer's card details be read off the wire? The honest answer at the time was that it depended on whether anyone had remembered to switch 'HTTPS only' on, because TLS enforcement across the estate was governed by habit rather than policy. Each web app, cache and function carried its own flag, and any one of them could have been left in the plaintext-capable default.

The team's response was to stop treating encryption in transit as a per-service cleanup and start treating it as a guardrail. They listed every service that would accept an unencrypted connection, updated the one legacy client that still needed it, turned off the non-SSL port on Redis, set every web app and function to HTTPS only with a minimum TLS of 1.2, and then assigned Azure Policy to deny the creation of any new resource that would reopen a plaintext path. The next time the CEO asked the question, the answer had changed from 'we believe so' to 'no, the platform refuses unencrypted connections by design.' That shift, from relying on everyone remembering to set one flag to making plaintext structurally impossible, is the one-line confidence signal this capability delivers, and it costs nothing in Azure spend to reach.

Why this is a board-level risk

Encryption in transit is the control that decides whether a credential or a customer record can be read off the network by anyone sitting on the path. Leaving a plaintext port or an HTTP endpoint open is the kind of root cause that turns a quiet network compromise into a stolen-credential breach, and enforcing TLS everywhere is what makes that root cause structurally difficult. An Azure Policy backstop makes it close to impossible.

The cost of getting this wrong is large and well documented, while the cost of fixing it is essentially engineering time. This is the rare class of control where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should be quickest to approve.

The leadership move on encryption in transit

The executive handle is not to approve each closure individually; it is to require that plaintext on the wire is prevented by policy and that any temporary plaintext exception is a named, owned, time-boxed decision, on the record.

1. Set a deadline to reach a backstopped end state

Ask for a date by which the estate is inventoried, the legacy plaintext clients are updated, the non-SSL ports and HTTP endpoints are off with a TLS 1.2 floor, and Azure Policy denies the creation of any new resource that would accept an unencrypted connection. A backstop that no individual resource can override is the difference between checking nothing speaks plaintext today and guaranteeing nothing can be created to speak it tomorrow.

2. Ask for proof, not assurance

The proof that this is closed is not a verbal 'we are on it.' It is a passing set of encryption-in-transit recommendations across every subscription plus evidence that the deny policies are assigned. Because Defender for Cloud assesses on a periodic cycle, ask for that evidence with a little lead time before any audit deadline rather than the morning of.

3. Treat any remaining plaintext path as a named, owned, dated exception

If a legacy client forces a plaintext path to stay open for now, that is survivable, but only as a deliberate, documented decision with an owner and a date by which it closes. The goal is not to debate each service; it is zero unintended plaintext paths and zero open-ended ones.

Quick quiz

Question 1 of 5

At a board review you ask whether a customer's card details could be read off the wire on the payment app. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how each Azure service expresses whether it will accept an unencrypted connection, across the settings in this capability.

Two takeaways. Encryption in transit is the rare control where the risk of inaction is severe and the cost of action is essentially engineering time, so it is the trade you should be quickest to approve. And the defensible end state is not 'we checked and nothing speaks HTTP today'; it is Azure Policy that denies any new resource an unencrypted path and a TLS 1.2 floor everywhere, making plaintext on the wire structurally impossible, with any temporary legacy exception documented, owned and dated.

Back to the library

Controls this lesson covers

One capability, many Microsoft Defender for Cloud recommendations. This lesson is the shared playbook; each control below keeps its own deep page with the exact check, severity and a copy-and-paste fix.

App Service

Azure API Management

API Management APIs should use only encrypted protocols High Serving APIs over plain HTTP or WS exposes data in transit to interception and tampering.

Azure App Service

Azure Functions

Enforce encryption in transit across Azure services

Encryption in transit: the basics

The downgrade nobody noticed

Finding plaintext-capable services across a subscription

How Defender for Cloud decides a service will speak plaintextdeep dive

What is the impact of leaving plaintext connections open?

How do you enforce TLS safely?

1. Inventory every plaintext-capable service

2. Find the clients that still use plaintext

3. Close the plaintext doors, highest impact first

4. Ratchet it shut with Azure Policy

Quick quiz

Keep learning

Encryption in transit: the cost and risk view

The downgrade nobody noticed

How a finance partner frames the encryption-in-transit decision

Why plaintext on the wire belongs on the risk register

What finance can do about the encryption-in-transit gap

1. Establish that the closures are zero-cost and the only cost is a client update

2. Order the work by what each connection carries, not by finding count

3. Treat any legacy plaintext client as a tracked, time-boxed exception

Quick quiz

Keep learning

Encryption in transit: the headline

The downgrade nobody noticed

What it looks like when plaintext is prevented by design, not luck

Why this is a board-level risk

The leadership move on encryption in transit

1. Set a deadline to reach a backstopped end state

2. Ask for proof, not assurance

3. Treat any remaining plaintext path as a named, owned, dated exception

Quick quiz

Keep learning

Controls this lesson covers

App Service

Azure API Management

Azure App Service

Azure Functions

Azure Kubernetes Service

Azure SQL Database

Redis

Service Fabric

Virtual Machines

Related compliance lessons