Skip to main content
Identity Authority
Category: Cloud Identity

Tenant

Simply put

In identity and access management, a tenant is a distinct, logically isolated space within a shared system that belongs to a single organization or customer. It keeps one organization's users, data, and settings separate from those of other organizations that use the same underlying platform. This concept is different from the everyday legal meaning of a tenant as someone who rents property from a landlord.

Formal definition

The evidence packet provided defines 'tenant' only in its real-property legal sense (a person or entity who temporarily occupies or possesses real estate belonging to a landlord under a lease), and contains no source material describing the IAM meaning of the term. In IAM practice, a tenant typically denotes a logically isolated administrative and data boundary within a multi-tenant identity platform, scoping a customer's or organization's directory, users, policies, and configuration; however, the specific technical characteristics of tenant isolation cannot be substantiated from the sources provided here and are noted as out of scope for this evidence set.

Why it matters

In multi-tenant identity platforms, the tenant boundary is the primary line separating one organization's users, data, and configuration from another's. When many customers share the same underlying identity infrastructure, the integrity of that logical isolation directly determines whether a misconfiguration or defect in one organization's space can expose or affect another's directory, policies, or credentials. For security architects and IGA leads, understanding what a tenant scopes is foundational to reasoning about blast radius and containment.

Because the tenant is often the top-level container for an organization's directory, users, policies, and settings, administrative and governance decisions are typically made within its boundary. Access reviews, provisioning, and policy administration are generally scoped to a tenant, so treating the tenant as the authoritative boundary matters for both runtime enforcement and lifecycle governance. Conflating tenants, or failing to enforce their separation, can undermine assumptions that downstream controls depend on.

It is worth flagging that the evidence set provided here defines 'tenant' only in its real-property legal sense and contains no source material substantiating the specific technical characteristics of tenant isolation in IAM platforms. Readers should therefore treat the IAM description here as a general characterization and consult vendor and standard documentation for the isolation guarantees of any particular platform.

Who it's relevant to

Security Architects
Architects rely on the tenant as a logical isolation boundary when reasoning about how one organization's users, data, and settings remain separate from others on a shared platform. This informs threat modeling and containment assumptions, though the specific isolation guarantees depend on the platform and are out of scope for this evidence set.
Identity Governance and Administration Leads
Because provisioning, access reviews, and policy administration are typically scoped to a tenant, IGA leads treat the tenant as the container within which lifecycle and certification activities are organized for a given organization.
System Administrators
Administrators configure a tenant's directory, users, and settings within its isolated space, managing one organization's configuration without affecting other organizations that share the same underlying platform.
Compliance Officers
Compliance and audit stakeholders care that a tenant maintains a distinct boundary for an organization's data and users, since that separation underpins claims about who can access what within a shared identity platform. The precise technical basis for isolation should be verified against platform documentation.

Inside Tenant

Isolation boundary
A tenant defines a logical separation boundary within a multi-tenant system, keeping one customer's or organization's identities, configurations, and data segregated from those of other tenants sharing the same underlying infrastructure.
Identity population
The set of principals (users, service accounts, and other identities) that belong to and are managed within the scope of a single tenant, typically backed by a tenant-scoped directory or user store.
Tenant-scoped configuration
Settings such as authentication policies, MFA requirements, federation and SSO connections, and branding that apply only within the boundary of that tenant, depending on the platform's configuration model.
Administrative delegation
Tenant-level administrative roles and permissions that let designated administrators manage the tenant's identities, access policies, and configuration without granting authority over other tenants.
Tenant identifier
A unique identifier (often surfaced as a claim in issued tokens or as part of an issuer value) that associates authentication and authorization events with a specific tenant, allowing the system to resolve which tenant context a request belongs to.

Common questions

Answers to the questions practitioners most commonly ask about Tenant.

