We value your privacy

We use cookies to analyse site traffic and improve your experience. You can accept all cookies or reject non-essential ones. See our Privacy Policy for details.

GR IT SERVICES
  • Contact
Get a quote
  2. Microsoft security
  3. Defender for APIs
Microsoft Defender for APIs, UAE

Which of your APIs are unauthenticated, and which have had no traffic for 30 days?

Defender for APIs answers both from observed traffic rather than from documentation. It marks endpoints inactive after 30 days without a call, and marks an API unauthenticated when none of the expected authentication mechanisms executed during the call.

Book an API security reviewSee what it finds
Microsoft Defender for APIs for UAE organisations
  • 30 daysWithout traffic before an endpoint is Inactive
  • OWASP API Top 10Covered by runtime threat detection
  • ObservedFindings come from traffic, not from specs
  • Azure APIMThe scope of the plan today
What Defender for APIs does

Eight things it tells you that documentation does not.

The value here is that everything is derived from actual traffic. An API inventory built from specifications describes intent. An inventory built from observed calls describes what is running, which is consistently a different list.

An inventory of what is actually published

A single dashboard with an aggregated view of all managed APIs, broken down by API collections, endpoints and Azure API Management services. For organisations where teams publish APIs independently, this is frequently the first complete list anybody has seen.

Which endpoints are unauthenticated, measured properly

It assesses authentication by verifying the presence of API Management subscription keys where subscription is required, and the execution of policies validating JWT, client certificates and Microsoft Entra tokens. If none of those executed during the call, the API is marked unauthenticated.

Which endpoints nobody is using

Endpoints that have received no API call traffic in the last 30 days are marked inactive, with a last called date in UTC. Unused APIs are pure attack surface with no offsetting benefit, and recommendations explicitly include disabling and removing them.

Which endpoints are exposed externally

An external traffic observed date shows when external API traffic was seen going to or from the endpoint. That distinguishes an API that is theoretically reachable from one that external parties are actually calling, which is a different risk conversation.

Which APIs handle sensitive data

API data classification classifies request and response bodies based on supported data types, to support risk prioritisation. An unauthenticated endpoint returning nothing sensitive and an unauthenticated endpoint returning personal data are the same finding until this classification separates them.

Runtime threat detection across the OWASP API Top 10

Ingested API traffic monitored with runtime anomaly detection using machine learning and rule-based analytics. Alerts cover the top ten OWASP API threats, data exfiltration, volumetric attacks, anomalous and suspicious API parameters, traffic and IP access anomalies, and usage patterns.

API risk in the wider attack path picture

With Defender CSPM enabled alongside, Cloud Security Graph analyses assets and connections to expose risks and possible lateral movement paths, and Cloud Security Explorer includes two built-in query templates for identifying risky API assets.

Findings where the people who own APIs already work

With the plan enabled, API security recommendations and alerts appear in the Azure API Management portal as well as in Defender for Cloud, and alerts export to SIEM systems such as Microsoft Sentinel. Findings that reach the API team without a portal switch get acted on more often.

How the findings are actually produced

Everything is derived from observed traffic, which is why the inventory surprises people.

That design decision explains both the strength of the findings and the one behaviour that confuses teams during onboarding.

  • Authentication is not read from a specification. It is assessed by verifying the presence of API Management subscription keys where a subscription is required, and the execution of policies validating JWT, client certificates and Microsoft Entra tokens. An API that documents authentication but does not execute it is marked unauthenticated.
  • Usage is measured the same way. Endpoints with no API call traffic in the last 30 days are marked inactive, with a last called date recorded in UTC, and external exposure is recorded as the date external traffic was actually observed rather than as a configuration property.
  • The behaviour that confuses people during onboarding follows from this: API endpoints that have not received any traffic since being onboarded display the status awaiting data. That is not an error and it is not a coverage gap, it is the plan waiting for a call to observe.
  • Practically, that means the value of the inventory grows over the first weeks. An assessment run the day after onboarding will show a lot of awaiting data. One run a month later shows which endpoints are used, by whom, from where, and whether authentication actually happened.
Ask us to run a 30 day API assessment
How we approach it

Four things that make an API programme produce change.

API findings are usually accurate and usually ignored, because they land on a security team with no authority over the code and no relationship with the developers who wrote it.

