Compliance

Harden Azure API Management

One capability across your API gateway: make sure every published endpoint is authenticated, monitored by Defender for APIs, scoped to least privilege, and that nothing it talks to (backends, secrets, the management plane) bypasses the checks you meant to enforce.

15 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-apim-backend-certificate-validation azure-apim-direct-management-endpoint-disabled azure-apim-endpoints-authenticated azure-apim-named-values-in-key-vault azure-apim-onboarded-to-defender-for-apis azure-apim-subscriptions-not-scoped-all-apis azure-apim-unused-endpoints-removed azure-logic-app-api-endpoints-authenticated azure-logic-app-unused-api-endpoints-removed

Hardening API Management: the basics

What does a weakly governed Azure API gateway actually look like?

Azure API Management is the front door to a lot of an organisation's data and logic, and weakness shows up in a handful of distinct shapes rather than one setting. An endpoint can be published with no authentication at all, so anyone who finds the URL can call it. APIs can be invisible to threat detection because they were never onboarded to Defender for APIs. Old endpoints that stopped receiving traffic can be left active long after they should have been retired. A subscription key can be scoped to all APIs instead of one product. The gateway can call its backends with certificate validation switched off, the deprecated direct management endpoint can still be enabled, and secret named values can sit as encrypted strings inside API Management instead of in Key Vault. Each is its own Defender for Cloud recommendation, but the underlying risk is the same: an API surface that is more reachable, less observed, or more trusting than you intended.

Microsoft Defender for Cloud, through its Defender for APIs plan and CSPM posture checks, turns each of these into its own recommendation, which is why one API-heavy subscription can fail several gateway checks at once. 'API endpoints in Azure API Management should be authenticated' and 'Azure API Management APIs should be onboarded to Defender for APIs' are the two that matter most, because the first closes the widest door and the second is what lets Defender see the traffic at all. They pair with the least-privilege, backend-trust, management-plane and secret-storage recommendations to form a single capability. They read as separate problems on the report, but they are one job: make every endpoint authenticated and observed, and stop the gateway from trusting anything it should not.

Most of this is drift, not intent. An API imported for a quick proof of concept that never had a policy attached, an instance that pre-dates Defender for APIs, a subscription left scoped to all APIs because that was the fastest way to unblock a test, a backend where someone disabled certificate validation to get past a self-signed cert and never re-enabled it. The work is to find every endpoint and setting that is weaker than intended, decide which exceptions are genuine, and bring the rest up to a consistent, enforced baseline.

In this lesson you will learn how Azure API Management expresses authentication, observability, least privilege and backend trust, how to find every weakly governed endpoint and setting in an instance, and how to bring them up to a consistent baseline without breaking live integrations. 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 endpoint nobody was watching

A large share of reported API breaches trace back to two boring root causes: an endpoint that should have required authentication but did not, and an old API that should have been retired but was quietly left running without current security coverage. The industry shorthand for the second one is the 'zombie API', an endpoint still reachable long after the team forgot it existed. Defender for APIs flags any endpoint that has seen no traffic for 30 days for exactly this reason: the APIs you have stopped thinking about are the ones an attacker is most likely to find first.

Finding gateway weakness across an instance

Priya is the platform lead at a fintech preparing for a SOC 2 audit. Defender for Cloud shows API Management findings spread across two instances: some APIs are unauthenticated, several have not been onboarded to Defender for APIs, and a handful of endpoints have seen no traffic in over a month.

Rather than work the findings one by one, Priya starts by listing every API in the instance and how it is secured, so the genuinely public-by-design endpoints can be separated from drift before anything changes.

Start by listing the APIs in an instance and whether each one requires a subscription key. APIs with subscriptionRequired false and no other auth policy are the widest-open doors.

$ az apim api list --resource-group rg-platform --service-name apim-prod \ --query "[].{name:displayName, path:path, subKeyRequired:subscriptionRequired}" -o table

Name Path SubKeyRequired

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

Payments API payments True

Partner Webhook webhook False

# Partner Webhook requires no subscription key. Confirm it enforces JWT or

# client-cert validation in policy, or it is an unauthenticated endpoint.

subscriptionRequired false is not automatically a finding: the API may validate a JWT or client certificate in policy instead. But an endpoint with neither a subscription key nor a validation policy is the highest-value target in this group. Fix these first.

How Defender for Cloud decides an API gateway is weakly governeddeep dive

