They should stop focusing on the retired endpoint and inventory every public surface that can still reveal tenant IDs, MOERA prefixes, or verified domains. Discovery often survives through combinations of DNS, OpenID, federation metadata, and mail configuration, so the control objective is reducing recoverable identity topology across the whole ecosystem, not just one API.
Why This Matters for Security Teams
Patched tenant enumeration endpoints rarely remove the underlying exposure. If tenant IDs, MOERA prefixes, verified domains, OpenID configuration, federation metadata, or mail records still reveal identity topology, attackers can keep mapping the environment and pivot to account discovery, phishing, or targeted abuse. That is a visibility problem, not just an API problem. The right lens is the one used in NIST Cybersecurity Framework 2.0: reduce exposure, verify what remains public, and continuously monitor externally reachable identity signals.
This is especially important because identity clues often survive in places teams do not treat as inventory sources. The Ultimate Guide to NHIs — Key Research and Survey Results shows only 5.7% of organisations have full visibility into their service accounts, which reflects the broader problem of incomplete identity surface mapping. In practice, many security teams encounter tenant discovery only after a third party, scanner, or attacker has already correlated several low-signal metadata points into a usable tenant profile.
How It Works in Practice
Security teams should treat tenant discovery as an ecosystem-level exposure review. Start by enumerating every public source that can reveal tenant identity or tenant-adjacent metadata, then remove, obscure, or standardise what is not operationally required. That includes DNS records, OpenID discovery documents, SAML or federation metadata, MX and mail routing data, application error messages, and any public directory or domain verification response. The objective is not to eliminate all metadata, but to reduce recoverable identity topology.
A practical workflow usually looks like this:
- Inventory all externally reachable identity surfaces, not just the retired endpoint.
- Test whether tenant IDs, domain aliases, or MOERA-style prefixes can still be correlated across services.
- Validate whether OpenID, federation, or mail configuration leaks stable identifiers.
- Decide which responses should be generic, rate-limited, or access-controlled.
- Track findings as exposure management issues, not only as application bugs.
For control design, use the same discovery mindset reflected in the State of Non-Human Identity Security: visibility gaps and overexposed identity artifacts tend to persist because teams focus on single fixes instead of the broader identity graph. Map the findings to external attack surface review, least privilege, and continuous validation. Public metadata should be assumed reusable by an attacker unless proven otherwise, and regression tests should be added whenever identity, mail, or federation settings change. These controls tend to break down in federated, multi-tenant, and acquisition-heavy environments because different teams own different metadata surfaces and no single change process covers them all.
Common Variations and Edge Cases
Tighter metadata suppression often increases operational overhead, requiring organisations to balance discovery resistance against supportability, partner onboarding, and troubleshooting. That tradeoff is real, especially when identity teams depend on vendor-managed federation or mail routing features that expose some tenant characteristics by design.
Current guidance suggests using a risk-based approach rather than trying to hide every trace of tenancy. Public-facing SaaS, customer portals, and B2B federation flows may legitimately disclose certain domains or issuer details, but there is no universal standard for how much is acceptable. Where disclosure is required, minimise what is returned, avoid stable identifiers where possible, and ensure the remaining metadata cannot be chained into a complete tenant profile.
Two edge cases matter most. First, if the retired endpoint is gone but cached documentation, DNS history, or onboarding emails still reveal tenant data, the exposure persists outside application control. Second, if verified domains are shared across subsidiaries or regions, discovery becomes easier because the same identifiers can be correlated in multiple contexts. That is why identity exposure reviews should be repeated after mergers, domain changes, and SSO migrations, not only after a security incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity discovery and exposure reduction are central when tenant metadata remains public. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access minimisation reduce the value of recoverable tenant topology. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust reduces reliance on obscurity and assumes discovery will occur. |
| NIST AI RMF | Risk mapping is needed to evaluate identity exposure across many public surfaces. | |
| CSA MAESTRO | GOV-03 | Agentic and automated workflows often reveal metadata through multiple integrated surfaces. |
Inventory every exposed NHI-related identifier and remove or constrain any public metadata that enables tenant discovery.