We let it observe before we report

Endpoints with no traffic since onboarding show as awaiting data, and inactive status needs 30 days without a call to be meaningful. An assessment run in week one produces an incomplete picture and an unnecessary argument. Waiting for the window is what makes the findings defensible.

We lead with unauthenticated endpoints, evidenced

The authentication assessment verifies whether subscription keys were present where required and whether policies validating JWT, client certificates or Entra tokens actually executed during the call. That is observed evidence rather than a configuration review, which is a much harder finding to dismiss.

We remove what nobody uses first

Disabling and removing unused APIs is one of the explicit recommendations, and it is the only security improvement that costs nothing and breaks nothing. Endpoints inactive for 30 days are the starting list, and it is usually longer than the owning team expects.

We put findings where the API owners already are

With the plan enabled, recommendations and alerts appear in the Azure API Management portal as well as in Defender for Cloud. Findings that reach a developer in the tool they already use get fixed. Findings in a security portal they do not have access to get discussed.

How an engagement runs

Four phases across roughly six weeks.

The observation period sets the timeline. Onboarding takes an afternoon, and the findings only become complete once traffic has been seen across a normal cycle of use.
  1. 01
    Week 1

    Onboard and start observing

    The plan enabled and APIs onboarded, either from the Defender for Cloud portal or from within the API Management instance. Expect a lot of awaiting data at this point, which is the plan working rather than a problem.

    • Plan enabled and APIs onboarded
    • API Management instances confirmed in scope
    • Baseline inventory captured
    • Recommendations to onboard remaining APIs actioned
  2. 02
    Weeks 2 to 4

    Let traffic accumulate, then read the findings

    Thirty days is the meaningful window, since that is the threshold for marking an endpoint inactive. During this period authentication status, external traffic and data classification all populate from real calls rather than from assumptions.

    • Unauthenticated endpoints identified from observed calls
    • Inactive endpoints identified after 30 days
    • Externally called endpoints listed
    • Sensitive data carrying APIs classified
  3. 03
    Week 5

    Act on the two easiest wins

    Unused APIs disabled and removed, which is recommended explicitly and reduces attack surface at no functional cost. Unauthenticated endpoints taken to their owning teams with evidence that no authentication mechanism executed during actual calls.

    • Unused APIs disabled or removed
    • Unauthenticated endpoints assigned to owners
    • Authentication remediation planned per API
    • Posture recommendations prioritised by data classification
  4. 04
    Week 6

    Wire detection into the response workflow

    Runtime alerts routed to whoever responds, exported into Sentinel or another SIEM where one exists, and recommendations surfaced in the API Management portal so the teams who own the APIs see them without switching tools.

    • Alerts exported to the SIEM
    • Recommendations visible in the API Management portal
    • Response owner named for API alerts
    • Recurring review scheduled for new APIs
Where this matters

Six situations where APIs are the weak point.

The common thread is an API estate that grew faster than the process for reviewing it, which is nearly universal in organisations doing anything digital.

A business exposing APIs to partners

Partner integrations accumulate, and each one is an authenticated channel until somebody publishes a version that is not. The external traffic observed date and the authentication status together answer whether any externally called endpoint is running without authentication actually executing.

A regulated firm with open banking or payment interfaces

Where APIs carry regulated data, data classification of request and response bodies is what allows risk to be prioritised properly. An unauthenticated endpoint carrying no sensitive data and one carrying customer records are very different findings, and the classification separates them.

A retailer whose mobile app is API driven

Consumer-facing APIs attract volumetric attacks, credential stuffing and parameter manipulation. Runtime detection covers volumetric attacks, anomalous and suspicious API parameters, and traffic and IP access anomalies, which are precisely the patterns that appear against a retail API.

An organisation that has never inventoried its APIs

The inventory is the first deliverable and frequently the most valuable. An aggregated view of all managed APIs broken down by collection, endpoint and API Management service tends to include endpoints nobody currently owns, which is a finding in itself.

A company with old APIs nobody retired

Versioned APIs accumulate because deprecating one requires knowing who still calls it. Thirty days of traffic data answers that question directly, and the recommendation to disable and remove unused APIs turns a difficult conversation into an evidenced one.

A business already running Defender CSPM

