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.
Expanded Definition
Tenant enumeration is the discovery of tenant-specific identifiers, domains, and naming patterns used by a cloud identity tenant. In NHI security, it matters because service endpoints, federation metadata, and DNS records can reveal enough structure for an attacker to map an organisation before any authentication attempt. That makes tenant enumeration different from credential theft: the exposure is not the secret itself, but the discoverability of the identity perimeter.
Definitions vary across vendors, especially when the term is used to include both passive discovery and active probing. NHI Management Group treats tenant enumeration as an exposure class within identity reconnaissance, closely related to how a tenant appears in metadata, login workflows, and federation responses. The control objective is to reduce the amount of tenant information that is publicly inferable, while recognising that some identity infrastructure will always disclose limited routing or branding details. For a general governance lens, the NIST Cybersecurity Framework 2.0 is useful for mapping discovery risk to asset visibility and protective controls.
The most common misapplication is assuming tenant names are harmless, which occurs when teams expose predictable domains, test endpoints, or federation metadata without reviewing what an unauthenticated observer can learn.
Examples and Use Cases
Implementing tenant visibility controls rigorously often introduces friction for legitimate users and integration teams, requiring organisations to weigh lower reconnaissance exposure against support complexity and federation usability.
- A security tester identifies a Microsoft tenant identifier through a public login page, then uses that identifier to search for related DNS naming patterns and subdomains.
- An attacker queries identity federation responses to confirm whether a target tenant uses a specific cloud directory, then tailors phishing or credential-stuffing attempts accordingly.
- A third-party application hardcodes tenant-specific URLs, making internal naming conventions visible in code, logs, and documentation.
- Blue teams validate tenant discovery exposure during threat modelling and compare findings with the controls described in the Ultimate Guide to NHIs, which emphasises visibility and governance for non-human identities.
- Defenders use passive recon techniques to understand what an unauthenticated user can infer before tightening login banners, metadata exposure, and tenant branding.
For a standards-oriented interpretation of what should be discoverable and monitorable, teams can align this work with the NIST Cybersecurity Framework 2.0 and its emphasis on asset identification and protective safeguards.
Why It Matters in NHI Security
Tenant enumeration becomes a real risk multiplier when service accounts, API keys, and federated workloads depend on identity infrastructure that can be mapped from the outside. Once an attacker knows the tenant naming scheme, they can focus social engineering, phishing, and password-spraying efforts on the correct identity plane instead of guessing blindly. That is especially important for NHI environments because machine identities often outnumber human identities by 25x to 50x, according to NHI Management Group’s Ultimate Guide to NHIs.
When tenant enumeration is ignored, defenders may miss the early stages of identity-centric attacks: discovery, targeting, and pretext building. It also complicates Zero Trust programs because the organisation cannot protect what outsiders can already map. The operational question is not whether a tenant can be perfectly hidden, but whether its public footprint reveals enough structure to accelerate compromise. In that sense, tenant enumeration belongs in the same governance conversation as identity exposure, secret hygiene, and access boundary design, as described in the broader NHI security guidance from Ultimate Guide to NHIs.
Organisations typically encounter the impact only after a phishing campaign, token abuse attempt, or federation recon incident confirms that the tenant was easier to map than expected, at which point tenant enumeration becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity exposure and recon paths are part of NHI attack surface management. |
| NIST CSF 2.0 | ID.AM-1 | Tenant discovery depends on knowing exposed identity assets and interfaces. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires controlling what identity boundaries expose to unauthenticated observers. |
Limit externally observable tenant metadata and segment identity services from broad exposure.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
