Unused API endpoints should be disabled and removed from Logic Apps (Preview)

What does the recommendation "Unused API endpoints should be disabled and removed from Logic Apps (Preview)" check?

Flags request-triggered API endpoints on a Logic App that have received no traffic for 30 days, which Defender for Cloud treats as dormant. The signal comes from the API security posture extension, so it only appears once the Defender CSPM plan and that extension are enabled; it does not surface on the free tier or under Defender for APIs, which covers Azure API Management only. It assesses the HTTP/Request trigger endpoint based on observed call volume, not the internal actions, connectors or recurrence-triggered workflows that never expose a callable URL. It does not judge whether the endpoint is authenticated or internet-facing; those are separate Logic Apps recommendations.

Why does "Unused API endpoints should be disabled and removed from Logic Apps (Preview)" matter?

A Logic App request endpoint is a public callback URL that can invoke a workflow. An endpoint nobody calls is one nobody is watching: it keeps its trigger URL and SAS signature live while drifting out of mind, so it misses the review, secret rotation and connector updates that active workflows get. Attackers who recover an old URL from logs, source control or a shared runbook can replay it to trigger downstream actions, move data or pivot into the backend systems the workflow touches, all without tripping anyone's attention. Every dormant endpoint widens the attack surface for zero business value, so retiring it removes a standing liability rather than accepting an unmonitored one.

How do I fix "Unused API endpoints should be disabled and removed from Logic Apps (Preview)"?

1. Confirm the endpoint really is unused: open the Logic App in the portal, check 'Overview' run history and 'Trigger history' for the last invocation, and rule out a quarterly or seasonal caller before you touch anything.
2. If the workflow is still needed but the public trigger is not, disable the workflow with 'az logic workflow update --resource-group <rg> --name <logic-app> --state Disabled' (Consumption) so the trigger URL stops accepting calls while you keep the definition.
3. Once you have confirmed it is genuinely redundant, delete it with 'az logic workflow delete --resource-group <rg> --name <logic-app>', then remove the workflow definition from your Bicep or Terraform module so a redeploy does not recreate the dormant endpoint.

# 1. Enable the Defender for APIs plan on the subscription so onboarded APIs are inspected.
az security pricing create --name Api --tier Standard

# 2. Disable the deprecated direct management endpoint (retired 15 March 2025).
#    'customProperties' on the service controls this gateway behaviour.
az apim update --name apim-prod --resource-group rg-platform \
  --set 'properties.customProperties."Microsoft.WindowsAzure.ApiManagement.Gateway.ManagementEndpoint"=false'

# 3. Re-enable backend certificate chain and name validation on a backend that
#    had it switched off. There is no native 'az apim backend' TLS flag, so PUT
#    the documented 'tls' block via the management API (api-version 2024-05-01).
sub=$(az account show --query id -o tsv)
az rest --method put \
  --uri "https://management.azure.com/subscriptions/$sub/resourceGroups/rg-platform/providers/Microsoft.ApiManagement/service/apim-prod/backends/payments-backend?api-version=2024-05-01" \
  --body '{"properties":{"url":"https://payments.internal/","protocol":"http","tls":{"validateCertificateChain":true,"validateCertificateName":true}}}'

# 4. Ratchet it shut: audit any instance whose management endpoint stays enabled.
#    Look the built-in policy up by display name; never hardcode a definition GUID.
pid=$(az policy definition list \
  --query "[?displayName=='API Management direct management endpoint should not be enabled'].name" -o tsv)
az policy assignment create \
  --name audit-apim-mgmt-endpoint \
  --policy "$pid" \
  --scope "/subscriptions/$sub"