With both enabled, Cloud Security Graph analyses assets and connections to expose risks and possible lateral movement paths, and Cloud Security Explorer offers built-in query templates for risky API assets. APIs stop being a separate silo and become part of the same risk picture.

Three positions

How UAE organisations understand their API exposure.

The middle column is the common one and its weakness is specific: a penetration test is a point in time, and APIs change between tests more than almost anything else does.
Inventory from observed traffic
Continuous API monitoringYes
Periodic penetration testingAt test time
Documentation and trustNo
Unauthenticated endpoints found
Continuous API monitoringContinuously
Periodic penetration testingAt test time
Documentation and trustIf someone checks
Unused endpoints identified
Continuous API monitoringAfter 30 days without traffic
Periodic penetration testingRarely
Documentation and trustNo
External exposure observed
Continuous API monitoringYes, with dates
Periodic penetration testingInferred
Documentation and trustAssumed
Sensitive data carrying APIs known
Continuous API monitoringClassified
Periodic penetration testingSometimes
Documentation and trustNo
Runtime attacks detected
Continuous API monitoringYes, OWASP API Top 10
Periodic penetration testingNo
Documentation and trustNo
New APIs covered automatically
Continuous API monitoringOn onboarding
Periodic penetration testingNext test
Documentation and trustNo
Findings reach the API team
Continuous API monitoringIn the APIM portal
Periodic penetration testingIn a report
Documentation and trustNot applicable
Attack path context
Continuous API monitoringWith Defender CSPM
Periodic penetration testingNo
Documentation and trustNo
Effort per cycle
Continuous API monitoringLow
Periodic penetration testingHigh
Documentation and trustNone
Feature
Continuous API monitoring
Periodic penetration testing
Documentation and trust
Inventory from observed traffic
YesAt test timeNo
Unauthenticated endpoints found
ContinuouslyAt test timeIf someone checks
Unused endpoints identified
After 30 days without trafficRarelyNo
External exposure observed
Yes, with datesInferredAssumed
Sensitive data carrying APIs known
ClassifiedSometimesNo
Runtime attacks detected
Yes, OWASP API Top 10NoNo
New APIs covered automatically
On onboardingNext testNo
Findings reach the API team
In the APIM portalIn a reportNot applicable
Attack path context
With Defender CSPMNoNo
Effort per cycle
LowHighNone
What the dashboard tells you

Ten data points per endpoint, and what each is good for.

Each field answers a question that a security review would otherwise ask a development team to answer from memory.
Field or capabilityThe question it answers
Endpoint name and URL path with methodWhat exists, as defined in API Management
Last called date in UTCIs anything using this
30 days unused, marked InactiveCan this be removed
Authentication statusDid an authentication mechanism actually execute
External traffic observed dateIs this being called from outside
Data classificationDoes this carry sensitive data
Awaiting data statusNo traffic observed since onboarding
Security recommendationsWhat to fix, prioritised by risk
Runtime alertsIs this being attacked right now
Cloud Security Explorer templatesWhich API assets are risky, queried directly
How an engagement runs

Five steps, and one of them is waiting.

The observation window is not dead time. It is what converts an inventory of what exists into an inventory of what is used, by whom, and whether it authenticated them.
  1. 1

    Enable the plan and onboard the APIs

    Onboarding is available from the Defender for Cloud portal or from within the API Management instance in the Azure portal. Recommendations include onboarding APIs to the plan, which is a useful cross-check that nothing was missed.

  2. 2

    Allow at least 30 days of observation

    The inactive threshold is 30 days without traffic, and endpoints with no traffic since onboarding show as awaiting data. Reading the findings before that window has passed produces a picture that is technically accurate and practically misleading.

  3. 3

    Triage by authentication and data classification together

    Unauthenticated endpoints ranked by whether they carry sensitive data, using the classification of request and response bodies. That combination is what turns a list of findings into a priority order the business will accept.

  4. 4

    Remove the unused and fix the unauthenticated

    Disabling and removing unused APIs first, since it is recommended explicitly and carries no functional cost. Then authentication remediation with the owning teams, supported by evidence that no mechanism executed during real calls rather than by a configuration opinion.

  5. 5

    Connect detection to response

    Runtime alerts covering the OWASP API Top 10, data exfiltration, volumetric attacks and access anomalies routed to a named responder and exported to Sentinel or another SIEM, with recommendations surfaced in the API Management portal for the teams who own the code.