The recommendations resolve to a few different layers of the service. Authentication is assessed at runtime: Defender for APIs checks whether an endpoint requires a subscription key (for APIs or products where subscription is required) or executes a policy that validates a JWT, a client certificate or a Microsoft Entra token. If none of those mechanisms runs during the call, the endpoint is marked unauthenticated. Observability is a plan-level fact: 'Azure API Management APIs should be onboarded to Defender for APIs' is unhealthy until you both enable the Defender for APIs plan on the subscription and onboard each API's collection, after which Defender begins inspecting traffic. Usage is traffic-based: an endpoint that has received no calls for 30 days is flagged as unused, because forgotten endpoints rarely get current security attention.

Least privilege and backend trust are configuration facts on the resource. A subscription whose scope is the whole service or all APIs, rather than a single product or API, triggers the least-privilege recommendation. A backend whose 'tls' block has 'validateCertificateChain' or 'validateCertificateName' set to false triggers the certificate-validation recommendation, because that gateway will trust a backend it should reject. The direct management endpoint recommendation fires when the deprecated management API is enabled on the instance, an endpoint that bypasses Azure Resource Manager role-based access control and throttling, and which Microsoft retired on 15 March 2025, so the only correct action is to disable it. Secret named values stored as encrypted strings inside API Management, rather than as Key Vault references, trigger the secret-storage recommendation.

Several of these are evaluated against the Microsoft Cloud Security Benchmark on a periodic cycle, so a fix does not flip a recommendation to Healthy instantly: the control-plane change is immediate, but the posture catches up on the next assessment, and the Defender for APIs detections need traffic to flow before they show value. The strongest position combines the per-resource fix with an Azure Policy backstop in audit or deny mode, so no new instance can be created with the management endpoint enabled, certificate validation bypassed, or secrets left out of Key Vault. The Logic Apps equivalents, authentication on Logic Apps API endpoints and retiring unused Logic Apps endpoints, are in preview and apply the same authenticated-and-observed logic to workflow-hosted APIs.

What is the impact of leaving the gateway weakly governed?

The direct impact is data exposure and abuse. An unauthenticated endpoint is callable by anyone who finds the URL, and API endpoints are enumerated quickly by automated scanners, so an open endpoint that fronts data is an exfiltration path. An API that was never onboarded to Defender for APIs is one nobody is watching, so anomalous or malicious traffic against it produces no alert. A subscription key scoped to all APIs turns a single leaked key into access across the whole gateway rather than one product. A backend call with certificate validation disabled is open to a man-in-the-middle that the gateway will silently trust.

The second-order impact is blast radius and invisibility. Every unauthenticated, unwatched or over-scoped endpoint is attack surface that has to be defended continuously, and the forgotten endpoints are the worst because nobody is looking at them. Hardening the gateway shrinks that surface to the APIs you actually operate and authenticate, and onboarding them to Defender for APIs means the traffic you do allow is finally being inspected, so an attack produces a signal instead of silence.

On the compliance side, every modern framework, ISO 27001, SOC 2, PCI DSS, HIPAA and the UK and EU data-protection regimes, expects evidence that exposed interfaces enforce authentication, follow least privilege, and are monitored. A passing set of API Management recommendations across every subscription, with Defender for APIs enabled on the APIs that handle real data, is a defensible artefact to hand an auditor and a genuine reduction in the most exposed layer you run.

How do you harden API Management safely?

Work the capability as one loop rather than chasing individual findings. The order matters: get visibility and authentication in place before you start retiring or re-scoping things, so you do not break a live integration that a partner depends on.

1. Onboard to Defender for APIs and inventory every endpoint

Enable the Defender for APIs plan on the subscription and onboard each instance's APIs so traffic is being inspected, then list every API, how it is authenticated, when it last received traffic, and how its subscriptions are scoped. Treat this inventory as the source of truth, not the Defender finding count, because one instance can trigger several recommendations at once.

2. Authenticate every endpoint, separate the genuine exceptions

For each endpoint with no subscription key and no validation policy, attach authentication: require a subscription key, or add a validate-jwt or validate-client-certificate inbound policy. The rare endpoint that is public by design, an open webhook or a health probe, should be a documented exception that is rate-limited and put behind a web application firewall, not left as silent drift.

3. Retire zombies and tighten least privilege

Remove endpoints that have seen no traffic for 30 days once you have confirmed they are genuinely dead, and re-scope any subscription that is scoped to all APIs down to the single product or API it actually calls. The same applies to unused Logic Apps API endpoints, which Defender now flags in preview.

