Microsoft tenant enumeration is ending, but domain discovery remains

At a glance

What this is: This is an analysis of how Microsoft tenant discovery changed after ACS and Autodiscover patching, and why full tenant domain enumeration is no longer available through a single unauthenticated request.

Why it matters: It matters because identity reconnaissance still feeds phishing, tenant mapping, and follow-on M365 tooling, so teams need to understand which discovery paths remain and which assumptions have been removed.

Context

The core governance gap is that identity discovery no longer fits the old model of one unauthenticated endpoint returning all tenant domains at once. Microsoft has closed the main ACS and Autodiscover paths, but the remaining signals are distributed across DNS, OpenID configuration, and authenticated Graph lookups, which makes tenant discovery a multi-surface problem.

For identity teams, that shift matters because the useful asset is not just the tenant ID. The MOERA prefix and related domains still support downstream reconnaissance and tooling, but they now require correlation rather than a single lookup. That changes how both defenders and red teams should think about exposure, detection, and enumeration coverage.

Key questions

Q: What breaks when unauthenticated Microsoft tenant enumeration is patched?

A: What breaks is the single-request workflow that returned every verified domain in a tenant. Defenders should assume the full enumeration primitive is gone, but not the underlying reconnaissance need. Attackers can still reconstruct useful tenant intelligence from smaller signals, so the control boundary shifts from blocking one endpoint to reducing how much identity data each surface reveals.

Q: Why do tenant IDs and MOERA prefixes still matter after patching?

A: Tenant IDs and MOERA prefixes still matter because they are the keys that make downstream Microsoft 365 discovery useful. With them, tools can target SharePoint, OneDrive, and related identity services more accurately. The security issue is not just exposure of a name, but exposure of a usable naming convention that supports follow-on enumeration.

Q: How can security teams tell whether identity discovery is still leaking?

A: Look for exposed DKIM CNAMEs, predictable MX answers, tenant ID resolution through public OpenID endpoints, and repeated authenticated or unauthenticated lookup activity across Microsoft identity surfaces. If these signals can be correlated into tenant naming and related-domain discovery, the environment is still leaking useful reconnaissance data even without the old ACS endpoint.

Q: When should teams treat a lookup API as a reconnaissance risk?

A: Treat a lookup API as a reconnaissance risk whenever it can be used to resolve tenant information, cross-tenant relationships, or naming data at scale. Even authenticated APIs can support abuse if permissions are broad, automation is easy, and the output materially helps tenant mapping or phishing preparation.

Technical breakdown

Why the old ACS metadata path mattered

The ACS metadata endpoint exposed allowedAudiences, which is a trust configuration list rather than a directory feature. In practice, that meant a single unauthenticated request could return the tenant’s verified domains and the initial onmicrosoft.com prefix, because the response reflected federation plumbing that was never designed as a discovery boundary. Once Microsoft patched that path, the leakage did not disappear conceptually. It simply stopped being accessible through one request, forcing discovery to move to other identity surfaces.

Practical implication: Treat federation metadata as a potential disclosure surface, not just an authentication component.

How domain discovery now shifts to DNS and OpenID

With the direct endpoint closed, the remaining approach is correlation. OpenID configuration can still reveal tenant IDs for known domains, DKIM CNAMEs can expose the MOERA prefix when present, and MX records can help validate guessed tenant names. None of these alone reproduces the old full-list response, but together they reconstruct much of the same intelligence. The difference is operational: discovery becomes probabilistic and distributed instead of deterministic and centralized.

Practical implication: Map which public records in your environment leak tenant identity fragments and monitor them as exposure points.

Why authenticated Graph lookup remains a fallback

When DNS-based discovery fails, the Graph API path fills the gap if an authenticated caller has the right permission. That changes the model from unauthenticated enumeration to controlled cross-tenant information access, but the output still supports tenant naming and domain correlation. From an identity-governance perspective, the important distinction is not whether the lookup is authenticated, but whether the permission boundary is narrow enough to prevent broad reconnaissance at scale.

Practical implication: Review cross-tenant Graph permissions as reconnaissance-enabling access, not just integration access.

Threat narrative

Attacker objective: The attacker wants to turn partial identity signals into a usable map of Microsoft tenant structure, domains, and naming conventions for downstream abuse.

1. Entry occurs through publicly reachable identity surfaces such as ACS metadata, Autodiscover federation queries, DNS records, OpenID configuration, or Graph lookup permissions.
2. Credential access is replaced by identity intelligence access, where the attacker harvests tenant IDs, MOERA prefixes, and domain relationships from responses or lookup results.
3. Escalation happens when those fragments are combined into tenant mapping, tool targeting, and follow-on discovery against SharePoint, OneDrive, and related Microsoft 365 services.
4. Impact is broader reconnaissance coverage with less guessing, which improves phishing targeting, tenant correlation, and M365 offensive automation.

