Notifications
Clear all
Topic starter
18/08/2026 2:23 pm
TL;DR: Microsoft has patched the main unauthenticated paths for tenant domain enumeration, including the ACS metadata endpoint and Autodiscover federation queries, but practitioners can still recover tenant IDs, MOERA prefixes, and related domains through DNS, Graph, and OpenID-based techniques according to Sprocket Security. The real issue is that identity discovery has shifted from single-request enumeration to fragmented recon across multiple identity surfaces, which raises the bar for both defenders and offensive tooling.
NHIMG editorial — based on content published by Sprocket Security: LLMjacking-related tenant discovery and the updated azmap.dev workflow
By the numbers:
- The scan indexed over 600 million domains against Microsoft ODC provider endpoints.
Questions worth separating out
A: They should stop focusing on the retired endpoint and inventory every public surface that can still reveal tenant IDs, MOERA prefixes, or verified domains.
Q: Why does tenant name exposure still matter after unauthenticated enumeration is removed?
A: Because many recon workflows need the tenant’s MOERA prefix to build downstream URLs, validate domain guesses, or locate related Microsoft services.
A: Look for whether public records can be combined into a complete tenant map in a few steps.
Practitioner guidance
- Inventory identity discovery surfaces Map every endpoint, DNS record, and mail-authentication artifact that can reveal tenant IDs, MOERA prefixes, or related domains.
- Classify public metadata as recon risk Treat tenant identifiers, verified domain lists, and branding values as security-sensitive metadata when they can be combined into usable enumeration paths.
- Review mail and federation configuration together Check whether DKIM, Autodiscover, and Graph-related configuration can still be chained into a tenant discovery workflow.
What's in the full article
Sprocket Security's full blog post covers the operational detail this analysis intentionally leaves for the source:
- Step-by-step examples of the original ACS metadata technique and the exact responses it returned.
- Working command-line queries for DKIM, MX brute-force, OpenID configuration, and Graph-based tenant discovery.
- The full azmap.dev workflow for caching, correlating, and refreshing tenant-domain mappings at scale.
- Practical notes on where the patched paths failed first and which Microsoft hostnames lagged behind the rollout.
👉 Read Sprocket Security's analysis of Microsoft tenant enumeration and azmap.dev →
Azure tenant discovery after ACS patching: what still works?
Explore further
18/08/2026 3:14 pm
Identity discovery is now a distributed control problem, not a single-endpoint problem. Closing one unauthenticated path does not eliminate discovery if other identity-adjacent systems still expose tenant IDs, naming clues, or related domains. The practical lesson is that IAM governance has to account for the full exposure map across OpenID, DNS, mail authentication, and federation metadata. Practitioners should treat discovery as a surface area to reduce, not a single setting to fix.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- 85% lack of visibility is a governance signal, not just a monitoring gap, because identity exposure often sits outside the primary IAM console.
A question worth separating out:
Q: What is the difference between fixing one identity endpoint and fixing discovery risk?
A: Fixing one endpoint removes a single route, while fixing discovery risk requires reducing the usefulness of all publicly reachable identity clues. Tenant IDs, mail-authentication records, federation outputs, and branding data can each contribute part of the picture, so the programme has to govern the whole set.
👉 Read our full editorial: Microsoft tenant enumeration is ending, but domain discovery remains