4. Close the trust gaps and ratchet with Azure Policy

Re-enable backend certificate chain and name validation, disable the deprecated direct management endpoint, and move secret named values from encrypted strings into Key Vault references behind a managed identity. Then assign Azure Policy to audit or deny these states on any future instance, so the safe configuration is enforced rather than merely encouraged.

# 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"

Quick quiz

Question 1 of 5

Defender for Cloud shows API Management findings across authentication, Defender onboarding, unused endpoints and subscription scope on one instance. What is the most efficient way to think about them?

Keep learning

Go deeper on how Azure API Management expresses authentication, observability and backend trust across the settings in this capability.

You can now treat Azure API Management as one capability rather than a scatter of findings: onboard your APIs to Defender for APIs so traffic is watched, authenticate every endpoint, retire the zombies, scope subscriptions to least privilege, close the backend and management-plane trust gaps, and ratchet the estate 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

Hardening API Management: the cost and risk view

Mostly free hardening, with one metered Defender plan and a small Key Vault charge as the only real costs

Most of this capability costs nothing in Azure spend to fix. Authenticating an endpoint, retiring an unused API, scoping a subscription to a single product, re-enabling backend certificate validation, and disabling the deprecated direct management endpoint are all configuration changes that do not move the bill. The cost sits in two narrow places: the Defender for APIs plan, which is metered per API call against the APIs you onboard, and a small Key Vault charge for the secret named values you move out of API Management and into a vault.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. An unauthenticated endpoint that fronts customer data carries a far higher expected loss than an unused internal test API, yet both surface as a single red finding. Map the failures to the data and the audience behind each API, and prioritise by exposure, not by recommendation count.

The Defender for APIs charge is the one deliberate spend decision here, and it is the cheap half of the trade: it buys the threat detection that turns an unauthenticated or anomalous call from an invisible event into an alert. The downside of leaving the gateway weakly governed is the documented cost of an API breach: data exfiltration through an open endpoint, regulatory fines, breach notification, forensics and reputational damage.

This lesson is for the finance partner who sees a cluster of API Management findings on the security report and wants to know what the right response is and what it costs. It covers why most of these controls are free to fix, that the Defender for APIs plan is the one deliberate, usage-based spend, where the small Key Vault charge sits, and how to turn a list of red findings into a risk-ordered remediation plan.

Fun fact

The endpoint nobody was watching

How a finance partner frames the gateway decision

Priya is the finance partner supporting the platform team's SOC 2 push. The security report lands with fourteen API Management findings spread across two instances. The instinct is not to wave through a blanket remediation budget; it is to ask what is actually behind each red finding. Authenticating an endpoint, retiring an unused API, scoping a subscription to one product or re-enabling backend certificate validation changes nothing on the Azure bill, so the spend question is narrow: the Defender for APIs plan is metered per API call on the APIs the team onboards, and moving secret named values into Key Vault adds a small per-vault charge.

Priya asks the team to map each failing API to the data and the audience behind it. Three unauthenticated endpoints front customer-facing data, four APIs were never onboarded to Defender for APIs, two endpoints have seen no traffic in months and are candidates for retirement, and one subscription key is scoped to all APIs when it only ever calls one product. The list is reframed on the risk register: the customer-facing unauthenticated endpoints are high expected-loss items to close this sprint at zero Azure cost, onboarding the busy APIs to Defender for APIs is a deliberate and modest metered spend that buys threat detection, and the zombie endpoints are low-value drift to retire. The finance pack reads: 'Most findings close at no incremental spend; the only real cost is the Defender for APIs plan, which we are choosing to pay for the most exposed APIs, plus a small Key Vault line.'

Why API gateway weakness belongs on the risk register

The cost model here is favourable in a way that is easy to miss. The great majority of the findings, authentication, unused endpoints, subscription scope, backend validation and the management endpoint, cost nothing in Azure spend to fix. The only deliberate spend is the Defender for APIs plan, which is metered per API call on the APIs you onboard, and a small Key Vault charge for the secrets you relocate. Each failing recommendation is an API where a future accident or a leaked key could expose data, and while the probability per endpoint is low, the probability across all endpoints over years is not.

