Microsoft Defender for Cloud · Azure API Management
API Management direct management endpoint shouldn't be enabled
Written and reviewed by Emnode · Last reviewed
What does the recommendation "API Management direct management endpoint shouldn't be enabled" check?
Flags any API Management service that has the legacy direct management REST API switched on, by evaluating the tenant access setting (the 'enabled' property on the service's management tenant resource). This is the standalone https://<service>.management.azure-api.net endpoint authenticated with a shared access token, not the Azure Resource Manager control plane. The check does not look at your gateway, the developer portal, public network access, or whether a private endpoint is configured: it is purely about whether the old out-of-band management API is reachable.
Why does "API Management direct management endpoint shouldn't be enabled" matter?
The direct management endpoint pre-dates Resource Manager and sidesteps it entirely. Calls to it are not subject to Azure RBAC, conditional access, Resource Manager authorisation or Resource Manager request throttling, and they are authenticated with a long-lived shared access token rather than a per-user identity. Anyone holding or leaking that token can read and rewrite your API configuration with no role assignment and little useful audit trail. Because the feature is legacy and rarely used deliberately, an enabled endpoint is usually a leftover that quietly widens your attack surface and undermines least-privilege governance. Microsoft has deprecated this API, so disabling it also removes a path that will stop receiving fixes.
How do I fix "API Management direct management endpoint shouldn't be enabled"?
- In the portal, open the API Management service, go to Deployment + infrastructure, select Management API, and set 'Enable Management REST API' to No so the direct endpoint is turned off.
- To enforce it across an estate, assign the built-in audit policy 'API Management direct management endpoint shouldn't be enabled' (look the definition up by name rather than pasting a GUID): pid=$(az policy definition list --query "[?displayName=='API Management direct management endpoint shouldn''t be enabled'].name" -o tsv); az policy assignment create --name no-apim-direct-mgmt --policy "$pid" --scope /subscriptions/<sub-id>. Set the effect parameter to Deny if you want to block new instances outright.
- In Bicep or ARM, deploy the tenant access child resource with 'enabled: false' under the service so the safe state is declared in code: resource access 'Microsoft.ApiManagement/service/tenant@2023-05-01-preview' = { parent: apim, name: 'access', properties: { enabled: false } }.
Remediation script · bash
# 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" Full walkthrough (console steps, edge cases and verification) in the lesson Harden Azure API Management.
Is "API Management direct management endpoint shouldn't be enabled" a false positive?
A team still running tooling or migration scripts that call the direct management API (for example an older configuration backup job written before the Resource Manager APIs covered everything) will see this flag while that dependency exists. That is a deliberate, time-boxed exception rather than a defect: scope the management token tightly, log its use, and plan the move to Resource Manager so the endpoint can be disabled and the finding cleared.
More Azure API Management controls
- API endpoints in Azure API Management should be authenticated
- API endpoints that are unused should be disabled and removed from the Azure API Management service
- API Management APIs should use only encrypted protocols
- API Management calls to API backends shouldn't bypass certificate thumbprint or name validation
- API Management secret named values should be stored in Azure Key Vault
- API Management subscriptions shouldn't be scoped to all APIs
- Azure API Management APIs should be onboarded to Defender for APIs