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

At a glance

What this is: This is an analysis of Microsoft’s tenant enumeration change and the workarounds that keep domain and tenant discovery viable.

Why it matters: It matters because identity and cloud teams need to understand how unauthenticated metadata exposure can still fuel reconnaissance against IAM, NHI, and federation estates.

By the numbers:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.
• The ratio of non-human to human identities now exceeds 100:1 in enterprise environments.

👉 Read Sprocket Security's analysis of Microsoft tenant enumeration after the Get-FederationInformation patch

Context

Tenant enumeration is an identity reconnaissance problem, not just a protocol quirk. When a service reveals verified domains, tenant names, or directory metadata without authentication, attackers can map the shape of a Microsoft 365 environment before they touch any high-value account or token.

For IAM teams, the issue is broader than one cmdlet or one SOAP endpoint. Exposure at the discovery layer can support phishing, user enumeration, infrastructure targeting, and downstream abuse of service accounts, federation trust, and cloud workload identities. That is why the fallback path matters as much as the patched path.

The article’s starting position is not atypical. Public cloud identity surfaces are often patched in one place while adjacent interfaces, cached datasets, and alternate lookups preserve the underlying intelligence value.

Key questions

Q: How do security teams reduce tenant enumeration risk in cloud identity environments?

A: Start by identifying every public endpoint that returns tenant, domain, or federation metadata, then remove or minimise the data each one discloses. Validate wrapper tools, alternate lookup services, and derived datasets as part of the same control boundary. If a patched interface still leaves the same intelligence available elsewhere, the risk remains.

Q: Why do public identity metadata leaks matter if no credentials are exposed?

A: Because attackers do not need credentials to improve targeting. Tenant names, verified domains, and realm information help them build phishing lists, map cloud namespaces, and prioritise follow-on attacks against users, service accounts, and federation trust. Metadata exposure often lowers the cost of the next attack stage.

Q: What do organisations get wrong about patching identity discovery flaws?

A: They often fix the first known endpoint and assume the technique is gone. In practice, attackers move to adjacent interfaces, alternate services, or large prebuilt datasets that recreate the same output. Effective remediation has to be surface-wide, not command-specific.

Q: How should defenders respond when a cloud identity lookup becomes a recon shortcut?

A: Treat it as an exposure-management problem, not a nuisance bug. Tighten the data returned by public endpoints, monitor for repeated domain queries, and validate whether the same information can be rebuilt indirectly. If so, close the indirect path as well before assuming the issue is contained.

Technical breakdown

How unauthenticated tenant enumeration worked through Autodiscover

The original technique relied on Exchange Online Autodiscover responding to GetFederationInformation requests with tenant-wide metadata. A single query could return verified domains, the tenant name, and related namespace details without authentication or meaningful rate limiting. That made the service valuable for reconnaissance because the output helped construct user enumeration targets and map the victim’s identity footprint before any interactive access occurred. The important point is that the weakness was not credential theft. It was unauthorized disclosure of identity metadata that reduced the attacker’s search space.

Practical implication: treat directory and tenant metadata as a security boundary and test unauthenticated discovery paths as part of exposure review.

Why the patch broke the command but not every underlying method

Microsoft changed the backend behavior so the service only returned information for explicitly provided domains. That removed the broad domain spill that the cmdlet and SOAP callers depended on. But patches rarely eliminate a reconnaissance objective if attackers can still obtain the same signal elsewhere. In this case, alternate endpoints, cached data sources, and derived databases can preserve tenant mapping even when the original route is closed. The control failure is usually scope, not existence: the organisation closes one door while leaving adjacent doors open.

Practical implication: validate that multiple discovery paths are closed, not just the first API or wrapper your team knows about.

Why fallback datasets matter in identity reconnaissance

Researchers can rebuild much of the same intelligence by correlating tenant IDs, domain records, and realm lookups across large datasets. This changes the defender’s task from blocking one query pattern to reducing the value of the underlying identity metadata itself. Once tenant identifiers and brand names are easy to correlate, adversaries can enrich phishing, targeting, and identity pivoting at scale. In identity security terms, this is a governance problem around metadata minimisation, not merely an API hardening problem.

Practical implication: reduce exposed identity metadata and review whether public endpoints reveal tenant structure that should not be queryable at scale.

Threat narrative

Attacker objective: The attacker wants a reliable map of tenant identity structure that improves targeting, reconnaissance, and subsequent access attempts.

1. Entry occurs through unauthenticated tenant and domain enumeration against public Microsoft identity endpoints and derived lookup sources.
2. Escalation happens when attackers correlate tenant IDs, brand names, and verified domains into a reusable target map for phishing and follow-on identity abuse.
3. Impact is improved targeting of Microsoft 365 environments, with faster user discovery and better preparation for credential attacks or federation abuse.