The documented cost of an API breach includes mandatory notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, and customer churn. Against that, the Defender for APIs charge is a small, usage-based premium that buys the detection layer, and the rest of the remediation is engineering time. The finance role is to attach expected loss to each failing endpoint so the work is prioritised by risk, and to recognise the Defender plan as the cheap half of an asymmetric trade rather than a line to cut.

What finance can do about the gateway gap

Finance cannot attach an authentication policy, but it owns the framing that turns a scatter of red findings into a risk-ordered plan with one deliberate, usage-based spend and an otherwise free remediation. Three levers.

1. Separate the zero-cost fixes from the one metered spend

Make explicit that the overwhelming majority of API Management findings cost nothing in Azure spend to fix: authenticating an endpoint, retiring an unused API, scoping a subscription, re-enabling backend validation or disabling the management endpoint does not move the bill. The only real cost is the Defender for APIs plan, metered per API call on the APIs the team chooses to onboard, plus a small Key Vault charge for relocated secrets. Budget the Defender plan as a discrete, scoped line and treat everything else as engineering time, so nobody can claim the whole capability is a spending decision.

2. Order the work by expected loss, not by finding count

An unauthenticated endpoint fronting customer data and an unused internal test API both show up as a single red finding, but their expected loss differs by orders of magnitude. Ask the team to map each failing endpoint to the data and audience behind it and prioritise the customer-facing, data-bearing APIs first. The metric that belongs on the cost-and-security review is the count of API findings weighted by the sensitivity and exposure of what each endpoint serves, not the raw total.

3. Scope the Defender for APIs spend deliberately

Because the plan is metered per call, the spend follows the APIs you onboard. Treat onboarding as a risk decision: the busy, data-bearing, externally exposed APIs are the ones worth paying to watch, and a quiet internal API may be lower priority. Recording which APIs are onboarded and why makes the Defender line defensible at the cost review and at audit, and keeps the spend proportional to the exposure it covers.

Quick quiz

Question 1 of 5

A security report shows fourteen API Management findings. As the finance partner, what is the right starting assumption about their Azure-spend cost to remediate?

Keep learning

Go deeper on how Azure API Management expresses authentication, observability and backend trust across the settings in this capability.

You have finished the finance view of hardening API Management. You know the cost model is favourable: the great majority of findings close at no Azure spend, the one deliberate cost is the Defender for APIs plan, which is a usage-based visibility investment you scope to the APIs that matter, and the only other charge is a small Key Vault line. Next time a cluster of gateway findings lands, you will order them by expected loss, scope the Defender spend to the exposed, data-bearing APIs, and ring-fence the genuine exceptions on the record.

Back to the library

Hardening API Management: the headline

Whether the front door to your data and logic is authenticated, watched, and trusted only where you meant it to be

API Management is where a lot of the estate's data and business logic is actually exposed to callers, so it is the category of risk where a single weak endpoint can become an exfiltration path. An API that takes no authentication, or one that no security tooling is even watching, is one discovery away from being abused, and the report shows this as a scatter of separate findings across the gateway.

The leadership question is not 'are we compliant today?' It is 'is every API we publish authenticated, is Defender watching them, and does the gateway trust only what we intended?' The defensible end state is that authentication is required on every endpoint, every API is onboarded to Defender for APIs, unused endpoints are retired, subscriptions follow least privilege, and the management plane and backend connections cannot be silently weakened.

Only one part of this is a cost decision, the Defender for APIs plan, and it is a small, usage-based spend that buys visibility into the most exposed layer you operate. The rest is governance: whether the gateway is hardened by design or only by everyone remembering to attach the right policy.

A short read for the leader who needs to know what a weakly governed API gateway exposes, why hardening it is mostly a governance decision with one small metered spend, and what a defensible end state looks like across the estate's APIs.

Fun fact

The endpoint nobody was watching

What it looks like when API exposure is governed by design, not luck

After an industry peer disclosed a breach that began with a single unauthenticated API endpoint nobody remembered shipping, the CEO asked the obvious question at the next review: could that happen to us? The honest answer at the time was that it depended on whether anyone had remembered to attach an authentication policy, because auth, Defender coverage and least-privilege scoping across the gateway were governed by habit rather than guardrail.

