Tenant enumeration after Microsoft’s patch: what changed for practitioners

At a glance

What this is: Microsoft’s Autodiscover patch closed one tenant-enumeration path, but Sprocket Security shows that alternate endpoints and offline domain-to-tenant datasets can still recover the same intelligence.

Why it matters: IAM and cloud security teams need to treat tenant discovery as a multi-path exposure problem, because closing a single endpoint does not eliminate enumeration if other lookup surfaces still exist.

Context

Tenant enumeration is the process of identifying the domains, tenant names, and related metadata tied to a Microsoft 365 environment. In practice, that information helps an operator build follow-on requests for user discovery, shared infrastructure mapping, and target validation.

The security gap is not the initial endpoint alone but the broader discovery surface around Microsoft identity services. When one lookup path is patched, researchers often move to alternate service endpoints, cached datasets, or derived tenant lookups, which means defenders have to think in terms of exposure paths rather than a single blocked request.

This is an identity-adjacent cloud security issue because tenant naming, domain association, and authentication metadata all feed later access and reconnaissance workflows. That makes it a practical governance problem for identity and cloud teams, not just an offensive tooling curiosity.

Key questions

Q: What breaks when Microsoft patches one tenant-enumeration endpoint but alternate lookup paths remain?

A: The primary break is false confidence. If tenant names, domain sets, or federation metadata are still recoverable through another resolver, the control only displaced the technique rather than eliminated it. Security teams should evaluate the whole discovery chain, because attackers need only one surviving path to rebuild the same target picture.

Q: Why does tenant enumeration still matter after a patch closes the obvious endpoint?

A: Because discovery is often a prerequisite for later targeting. If an attacker can still recover the tenant identifier or associated domains, they can build valid follow-on requests, map the environment, and narrow their next actions. Patching one surface helps, but it does not remove the value of the metadata itself.

Q: What signs suggest tenant discovery controls are failing in practice?

A: Look for repeated domain lookups, unusual use of identity discovery endpoints, and requests that probe multiple related domains in short bursts. Those patterns often indicate enumeration rather than legitimate sign-in activity. If a blocked path is being replaced by alternate resolvers, the control is failing at the workflow level, not just the endpoint level.

Q: How should teams respond when a tenant lookup technique is replaced by a fallback service?

A: Treat the fallback as part of the same exposure, not a separate issue. Remove or restrict redundant metadata returns, validate whether the alternative service exposes the same tenant intelligence, and reassess whether the original patch actually reduced attacker reach. Governance should follow the data, not the interface name.

Technical breakdown

How Get-FederationInformation exposed tenant metadata

The original technique relied on the Exchange Online Get-FederationInformation flow through the Autodiscover SOAP endpoint. A single unauthenticated POST could return the full domain set for a tenant, plus the short tenant name used in .onmicrosoft.com addresses. That combination mattered because it converted one known domain into a broader tenant profile that could then be used to construct further discovery requests. The control weakness was not encryption or transport, but unauthenticated metadata disclosure from a service that was never meant to expose the full tenant boundary to arbitrary callers.

Practical implication: Treat tenant metadata disclosure as an enumeration control issue and inventory every endpoint that can reveal domain or tenant identifiers.

Why the patch reduced one path but not the discovery problem

Microsoft’s change tightened the backend logic so the service only returned information for domains explicitly passed in the request. That closed the broad fan-out behaviour of the original Autodiscover response, but it did not remove the underlying need for tenant resolution in adjacent Microsoft services. When an attacker can still derive tenant IDs or query alternate identity surfaces, the security outcome is reduced convenience, not complete prevention. In other words, the patch changed one resolver, while the overall discovery ecosystem remained available through other methods.

Practical implication: Assess tenant enumeration as a chain of lookup mechanisms, not a single cmdlet or SOAP call.

Why fallback datasets and alternate interfaces keep enumeration alive

The article shows two fallback patterns. First, an alternate interface can proxy the same discovery logic behind a different web front end. Second, large offline datasets can correlate domains, tenant IDs, and organization names at scale, letting operators recover the same intelligence without hitting the primary service repeatedly. Both patterns separate the operator from the original endpoint and make patching slower to fully extinguish. That is why discovery controls in cloud identity systems often degrade into a cat-and-mouse problem unless the surrounding metadata surfaces are also reduced.

Practical implication: Assume an exposed lookup surface will be mirrored elsewhere unless you also remove the supporting metadata paths.

Threat narrative

Attacker objective: The objective is to preserve tenant discovery for downstream targeting, user enumeration, and infrastructure mapping even when the primary Microsoft path is blocked.

