Notifications
Clear all
Topic starter
20/08/2026 5:26 pm
TL;DR: Microsoft’s Get-FederationInformation change broke unauthenticated tenant enumeration through Autodiscover, but alternate endpoints and database-driven workarounds can still preserve the technique for offensive workflows, according to Sprocket Security. The deeper lesson is that identity discovery controls are often easier to bypass than they first appear, so exposure management has to account for fallback paths, not just the primary endpoint.
NHIMG editorial — based on content published by Sprocket Security: analysis of Microsoft’s Get-FederationInformation patch and tenant enumeration workarounds
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.
Questions worth separating out
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.
Q: Why do public identity metadata leaks matter if no credentials are exposed?
A: Because attackers do not need credentials to improve targeting.
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.
Practitioner guidance
- 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.
- Test for fallback enumeration routes Validate whether patched interfaces still leak the same information through adjacent endpoints, cached datasets, or alternate services.
- 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.
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
Microsoft’s tenant enumeration patch: what do teams do next?
Explore further
20/08/2026 6:15 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Tenant enumeration after Microsoft’s patch: what changed for practitioners