The team's response was to stop treating API Management as a per-endpoint cleanup and start treating it as a hardened front door. They listed every API and how it was secured, attached authentication to the endpoints that lacked it, onboarded the live APIs to Defender for APIs so the traffic was finally being watched, retired the zombie endpoints, scoped subscriptions down to single products, and set Azure Policy to audit any API Management instance with the deprecated management endpoint enabled or backend certificate validation bypassed. The next time the CEO asked the question, the answer had changed from 'we believe so' to 'every published endpoint is authenticated, Defender is watching them, and the one deliberately open endpoint is documented and rate-limited.' That shift, from relying on everyone remembering to attach the right policy to making the weak state structurally hard, is the confidence signal this capability delivers.

Why this is a board-level risk

A large share of major API breaches came back to the same root causes: an endpoint that should have required authentication but did not, or an old endpoint nobody was watching. Hardening API Management is the capability that makes those root causes structurally difficult, and onboarding to Defender for APIs is what turns the traffic you do allow from invisible into monitored.

Most of getting this right is engineering time, and the one cost, the Defender for APIs plan, is a small usage-based spend that buys visibility into the most exposed layer you operate. This is the rare class of control where the risk of inaction is severe, the bulk of the fix is free, and the only spend is the cheap and valuable half. That is exactly the trade leadership should be quickest to approve.

The leadership move on the gateway

The executive handle is not to approve each fix individually; it is to require that every published endpoint is authenticated and watched, that least privilege is the default, and that the few deliberately open endpoints are documented, on the record.

1. Set a deadline to reach a backstopped end state

Ask for a date by which every API is onboarded to Defender for APIs, every endpoint is authenticated or documented as a deliberate exception, zombie endpoints are retired, subscriptions follow least privilege, and Azure Policy audits or denies the deprecated management endpoint, bypassed backend validation and secrets left out of Key Vault. A backstop that no individual instance can override is the difference between checking nothing is weak today and guaranteeing nothing can be created weak tomorrow.

2. Treat Defender for APIs as a visibility investment, not a cost to trim

The one spend in this capability buys monitoring of the most exposed layer you operate. Ask which APIs are onboarded and why, and make sure the busy, data-bearing, externally exposed ones are covered. The right question is not 'how do we minimise this bill?' but 'are we paying to watch the APIs whose compromise would hurt most?'

3. Require documented, owned exceptions for genuinely open endpoints

A small number of endpoints, an open webhook, a public health probe, are unauthenticated on purpose, and that is fine. The leadership requirement is that each is a deliberate, documented decision with an owner, rate-limited and behind a web application firewall, not an accident left open. The goal is not zero open endpoints; it is zero unintended ones.

Quick quiz

Question 1 of 5

At a board review you ask whether an open-endpoint incident like a competitor's could happen to your estate. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Azure API Management expresses authentication, observability and backend trust across the settings in this capability.

Two takeaways. API gateway weakness is the rare control where the risk of inaction is severe, the bulk of the fix is engineering time, and the only spend, Defender for APIs, is the cheap and valuable half that buys visibility into your most exposed layer. And the defensible end state is not 'we checked and nothing looked open'; it is every endpoint authenticated, every API watched by Defender, subscriptions least-privileged, and the few deliberately open endpoints documented, owned and behind a web application firewall.

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.

Azure API Management

Azure Logic Apps

Part of the learning path Harden Azure workloads

Harden Azure API Management

Hardening API Management: the basics

The endpoint nobody was watching

Finding gateway weakness across an instance

How Defender for Cloud decides an API gateway is weakly governeddeep dive

What is the impact of leaving the gateway weakly governed?

How do you harden API Management safely?

1. Onboard to Defender for APIs and inventory every endpoint

2. Authenticate every endpoint, separate the genuine exceptions

3. Retire zombies and tighten least privilege

4. Close the trust gaps and ratchet with Azure Policy

Quick quiz

Keep learning

Hardening API Management: the cost and risk view

The endpoint nobody was watching

How a finance partner frames the gateway decision

Why API gateway weakness belongs on the risk register

What finance can do about the gateway gap

1. Separate the zero-cost fixes from the one metered spend

2. Order the work by expected loss, not by finding count

3. Scope the Defender for APIs spend deliberately

Quick quiz

Keep learning

Hardening API Management: the headline

The endpoint nobody was watching

What it looks like when API exposure is governed by design, not luck

Why this is a board-level risk

The leadership move on the gateway

1. Set a deadline to reach a backstopped end state

2. Treat Defender for APIs as a visibility investment, not a cost to trim

3. Require documented, owned exceptions for genuinely open endpoints

Quick quiz

Keep learning

Controls this lesson covers

Azure API Management

Azure Logic Apps

Related compliance lessons