1. Entry begins with unauthenticated queries to Microsoft Autodiscover or an alternate tenant-lookup surface that accepts a domain name and returns identity metadata.
2. Credential access is not the objective here, but the disclosed tenant name and domain set enable follow-on discovery that supports later authentication targeting and infrastructure mapping.
3. Impact is the recovery of tenant identifiers and federated domains at scale, which preserves offensive reconnaissance even after the original path is patched.

Breaches seen in the wild

• OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Tenant discovery controls fail when they are treated as single-endpoint problems. The article shows a classic control displacement pattern: Microsoft constrained one Autodiscover behaviour, yet alternate interfaces and offline datasets still let operators reconstruct the same tenant intelligence. That means the real governance unit is the full metadata surface, not the individual request path. Practitioners should treat tenant enumeration as an exposure class, not a one-off bug fix.

Discovery resilience is now part of identity security, not just offensive tooling. Once tenant names, federated domains, and organisation labels can be correlated outside the primary service, patching becomes a temporary friction control rather than a durable boundary. That is especially relevant for IAM teams because identity metadata is often reused across onboarding, admin workflows, and cloud access design. The practical conclusion is that discovery reduction has to be built into the identity architecture, not bolted onto one product surface.

Fallback logic creates a long tail of residual risk. The article’s most important lesson is that if one resolver dies, a motivated operator will move to a second resolver, a cached database, or a proxy service. This is the same governance pattern seen in other identity-adjacent exposures: the control exists, but the surrounding ecosystem still leaks enough information to reconstruct the target. Security teams should assume residual discoverability will persist unless they map every path that returns tenant metadata.

Tenant-name leakage is a named exposure worth tracking explicitly. The short tenant identifier is not just a convenience field, because it enables follow-on URL construction and broader service enumeration. Once that identifier is available through more than one channel, defenders have a verification problem rather than a block-all problem. The right response is to measure where tenant identity data can be derived, then reduce the number of places that can answer the same question.

Cloud identity governance needs to account for attacker workflow continuity. Even when one request shape is patched, operators can preserve workflows by abstracting the method behind a new interface or a lookup corpus. That creates a practical lesson for IAM and cloud teams: governance must assume the attacker will change transport, not goal. The control target is therefore the reusable discovery capability, not the specific cmdlet or endpoint.

What this signals

Tenant metadata has become a control-plane asset. Once tenant names and domain associations can be recovered from more than one route, discovery becomes resilient by default. Security teams should therefore measure the number of ways a tenant can be resolved, not just whether one endpoint is patched.

The practical problem for defenders is that lookup techniques are now easy to abstract behind other services or offline datasets. That makes one-off fixes insufficient unless identity teams can also reduce identifier reuse across Microsoft 365 discovery surfaces.

For practitioners

• Map every tenant metadata surface Inventory Autodiscover, OIDC discovery, user-realm lookups, and any other Microsoft identity endpoints that return tenant names, domain sets, or federation details.
• Reduce identifier reuse across workflows Limit where tenant names and verified domains are exposed in documentation, tooling, and automation so one lookup does not cascade into later enumeration steps.
• Test fallback enumeration paths Validate whether alternate endpoints, cached datasets, or proxy services can still recover tenant metadata after the primary path is blocked.
• Instrument for repeated lookup behaviour Watch for bursty, repeated tenant-resolution requests and cross-domain probing that indicate enumeration rather than normal authentication traffic.

Key takeaways

• Microsoft’s patch reduced one unauthenticated tenant-enumeration path, but it did not eliminate the broader discovery problem because alternate resolvers still exist.
• The real control gap is not a single endpoint, but the full metadata surface that exposes tenant names, domain sets, and federation details.
• Teams need to inventory all tenant-resolution paths and test whether fallback services can still reconstruct the same target intelligence.

Key terms

• Tenant enumeration: Tenant enumeration is the process of discovering domains, tenant identifiers, and naming conventions associated with a cloud identity tenant. In Microsoft environments, it can be supported by public metadata, DNS records, and identity federation responses, even when no authentication is required.
• Autodiscover: Autodiscover is the configuration mechanism that helps email clients find the correct Exchange settings for a mailbox. During tenant migration it can keep pointing clients to the old environment, which is why cached settings often need to be refreshed after cutover.
• Federation metadata: Federation metadata is the signed information that tells other parties how an identity or application should be trusted. In NHI governance, it becomes a control surface because issuer values, claim rules, and entity details determine whether registration and authentication behave correctly.
• Discovery surface: A discovery surface is any public endpoint, record, or metadata source that reveals identity structure useful to an attacker or analyst. In identity programmes, these surfaces matter because they can expose relationships, naming patterns, or tenant boundaries before any authentication occurs.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is a useful next step for practitioners who need to connect identity governance to access design, lifecycle control, and exposure management.