Tenant discovery is the step where a system determines which organisation a user intends to access after identity is proven. It may use a subdomain, invite link, domain mapping, or org picker. In SaaS, discovery is part of authorisation because the same user can belong to multiple tenants with different policies.
Expanded Definition
Tenant discovery is the authorisation-context step that determines which organisation, workspace, or account a proven user is trying to reach. It sits between identity proofing and tenant-specific policy enforcement, which means the same authenticated person can be directed into different control planes depending on the tenant resolved.
In SaaS and multi-tenant platforms, tenant discovery commonly uses a subdomain, invite link, domain mapping, email domain hinting, or an org picker. The key distinction is that it does not establish who the user is, but which tenant should govern the session after identity is accepted. That makes it closely related to onboarding and session routing, and it must align with tenant-scoped controls such as role assignment, data partitioning, and policy inheritance. Definitions vary across vendors, especially where discovery is blended with login UX or account selection, so security teams should treat it as an explicit trust decision rather than a convenience feature. NIST Cybersecurity Framework 2.0 is useful here because discovery affects access governance, identity verification, and protected asset selection, even when no single standard names the step directly.
The most common misapplication is treating tenant discovery as a harmless user-interface choice, which occurs when routing logic is allowed to select the wrong organisation before tenant-specific authorisation is enforced.
Examples and Use Cases
Implementing tenant discovery rigorously often introduces extra routing and validation logic, requiring organisations to weigh simpler user onboarding against stronger tenant isolation.
- A contractor signs in with a corporate email, but an org picker routes them into the client tenant they were invited to, not the contractor’s home workspace.
- A subdomain such as team.example.com resolves the tenant before session creation, reducing cross-tenant ambiguity in a multi-brand SaaS product.
- An invite link carries the tenant context needed to land the user in the correct workspace, which is especially important for Ultimate Guide to NHIs — Key Challenges and Risks scenarios where service accounts and automation may also be tenant-scoped.
- A platform uses domain mapping to suggest a default tenant, while still forcing the user to confirm the selection before privileges are issued.
- A security team validates discovery outcomes against NIST Cybersecurity Framework 2.0 functions so that routing decisions do not bypass access control reviews.
Tenant discovery also matters when organisations merge, share federated workspaces, or support external collaborators. In those cases, discovery logic has to distinguish identity from tenancy, and that separation becomes critical when one user belongs to more than one organisation. The NHI Lifecycle Management Guide is relevant because tenant assignment affects onboarding, rotation scope, and offboarding boundaries for non-human identities as well.
Why It Matters in NHI Security
Tenant discovery is a security boundary, not just a navigation step. If it is weak, attackers can exploit account confusion, invite reuse, stale domain mappings, or ambiguous org selection to land in the wrong tenant and inherit unintended permissions. For NHI programs, this is especially dangerous because service accounts, API keys, and automation identities are often provisioned per tenant and may be over-permissioned by default. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, which makes any tenant-resolution error more consequential once a session is established. When tenant discovery is mismanaged, offboarding can also fail cleanly, leaving identities attached to the wrong organisational boundary.
Controls should ensure that tenant resolution is explicit, logged, and validated against the authenticated principal, the expected domain, and the requested resource. The security team should review discovery outcomes alongside onboarding, federation, and entitlement management because the risk often hides in the first step of access, not in the credential itself. Organisations typically encounter tenant misrouting only after a cross-tenant access incident or a confused-deputy event, at which point tenant discovery becomes operationally unavoidable to address.
For a broader NHI risk baseline, see Top 10 NHI Issues and the Ultimate Guide to NHIs, both of which show how access ambiguity and poor lifecycle discipline compound tenant-level exposure.
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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Tenant discovery affects access control, identity binding, and authorized resource selection. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Tenant confusion can expose secrets and identities to the wrong organisational boundary. |
| NIST SP 800-63 | Digital identity guidance separates authentication of the user from application-specific access context. |
Validate tenant routing before access is granted and log each resolution decision for review.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