Straight answers

What organisations ask about Defender for APIs.

Microsoft states the plan currently provides security for APIs published in Azure API Management. Onboarding happens either in the Defender for Cloud portal or within the API Management instance in the Azure portal. APIs published outside API Management are not in scope of this plan.

From the call itself. It verifies the presence of API Management subscription keys for APIs or products where subscription is required, and the execution of policies validating JWT, client certificates and Microsoft Entra tokens. If none of those executed during the API call, the API is marked unauthenticated.

An endpoint that has received no API call traffic in the last 30 days. It is shown alongside a last called date in UTC. Recommendations explicitly include disabling and removing unused APIs, and inactive endpoints are the natural starting list for that.

Because no traffic has been observed since they were onboarded. It is not an error or a coverage gap. Findings here are derived from real calls rather than from specifications, so an endpoint nothing has called yet has nothing to report.

At least 30 days, because that is the window for the inactive determination and it is long enough for authentication, external traffic and data classification to populate from real usage. Reading the dashboard in week one gives an incomplete picture that tends to produce unnecessary arguments.

Runtime anomaly detection using machine learning and rule-based analytics, with alerts covering the top ten OWASP API threats, data exfiltration, volumetric attacks, anomalous and suspicious API parameters, traffic and IP access anomalies, and usage patterns.

Yes. API data classification classifies request and response bodies based on supported data types, specifically to support risk prioritisation. That is what lets you rank an unauthenticated endpoint carrying customer records above one carrying nothing sensitive.

They can. With the plan enabled you receive API security recommendations and alerts in the Azure API Management portal as well as in Defender for Cloud. That matters more than it sounds, because findings that reach people in the tool they already use get acted on.

Yes. Defender for Cloud alerts and recommendations can be exported into SIEM systems such as Microsoft Sentinel, for investigation within existing threat response workflows. For teams already operating a SIEM, that avoids creating a separate API alert queue nobody watches.

They complement each other. A penetration test is deep and point in time. This is continuous and observational, so it catches the endpoint published last Tuesday without authentication, which a quarterly test would not see for another two months.

Context. Cloud Security Graph analyses assets and connections across the organisation to expose risks, vulnerabilities and possible lateral movement paths, and Cloud Security Explorer includes two built-in query templates for identifying risky API assets. APIs become part of one risk picture rather than a separate list.

Removing unused APIs. It is an explicit recommendation, the inactive list gives you the candidates after 30 days, and it reduces attack surface without changing anything anybody depends on. It is also the finding least likely to be contested by a development team.

Onboarding is per API and there is a recommendation covering APIs that have not been onboarded to the plan, which acts as a useful cross-check. In practice the recommendation is what catches the ones somebody missed during the initial pass.

Then this plan does not cover them, since it currently provides security for APIs published in Azure API Management. That is worth establishing early, because an organisation whose critical APIs sit behind a different gateway needs a different approach rather than a partial one.

We scope by the number of API Management instances and APIs. The free first step: count how many APIs you publish, then ask which of them anybody has called in the last month. If those two numbers differ significantly, the inventory alone will be worth the exercise.

Recommendations to onboard APIs to the plan, to disable and remove unused APIs, and best practice recommendations for security, authentication and access control. The onboarding recommendation is quietly useful as a cross-check, because it catches the APIs somebody missed during the initial pass.

With Defender CSPM enabled alongside, yes. Cloud Security Explorer lets you query organisational information to locate, identify and remediate API assets, security issues and risks, and there are two built-in query templates available for identifying risky API assets with a single click.

It classifies API request and response bodies based on supported data types, specifically to support risk prioritisation. Without it, every unauthenticated endpoint looks the same. With it, the one returning sensitive data separates itself from the one returning a health check response.

Yes, and the external traffic observed date is what distinguishes them. An endpoint with no external traffic observed is being called internally only, which is a materially different risk position from one that external parties are actively calling, even though the configuration might look identical.

By combining two fields the dashboard already gives you. Authentication status tells you which endpoints have no authentication mechanism executing, and data classification tells you which carry sensitive data in their request or response bodies. The overlap of those two is the list worth acting on first.

