Multi-tenant identity design is difficult because the word “tenant” can describe two different things. In a SaaS application, a tenant is usually a customer or organizational boundary. In Microsoft Entra ID, a tenant is an identity directory. Those concepts can align, but they do not have to. Architects working in the AZ-305 space need to separate application tenancy from identity-directory tenancy before deciding how users authenticate and how their authorization is isolated.
Microsoft’s current Azure Architecture Center guidance recommends using managed identity providers rather than building an authentication system yourself. For business-to-business applications, customer organizations may already use their own Microsoft Entra tenants. For mixed or consumer scenarios, Microsoft Entra External ID can provide sign-up, federation, and customer identity capabilities. The architecture should choose the identity model based on who the users are and what trust relationships the service needs.
Define the application tenant independently of the directory
An application tenant is a business boundary: a customer company, department, partner, school, or other group whose data and permissions must be isolated from other groups. A Microsoft Entra tenant is an identity directory. One application tenant might contain users from one Entra directory, several directories, or external identity providers.
That distinction prevents the application from assuming that a directory ID is always the same thing as customer tenancy. A consultant might belong to one Microsoft Entra tenant and work across several customer tenants inside the SaaS application. Conversely, a customer might migrate directories without changing its application tenant.
Model the application tenant explicitly in data and authorization. Identity tells you who the user is; application tenancy tells you which customer context the request belongs to.
Tenant identity should be represented with a durable internal identifier. Customer display names, domains, and directory IDs can change during mergers, rebranding, or identity migration. An internal tenant key lets the application preserve data ownership while external identity attributes are updated.
Choose the identity provider from the user population
For business customers that already use Microsoft Entra ID, a multitenant application registration can let users authenticate with their home organizational directory. The application trusts Microsoft identity tokens from approved tenants and then maps those identities to application tenants and roles.
For customer populations that are not primarily Microsoft Entra organizations, External ID can support sign-up, invitation, branding, and federation with other identity providers. The architecture should avoid assuming that every external user will become a guest account in the provider’s workforce tenant if the product has a true customer-identity requirement.
The knowledge represented by SC-300 is useful because the application’s design depends on Microsoft Entra concepts such as users, groups, applications, service principals, conditional access, and external collaboration.
Onboarding should decide who is allowed to establish the first administrative relationship for a new customer tenant. Self-service registration can be appropriate for some products, while enterprise services may require sales or support verification. The first administrator can often invite others or configure federation, so that bootstrap process is security-sensitive.
Track tenant context on every request
Authentication answers which identity signed in. Authorization still needs to determine which tenant that identity is acting for and what it can do there. The tenant context can come from the route, token claims, user selection, or application data, but it must be validated before access to tenant-scoped resources is granted.
A dangerous design assumes that because a user has a valid token, every resource referenced in the request belongs to that user’s tenant. Object identifiers supplied by the client must be checked against the active tenant boundary. Otherwise, an authenticated user can potentially access another tenant’s data by changing an identifier.
Keep tenant identity separate from user identity in the authorization model. One user may legitimately belong to multiple application tenants, and the role may differ in each one.
Tokens should be validated for issuer, audience, signature, lifetime, and the claims the application actually relies on. A multitenant application cannot assume that any token signed by Microsoft is intended for it. Validation rules should match the registration model and should reject tokens that come from unapproved tenants when the service uses an allowlist.
Use federation instead of copying customer credentials
Federation lets the customer’s identity provider authenticate its users while the SaaS application consumes the resulting token. This preserves the customer’s password policies, MFA, and account lifecycle. When an employee leaves the customer organization and the identity is disabled, the application can stop accepting sign-in without maintaining a separate password database.
The broader principles behind Microsoft identity and access administration apply directly. Strong identity lifecycle, conditional access, and secure application registration are architectural dependencies for SaaS systems even when the application itself is not an Azure administration tool.
Do not build custom password authentication unless there is an exceptional requirement. Managed identity platforms have security capabilities that are difficult and expensive to reproduce safely.
Federation also affects support. If a customer’s conditional access policy blocks a user, the SaaS provider may see only an authentication failure. Support tooling should capture enough non-sensitive identity context—such as tenant, issuer, correlation ID, and error category—to help the customer’s identity team investigate without exposing tokens or credentials.
Authorization should be tenant-aware and application-specific
Directory roles and Azure RBAC do not automatically solve SaaS application authorization. The application needs a model for tenant-level roles and, where required, resource-level permissions. A user might be an administrator for one customer tenant and a read-only auditor for another.
Role-based authorization is easier to operate when roles represent stable business responsibilities. Resource-based authorization can be added where users need access to specific projects, accounts, or records. Keep the authorization data close enough to the application that tenant context can be evaluated reliably on every request.
Avoid granting broad authorization solely from email domain or directory membership. Domains can change, guest users exist, and one directory can host identities for multiple business contexts. The authorization decision should rely on explicit application relationships.
Authorization data needs lifecycle controls. When a user leaves a customer or changes role, application permissions should be removed promptly even if the identity still exists in the external directory. For large customers, automated provisioning standards such as SCIM can reduce manual account maintenance and keep application membership synchronized with authoritative groups or systems.
Cross-tenant access needs an explicit trust policy
Enterprises sometimes operate several Microsoft Entra tenants or collaborate with partner tenants. Cross-tenant access settings, B2B collaboration, and tenant restrictions can shape who is allowed to authenticate and under what conditions. The identity architecture should document whether any Entra tenant can attempt sign-in or whether customers must be onboarded to an allowlist.
Tenant onboarding should validate the organization and establish administrative ownership. For some B2B products, customer administrators may grant consent for application permissions. That process should be designed as part of customer onboarding, not discovered during the first production sign-in.
The wider Microsoft certification ecosystem spans identity, security, administration, and architecture because cross-tenant trust is not owned by one discipline. Product design and enterprise identity policy need to agree.
Consent should be least-privilege. If the application needs Microsoft Graph or another API, request only the delegated or application permissions required. Broad tenant-wide application permissions increase the impact of credential compromise and can make enterprise customers reluctant to onboard. Separate optional integrations from the core sign-in path when they require elevated consent.
Workload identities need tenant isolation too
Users are not the only identities in a multitenant application. Background workers, deployment automation, data pipelines, and integrations also authenticate. Use managed identities or service principals rather than shared secrets where the Azure service supports them, and scope permissions to the resources each component requires.
Do not let one highly privileged workload identity become the universal key to every customer’s data if the architecture can avoid it. Separate identities by service, deployment stamp, or privilege boundary where that reduces blast radius. Record tenant context in background jobs so that an asynchronous worker cannot accidentally process data under the wrong customer scope.
Secret and certificate rotation should be automated for identities that still require credentials. The operating model matters as much as the initial authentication design.
Background processing needs a safe way to establish tenant context even when there is no interactive user token. Queue messages, scheduled jobs, and integration events should carry or resolve a trusted tenant identifier. Never derive tenant ownership only from an object ID supplied by an external caller without verifying that the object belongs to the intended tenant.
Identity scale affects token and directory design
Large SaaS platforms need to consider authentication volume, directory object limits, token validation, consent, and onboarding automation. Storing one group or directory object for every fine-grained application permission can create scaling and administration problems. Application authorization data may be a better fit for high-cardinality business roles.
Caching token metadata can improve performance, but authorization changes need a predictable propagation model. Long-lived cached permissions can keep access active after an administrator revokes it. Decide which claims can be cached and which decisions require fresh application data.
Audit logs should record user identity, application tenant, action, target resource, and authorization result. That context is essential when investigating whether a cross-tenant access event was legitimate or a boundary failure.
Rate limits and sign-in surges should be considered at large scale. Product launches, regional incidents, or token expiration patterns can create synchronized authentication demand. Cache public signing keys correctly, use recommended identity libraries, and avoid unnecessary directory lookups on every request when validated token claims and application data are sufficient.
Session management should respect tenant changes. If a user switches from one customer context to another, cached authorization and UI state must change with it. Long-lived sessions should not preserve access after tenant membership is revoked. Applications need a clear strategy for token refresh, session invalidation, and tenant switching.
Data export and support tooling are common places where isolation breaks. Administrative dashboards, analytics jobs, and customer-support impersonation features often sit outside the primary request path. Apply the same tenant-context checks to those tools and record privileged support access in audit logs.
Test isolation as aggressively as authentication
Identity systems are often tested for successful login while tenant isolation receives less attention. Security tests should attempt to cross tenant boundaries by changing route identifiers, object IDs, API parameters, and background-job inputs. The application should reject the request even when the user is fully authenticated.
The operational perspective described in Azure administration also matters because identity failures can come from application configuration, role assignments, networking, or directory settings. Monitoring needs to distinguish authentication failure, authorization failure, and tenant-context mismatch.
Strong multi-tenant identity design keeps four concepts separate: the user, the identity provider, the application tenant, and the authorization relationship. Use managed identity platforms, track tenant context on every request, federate where customers already own identities, and make isolation explicit in data and code. That produces a system where one user can safely work across legitimate tenants without turning authentication success into unrestricted access.
Incident response should be able to revoke or isolate one application tenant without disabling the whole service. That might mean blocking a compromised customer tenant, invalidating its sessions, stopping its background jobs, and preserving audit data while other customers continue operating. Designing that containment path in advance turns tenant isolation from a data-model concept into an operational capability.
Identity architecture should also support regional resilience. Authentication may depend on globally distributed Microsoft services, but application-specific authorization data, session stores, and tenant mappings can still be regional. Replicate or reconstruct those components according to the application’s recovery objectives so a regional failover does not restore compute while leaving users unable to authorize.
Review tenant-deletion workflows as carefully as onboarding. Customers may require export, retention, legal hold, or verified deletion across databases, object storage, caches, search indexes, and backups. A durable tenant identifier and inventory of data locations makes that lifecycle manageable and helps prove that isolation extends to end-of-service handling.
Customer administrators should have self-service visibility into membership and sign-in where the product model allows it. Giving tenants a controlled way to review users, revoke sessions, and inspect audit events reduces support dependence and makes the boundary easier for customers to govern.
Privacy requirements can affect identity logging. Store enough information to investigate access without retaining unnecessary token contents or personal data. Use stable identifiers and correlation IDs so security teams can trace events while keeping the authentication pipeline aligned with data-minimization obligations.
Tenant-aware authorization should be reviewed whenever new product features introduce shared resources. Collaboration features, cross-tenant reporting, support consoles, and marketplace integrations can intentionally cross boundaries that were previously strict. Each new cross-tenant feature needs an explicit rule for who can authorize the relationship and how the action is audited.
Use separate administrative roles for identity-platform configuration and customer-tenant administration. The engineers who maintain application registrations, federation, or External ID settings do not necessarily need access to customer business data, while support staff who manage tenant membership should not automatically be able to change the underlying identity provider configuration. Separation of duties reduces the impact of mistakes and compromised accounts.
Document the tenant-isolation threat model. Make it explicit which boundaries are enforced by identity, which by application authorization, and which by data partitioning so security reviews can test the correct control instead of assuming one layer protects everything.