NHI Mgmt Group analysis

Identity metadata is part of the attack surface. Tenant names, verified domains, and realm data are not harmless convenience fields when they can be queried at scale without authentication. They become an intelligence layer for phishing, user discovery, and cloud targeting. The practical conclusion is simple: if public identity metadata increases attacker efficiency, it must be governed like any other exposure boundary.

Patch-and-pivot cycles are now the norm in cloud identity reconnaissance. Closing one endpoint rarely eliminates the technique because attackers can shift to alternate services, derived databases, or cached correlation sources. That means defender assumptions built around a single control point are too narrow. Practitioners should expect identity discovery to migrate rather than disappear.

Metadata minimisation is a governance control, not just a privacy preference. When large-scale correlation can reconstruct tenant structure from public endpoints, the issue extends into IAM, federation, and cloud account governance. This is where NIST SP 800-53 Rev 5 Security and Privacy Controls and Microsoft identity design choices intersect: reduce what unauthenticated callers can learn, then verify that adjacent interfaces do not leak the same signal.

Tenant enumeration creates downstream risk for NHI and agentic workflows too. Once attackers know tenant boundaries and naming patterns, they can target service accounts, API integrations, and cloud workflows with much higher precision. That matters because non-human identities often inherit the same directory structure and trust assumptions as human accounts. Practitioners should treat discovery exposure as an upstream risk multiplier for both IAM and NHI programmes.

Named concept: identity reconnaissance spillover. This is the pattern where one public lookup reveals enough information to reconstruct broader tenant structure through alternate endpoints or derived datasets. It matters because defenders may believe a single patch resolved the issue when in reality the intelligence simply moved. The right response is to map the whole discovery surface and then remove repeated data paths, not just one vulnerable call.

What this signals

Identity reconnaissance spillover: the main programme risk is not one broken endpoint, but the persistence of the same intelligence through alternate services and derived datasets. Teams should assume attackers will correlate public identity metadata even after a patch lands, which makes exposure review and metadata minimisation part of identity governance, not a separate hardening exercise.

Public cloud identity surfaces increasingly behave like distributed discovery systems. That means IAM and NHI teams need to think beyond account controls and assess what unauthenticated callers can infer about tenants, domains, trust relationships, and naming patterns. The more that public metadata can be rebuilt indirectly, the less value a point fix has in operational terms.

For practitioners

• Map every public identity discovery path Inventory Autodiscover, realm lookups, tenant resolution endpoints, and third-party reconstructions that disclose tenant names, verified domains, or directory hints. Include wrapper tools and alternate APIs in the review because attackers will use whichever path still returns useful metadata.
• Test for fallback enumeration routes Validate whether patched interfaces still leak the same information through adjacent endpoints, cached datasets, or alternate services. A control is incomplete if a different HTTP path, metadata service, or lookup source recreates the same reconnaissance value.
• Reduce identity metadata exposed to unauthenticated callers Remove unnecessary tenant branding, domain expansion, and realm details from public responses where possible, and verify that the remaining output cannot be correlated into a broader tenant map. Treat minimised disclosure as part of access control hygiene, not a cosmetic change.
• Reassess phishing and user-enumeration assumptions Assume that attackers may already know tenant naming conventions and verified domains before they start social engineering. Update detection, awareness, and login-protection logic so it does not rely on obscurity of the target tenant structure.

Key takeaways

• Tenant enumeration is an identity governance issue when public metadata can reveal tenant structure without authentication.
• Closing one lookup path is not enough if alternate endpoints or derived datasets preserve the same reconnaissance value.
• Practitioners should treat public identity metadata as an attack surface and test for spillover across adjacent services.

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.
• Identity Metadata: Identity metadata is the contextual information attached to a credential or account. It includes who created it, what system it belongs to, what it normally accesses, and how long it should exist. In NHI governance, metadata turns a valid secret into an understandable and governable identity.
• 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.
• Scope Minimisation: Scope minimisation is the practice of granting only the permissions needed for a specific task or transaction. For MCP and other non-human identities, it must be evaluated at the workflow level because agents can chain tool use quickly and expand exposure if granted broad scopes. The control reduces blast radius when a client is compromised.

What's in the full article

Sprocket Security's full analysis covers the operational detail this post intentionally leaves for the source:

• The exact Autodiscover and Get-FederationInformation request structure used in tenant enumeration workflows
• Practical integration notes for tooling that falls back to alternate Microsoft identity lookup paths
• The unauthenticated API design that preserves enumeration when the original method is patched
• Examples of how researchers are correlating tenant IDs and domain data into searchable datasets

👉 Sprocket Security's full post covers the Autodiscover mechanism, the fallback methods, and the API integration details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It gives identity and security practitioners a shared vocabulary for controlling exposure across human and non-human estates.