Deny policy

Question

Deny policy

moti jirata 25

Can you give me an example for a deny policy for webapps that doesnt have the latest minTls version?

Bharath Y P 10,355 Reputation points Microsoft External Staff Moderator

2026-06-01T10:35:08.2+00:00

Could you please help us with the requested details, thanks

3 answers

Your answer

Bharath Y P 10,355 Reputation points Microsoft External Staff Moderator

2026-06-01T10:35:08.2+00:00

Could you please help us with the requested details, thanks

Answer 1

Bharath Y P 10,355 Microsoft External Staff Moderator

Hello moti jirata! To give you the right “deny” policy example, I need a bit more context. Could you help me clarify:

Which resource are you targeting?
- Azure App Service (Web App) TLS setting?
- Application Gateway WAF TLS policy?
- Another service altogether?
How are you enforcing it today?
- Via Azure Policy definitions?
- Custom WAF rules on App Gateway?
- ARM template or Bicep?
What exactly do you consider “latest” TLS?
- TLS 1.2 as the minimum?
- TLS 1.3 requirement?
Do you already have an existing policy that you want to modify, or should we craft one from scratch?

Once I know those details, I can whip up a precise deny-rule example for you!

moti jirata 25

It is an Azure App Service (Web App) TLS setting , i have an EPAC and use Bicep to deploy and latest in is context is anything above TLS 1.2. Below is my deny policy which is custom, it works now to deny creation or updating a webapp with TLS version 1.1 or lower but my issue now is that azure flags my webapps as non-compliant eventhough they are. The policy works but the policy assement is not doing its job since i can see in the detail the the actualvalue[] is empty and is not matching the target value[].

 "properties": {
    "displayName": "App Service apps should use the latest TLS version",
    "policyType": "Custom",
    "mode": "All",
    "description": "Periodically, newer versions are released for TLS either due to security flaws, include additional functionality, and enhance speed. Upgrade to the latest TLS version for App Service apps to take advantage of security fixes, if any, and/or new functionalities of the latest version.",
    "metadata": {
      "version": "2.2.1",
      "category": "App Service"
    },
    "version": "2.2.1",
    "parameters": {
      "effect": {
        "type": "String",
        "metadata": {
          "displayName": "Effect",
          "description": "The effect determines what happens when the policy rule is evaluated to match"
        },
        "allowedValues": [
          "Disabled",
          "Deny",
          "Audit"
        ],
        "defaultValue": "Deny"
      },
      "minimalTlsVersion": {
        "type": "String",
        "metadata": {
          "displayName": "Minimal TLS version",
          "description": "The minimal TLS version that is allowed. App Service apps with a lower TLS version will be non-compliant."
        },
        "allowedValues": [
          "1.2",
          "1.3"
        ],
        "defaultValue": "1.2"
      }
    },
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Web/sites"
          },
          {
            "field": "kind",
            "notContains": "functionapp"
          },
          {
          "anyOf": [
            {
              "field": "Microsoft.Web/sites/siteConfig.minTlsVersion",
              "exists": false
            },
           {
            "field": "Microsoft.Web/sites/siteConfig.minTlsVersion",
            "less": "[parameters('minimalTlsVersion')]"
          }
        ]
        }
      ]
      },

      "then": {
        "effect": "[parameters('effect')]"
      }
    }
  }

Bharath Y P 10,355 Reputation points Microsoft External Staff Moderator

2026-06-15T03:34:45.6933333+00:00
Your setup Deny policy works > blocks TLS < 1.2. Compliance shows non-compliant even when TLS = 1.2 and actualValue[] is empty. This is look like not a logic issue in your comparison It is an alias / resource shape issue in Azure Policy evaluation.

Azure Policy cannot consistently evaluate siteConfig.minTlsVersion when:

Defined under Microsoft.Web/sites

Due to alias limitations and resource shape differences

Deny evaluates request payload, not persisted resource state.

Use:

Microsoft.Web/sites/config/minTlsVersion alias

OR combine both config + siteConfig paths

This results Accurate compliance + no false positives.

Answer 2

Hello moti jirata,

Greetings! Thanks for raising this question in Q&A forum.

The Deny effect in Azure Policy is used to block resource requests that don't comply with your defined governance standards. When a resource creation or update request matches a deny policy, it is blocked before it even reaches the Resource Provider and returns a 403 (Forbidden) error.

Why the Deny Policy Triggers

Azure Policy evaluates every resource create/update request. The deny effect is processed before audit, so any non-compliant resource is blocked immediately. Common reasons this happens:

The resource doesn't meet location restrictions (e.g., only eastus is allowed)

The resource type isn't permitted in your subscription or resource group

Required tags are missing on the resource

SKU or pricing tier doesn't match the policy rules

How Deny Policy Evaluation Works

Azure Policy uses a cumulative most restrictive model — if multiple policies apply to the same resource and both have a deny effect, the resource is blocked regardless of scope. The evaluation order is:

disabled (checked first — skips evaluation if disabled)

append and modify (can alter the request)

deny (blocks the request if matched)

audit (logs non-compliance)

auditIfNotExists / deployIfNotExists (evaluated last)

How to Fix or Bypass a Deny Policy

Check which policy is blocking: Go to Azure Portal → Resource Group / Subscription → Policies → Compliance and look for non-compliant assignments

Add an exclusion: If a specific resource or resource group should be exempt, add it as an exclusion in the policy assignment scope

Update the policy rule: If the policy condition is too restrictive, modify the if condition in the policy definition to narrow its scope

Use the correct values: Ensure your resource properties (location, SKU, tags) align with what the policy expects

Deny vs. DenyAction

These are two different effects — don't confuse them:

Effect	Blocks	Use Case
`deny`	Create / Update requests	Enforce standards on resource configuration

`deny`	Create / Update requests	Enforce standards on resource configuration
`denyAction`	Delete requests	Protect critical resources from accidental deletion

If you share the specific error message or the policy rule that is blocking you, I can help narrow down the exact fix!

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.

Answer 3

Below is an example Azure Policy definition that denies web apps whose minimum TLS version is not the latest (for example, anything less than 1.2). Adjust the field and equals values to match the specific resource type and latest TLS version used in the environment.

{
  "properties": {
    "displayName": "Deny web apps that do not use latest minimum TLS version",
    "policyType": "Custom",
    "mode": "All",
    "description": "Denies creation or update of web apps where minTlsVersion is less than the required version.",
    "metadata": {
      "category": "App Service"
    },
    "parameters": {
      "requiredMinTlsVersion": {
        "type": "String",
        "metadata": {
          "displayName": "Required minimum TLS version",
          "description": "Minimum TLS version that web apps must use."
        },
        "allowedValues": [
          "1.0",
          "1.1",
          "1.2",
          "1.3"
        ],
        "defaultValue": "1.2"
      }
    },
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Web/sites"
          },
          {
            "field": "Microsoft.Web/sites/config/minTlsVersion",
            "notEquals": "[parameters('requiredMinTlsVersion')]"
          }
        ]
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}

This follows the same pattern as the minimum TLS enforcement examples in the context: a deny effect that blocks create/update operations when the configured minimum TLS version is lower than the required one.

References: