Azure resources that participate in service-to-service communications can authenticate their peers with client certificates, in a mutual TLS handshake. Disabling that mechanism leaves the endpoint relying on weaker controls, such as passwords or network position alone, to establish trust between the two parties.

Why is this an issue?

Several Azure services let workloads authenticate their peers with client certificates over TLS, establishing mutual trust between the two ends of the connection. Unlike a shared password, a certificate cannot be forged or replayed by a man-in-the-middle, and its private key never leaves the holder, which makes it considerably harder to steal.

This rule targets resources used for internal, machine-to-machine traffic, where mTLS is the industry-standard authentication mechanism. Externally-facing endpoints handling browser or mobile traffic are out of scope, since certificate-based authentication is impractical there.

Disabling client certificate authentication on an internal resource, or selecting an authentication mode that does not require a certificate, removes the mutual-trust guarantee. The endpoint must then rely on weaker controls, such as passwords or network reachability, to decide whether the caller is legitimate.

Certificates also support precise incident response. Compromised certificates can be revoked individually, and an issuing certificate authority can be revoked to invalidate every certificate it produced. Authentication mechanisms that do not rely on certificates do not offer that level of traceability and containment.

What is the potential impact?

Without client certificate authentication, an attacker who learns a shared password or reaches the endpoint over the network can impersonate the legitimate caller. Depending on what the affected resource handles, this exposes data flowing through the endpoint, the credentials it stores, or any downstream system it integrates with.

Recovery is also harder. A password leak typically forces a rotation across every caller that knows it, whereas certificate-based authentication scopes the blast radius to a single revoked credential and preserves an audit trail of which certificate was used.

How to fix it in Azure App Service

Set client_certificate_enabled to true and client_certificate_mode to Required on azurerm_linux_web_app, azurerm_windows_web_app, azurerm_linux_function_app, azurerm_windows_function_app, and their _slot variants. For azurerm_logic_app_standard, the equivalent attribute is client_cert_mode.

Code examples

The following code disables client certificate authentication on an Azure resource, leaving the endpoint to rely on weaker controls such as passwords, or on no peer authentication at all.

Noncompliant code example

resource "azurerm_linux_web_app" "internal_api" {
  public_network_access_enabled = false
  client_certificate_enabled    = true
  client_certificate_mode       = "Optional" # Noncompliant
}

resource "azurerm_logic_app_standard" "workflow_runner" {
  public_network_access_enabled = false
  client_cert_mode              = "Optional" # Noncompliant
}

Compliant solution

resource "azurerm_linux_web_app" "internal_api" {
  public_network_access_enabled = false
  client_certificate_enabled    = true
  client_certificate_mode       = "Required"
}

resource "azurerm_logic_app_standard" "workflow_runner" {
  public_network_access_enabled = false
  client_cert_mode              = "Required"
}

How to fix it in Azure Container Apps

Set ingress.client_certificate_mode to require on the azurerm_container_app resource.

Code examples

The following code disables client certificate authentication on an Azure resource, leaving the endpoint to rely on weaker controls such as passwords, or on no peer authentication at all.

Noncompliant code example

resource "azurerm_container_app" "internal_worker" {
  ingress {
    target_port             = 80
    external_enabled        = false
    client_certificate_mode = "accept" # Noncompliant
  }
}

Compliant solution

resource "azurerm_container_app" "internal_worker" {
  ingress {
    target_port             = 80
    external_enabled        = false
    client_certificate_mode = "require"
  }
}

How to fix it in Azure Data Factory

A azurerm_data_factory_linked_service_web resource calls an external HTTP endpoint as part of a Data Factory pipeline. The authentication_type argument selects how the runtime authenticates to that endpoint, and any value other than ClientCertificate disables certificate-based authentication.

Code examples

The following code disables client certificate authentication on an Azure resource, leaving the endpoint to rely on weaker controls such as passwords, or on no peer authentication at all.

Noncompliant code example

resource "azurerm_data_factory_linked_service_web" "example" {
  authentication_type = "Basic" # Noncompliant
}

Compliant solution

resource "azurerm_data_factory_linked_service_web" "example" {
  authentication_type = "ClientCertificate"
}

Resources

Documentation

Standards