Does a tenant boundary by itself guarantee that one tenant's data is inaccessible to another?
Not inherently. A tenant is a logical isolation construct, but the strength of isolation depends on how it is implemented. Depending on the deployment model, tenants may share underlying infrastructure, databases, or even table rows distinguished only by a tenant identifier. Effective isolation typically requires enforcement at multiple layers, including authentication scoping, authorization checks that always evaluate the tenant context, and data-layer partitioning. Treating the tenant label as a self-enforcing security boundary, rather than as a context that policies and controls must consistently apply, is a common source of cross-tenant access flaws.
Is a tenant the same thing as an organization, a customer, or a directory?
Not necessarily. A tenant is an administrative and isolation boundary within a system, and it may or may not map one-to-one to a real-world organization or customer. In some deployments a single customer operates multiple tenants (for example, separating production from test), and in others multiple business units share one tenant. A tenant may be backed by a directory but is a broader concept than the directory itself; it also encompasses configuration, policies, and administrative scope. The precise relationship depends on vendor terminology and deployment design.
How is the tenant context typically determined during authentication and token issuance?
In most deployments the tenant is resolved before or during authentication, often from the sign-in domain, a URL path or subdomain, a discovery step, or the identity provider associated with the user. Once resolved, the tenant identifier is typically carried forward as a claim in the issued token so that downstream authorization can evaluate requests within the correct tenant scope. The exact mechanism and the specific claim name vary by vendor and by the standard profile in use, such as OIDC or SAML 2.0.
How should authorization decisions account for tenant boundaries at runtime?
Authorization should treat the tenant as a mandatory part of the decision context rather than an optional filter. In a PDP/PEP model, the tenant identifier is typically provided as an attribute the policy decision point evaluates alongside subject, resource, and action, and the policy enforcement point should reject requests whose token tenant context does not match the requested resource's tenant. This is distinct from identification and authentication; verifying the principal does not by itself confine that principal to a single tenant, so tenant scoping must be enforced explicitly in policy.
What are the common approaches to modeling roles and entitlements across multiple tenants?
Approaches vary by product. Some designs scope roles entirely within a tenant so that an RBAC assignment has no meaning outside it, while others support cross-tenant or provider-level administrative roles for operators who manage many tenants. ABAC or PBAC models may incorporate the tenant as an attribute in policy conditions. Segregation of duties and access certification, which are IGA concerns, are typically evaluated within a tenant's scope, though multi-tenant governance may require aggregating reviews across tenants. The specific capabilities depend on the vendor and configuration.
How does provisioning to a multi-tenant system typically handle tenant assignment?
When provisioning via SCIM or a similar mechanism, the target tenant is generally established by the endpoint, credentials, or configuration used for that provisioning connection, so each tenant is often served by its own provisioning target or scoped credential. Attributes and group or role assignments created through provisioning are then interpreted within that tenant's boundary. Whether a single provisioning integration can span multiple tenants depends on the provider's SCIM implementation and administrative model, so this should be confirmed against the specific vendor's documentation rather than assumed.

Common misconceptions

A tenant is the same thing as a single organization or company.
A tenant is a logical boundary within a platform, not necessarily a one-to-one mapping to a legal organization. Depending on deployment, one organization may operate multiple tenants (for example separate production and test tenants), or a tenant may represent a subdivision, so the mapping varies by design.
Tenant isolation guarantees complete physical separation of data and compute.
In most multi-tenant deployments, isolation is a logical boundary enforced by the platform rather than dedicated physical infrastructure per tenant. The strength and nature of isolation depends on the vendor's architecture and configuration, and shared infrastructure is common.
Belonging to a tenant is what determines what a principal is allowed to do.
Tenant membership scopes which identities and configurations apply, but it is not itself authorization. What a principal may do is determined separately by the access control model (such as RBAC or ABAC) and enforced at runtime; tenancy establishes context, not entitlements.

Best practices

Treat the tenant identifier as a security-relevant value: validate the tenant context (for example the issuer or tenant claim) during token validation so requests are only honored within the intended tenant boundary.
Scope administrative roles to individual tenants and avoid cross-tenant administrative grants unless explicitly required, applying least privilege to tenant-level delegation.
Keep authentication policies (such as MFA and step-up requirements) configured per tenant where the platform supports it, rather than assuming a single global policy fits every tenant's risk profile.
Verify how your platform enforces tenant isolation and document its limitations, since isolation is typically logical and varies by vendor and configuration.
Manage each tenant's identity lifecycle (provisioning, access reviews, and de-provisioning via SCIM or equivalent) within the tenant boundary to prevent identities or entitlements from leaking across tenants.
Separate non-production and production tenants so that testing of configuration or policy changes does not affect the live identity population.
Promotional banner for the Penetration Report Template Kit