It gives you the evidence to find an owner. An endpoint with a last called date, an external traffic observed date and a data classification is far easier to trace to a team than a name in a gateway configuration, because you can see who is calling it and what it returns.
API security review

Fifteen questions about your own API estate.

Most organisations cannot answer the first three from memory, and those three are exactly what an attacker establishes first.

Inventory

  • How many APIs do we publish?
    A number, from observation.
  • Which are called from outside?
    Observed, not configured.
  • Which had no traffic in 30 days?
    They are attack surface.
  • Are all API Management instances onboarded?
    There is a recommendation for this.
  • Who owns each API?
    Findings need an owner.

Authentication

  • Which endpoints are unauthenticated?
    Measured during real calls.
  • Do we require subscription keys?
    One of the mechanisms assessed.
  • Do we validate JWT in policy?
    Another assessed mechanism.
  • Do we use client certificates anywhere?
    Also assessed.
  • Do we validate Entra tokens?
    The fourth mechanism.

Risk and response

  • Which APIs carry sensitive data?
    Data classification shows this.
  • Is Defender CSPM enabled alongside?
    It adds attack path context.
  • Do alerts reach the SIEM?
    Export is supported.
  • Do API teams see the recommendations?
    They appear in the APIM portal.
  • Who responds to an API alert at night?
    Name them.
Related reading

The pages around this one.

Microsoft Defender for Cloud

The parent product and the other workload protection plans.

Learn more

Website security audit

The deeper, point in time assessment of a web application.

Learn more

Cloud security posture audit

Assessing configuration across the whole cloud estate.

Learn more
Next step

Count your published APIs, then count how many were called in the last month.

If those numbers differ, the difference is attack surface with no offsetting benefit. Removing it is the easiest security improvement available and nothing depends on it.

Book an API security reviewCall +971 56 613 2743

Related Services

Explore more solutions that work great with this service

Defender for Cloud

Azure posture, and the free tier almost nobody has enabled

Learn more

Website Security Audit

OWASP Top 10 2025, tested properly and retested

Learn more

Cloud Security Posture Audit

The real inventory, then configuration and identity

Learn more

Defender for Containers

Kubernetes posture, runtime and supply chain

Learn more

Defender EASM

Discovers internet-facing assets you never registered

Learn more

Azure Security Audit

Subscription audit, starting with the free tier you already own

Learn more

VAPT Testing

CREST-certified vulnerability assessment and penetration testing

Learn more

Microsoft Security Dubai

Entra, Defender, Purview, Sentinel, and what you already own

Learn more
GR IT SERVICES

Leading IT services provider in Dubai,
delivering enterprise-grade solutions
for businesses across the UAE.

Microsoft CSP PartnerCISGuard

Get the Helpdesk app

Raise and track IT tickets from your phone.

Download on the App StoreGet it on Google Play
Learn more about the app

Microsoft 365

  • Microsoft 365 Administration
  • M365 Reporting & Auditing
  • Microsoft 365 Licensing
  • Microsoft Copilot
  • Microsoft 365 Apps
  • Windows 365 Cloud PC
  • Microsoft SharePoint
  • Outlook & Exchange

Security

  • Microsoft Defender
  • Microsoft Purview
  • Microsoft Intune
  • Microsoft Entra
  • Compliance Manager
  • Cybersecurity Audits
  • Copilot for Security
  • Microsoft Sentinel
  • Microsoft Priva

Infrastructure

  • Google Workspace
  • Cloud Migration Services
  • Data Analytics & BI
  • Active Directory
  • Server Management
  • Apple Business
  • Apple Jamf Pro
  • IP Telephone
  • Data Backup
  • Website Development

IT Services

  • Managed IT Services
  • IT Support Dubai
  • IT AMC Dubai
  • New Office IT Setup
  • IT Relocation
  • Remote IT Support
  • On-Call IT Support
  • Startup IT Business Kit
  • Disaster Recovery & BC

Company

  • About Us
  • Careers
  • Contact
  • Blog

Contact

  • Iris Bay Tower, Office 903,
    Business Bay, Dubai, UAE
  • +971 56 613 2743
  • hello@gritservices.ae
  • gritservices.ae

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie Policy