NHI Mgmt Group analysis

Tenant discovery has become a correlation problem, not a single-endpoint problem. The old model assumed one unauthenticated request could disclose the tenant’s domain surface. That assumption is gone, but the operational value of tenant intelligence remains because the fragments still exist across DNS, OpenID, and authenticated directory queries. Practitioners should now think in terms of distributed identity exposure rather than endpoint hardening alone.

Identity discovery still leaks through control planes that were never meant to be discovery tools. DNS records, federation metadata, and tenant lookup APIs all carry identity state because they support legitimate platform functions. The risk is not that each surface returns the full picture, but that enough small exposures can be stitched together into a complete one. The practical conclusion is that discovery governance must span public records, federation endpoints, and permissioned lookup paths.

MOERA prefix exposure remains a high-value recon primitive. The tenant’s initial onmicrosoft.com prefix is operationally more useful than brand names because it supports SharePoint, OneDrive, and MDI targeting. That means identity security teams need to treat tenant naming intelligence as an asset class with its own exposure chain. The practitioner takeaway is to understand where naming information can still be derived, not just where full enumeration used to happen.

Authenticated fallback paths do not eliminate reconnaissance risk. Graph-based tenant information lookup is not a bug in the same sense as a leaked unauthenticated endpoint, but it still creates a discovery capability that can be abused when permissions are broader than intended. This is a reminder that identity governance has to cover both public disclosure and authorized reconnaissance. The practitioner implication is to scope cross-tenant read permissions as tightly as any other sensitive access.

Domain enumeration controls are drifting from prevention to detection and correlation. Microsoft has removed the highest-yield unauthenticated path, but the remaining techniques show that identity exposure now emerges from combinations of low-signal sources. That makes detection logic, inventory quality, and permission review more important than chasing a single broken endpoint. The practical conclusion is to govern discovery as an exposure pattern across the whole identity stack.

What this signals

Tenant discovery is now an exposure correlation problem. Public identity surfaces no longer hand over a complete tenant map in one request, but they still leak enough fragments to support reconnaissance when DNS, federation, and directory signals are combined. Teams need to assess these surfaces together, not as isolated configuration points.

MOERA naming remains the operational pivot. The tenant’s initial onmicrosoft.com prefix is still the most useful artifact for SharePoint, OneDrive, and Microsoft 365 follow-on discovery. That makes tenant naming information part of the identity attack surface, not just a branding detail.

Authenticated lookup is still reconnaissance if the permission is too broad. Cross-tenant read access can become a discovery channel when it exposes tenant metadata at scale. The governance question is whether the permission model is constrained enough to stop routine automation from becoming tenant mapping.

For practitioners

• Audit public identity disclosure surfaces Inventory DNS, DKIM, OpenID configuration, federation metadata, and related Microsoft 365 endpoints that can reveal tenant identity fragments or naming conventions.
• Review cross-tenant lookup permissions Limit permissions such as CrossTenantInformation.ReadBasic.All to the smallest set of approved applications and monitor any usage patterns that resemble broad tenant reconnaissance.
• Validate tenant-name exposure paths Check whether your organization still publishes DKIM CNAMEs, MX records, or other records that can reveal the MOERA prefix or related domains.
• Tune detection for recon stitching Correlate repeated tenant lookups, federation queries, and DNS probing so that fragmented identity discovery attempts can be detected even when no single request is suspicious.

Key takeaways

• Microsoft has removed the highest-yield unauthenticated tenant enumeration paths, but identity discovery has not disappeared, it has fragmented across public records and lookup services.
• MOERA prefixes and related domains remain operationally valuable because they support Microsoft 365 targeting even when full domain lists are no longer available in one response.
• The right control response is to govern identity disclosure across DNS, federation, and cross-tenant lookup permissions as one exposure surface.

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.
• MOERA: MOERA stands for Microsoft Online Email Routing Address. It is the tenant’s initial onmicrosoft.com domain prefix, which remains stable and is operationally useful because it supports downstream Microsoft 365 service discovery and tooling, even when brand names differ from the actual routing prefix.
• 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.
• Cross-tenant Lookup Permission: Cross-tenant lookup permission is an authenticated privilege that allows one tenant or application to query information about another tenant. It becomes a reconnaissance concern when the returned data can be used to map identities, naming conventions, or related domains at scale.

Deepen your knowledge

Identity lifecycle management, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.