MSA1.1 Tenant Architecture — The Boundary That Constrains Everything

Most organizations never make a deliberate tenant architecture decision. They signed up for Microsoft 365, received a tenant, and started configuring it. Five years later, the tenant is the foundation of their entire security posture — and nobody documented why it's a single tenant rather than multiple tenants, what the tenant boundary means for data residency, how the boundary affects Conditional Access policy scope, or what happens when an acquisition brings a second tenant into the picture. This sub teaches you to understand the tenant as an architectural boundary with specific security, compliance, and operational consequences — and to document the decision explicitly.

Estimated time: 35 minutes.

What the tenant boundary actually is

A tenant is the term Microsoft uses for an instance of Entra ID. When your organization signed up for Microsoft 365, Microsoft created a tenant — a dedicated directory containing your users, groups, applications, policies, and configuration. Every M365 service your organization uses operates within this tenant boundary.

The tenant boundary is not a network boundary. It's not a geographic boundary. It's an identity and access management scope. Everything inside the tenant shares a common policy framework: the same Conditional Access policies evaluate every sign-in, the same Entra ID Protection instance evaluates risk, the same PIM instance governs privilege, the same Purview instance classifies data. Services outside the tenant — a subsidiary's M365 environment, a partner's Azure AD, a SaaS application with its own identity store — exist in a different scope with different policies and different administrators.

This matters architecturally because the tenant boundary determines the scope of every security control you build in this course. A Conditional Access policy you create in MSA3 applies to identities in your tenant — and only your tenant. A PIM role assignment you configure in MSA4 governs roles in your tenant — and only your tenant. A DLP policy you design in MSA5 protects data in your tenant's M365 services — and only your tenant's.

The decision about how many tenants your organization operates is therefore the decision about how many independent security architectures you need to maintain. One tenant means one architecture. Two tenants means two architectures with a cross-tenant trust layer that adds complexity to every module in this course.

Query your tenant to see what the boundary looks like in the API:

Connect-MgGraph -Scopes "Organization.Read.All"
$org = Get-MgOrganization
$org | Select-Object DisplayName, Id, TenantType, CreatedDateTime,
  CountryLetterCode, OnPremisesSyncEnabled,
  @{N='MultiGeoEnabled';E={$_.IsMultipleDataLocationsForServicesEnabled}},
  @{N='VerifiedDomains';E={($_.VerifiedDomains | Where-Object { $_.IsDefault }).Name}}

Run this against your tenant. Your output will show your organization's name, tenant ID, and configuration.

How to interpret the output — what each field tells you about your architecture:

TenantType: AAD identifies a workforce tenant (as opposed to an external/CIAM tenant — a distinction that became important when Microsoft introduced Entra External ID). If you see AAD, you're working with a standard workforce directory.

CreatedDateTime tells you when the tenant was provisioned. The older the tenant, the more accumulated configuration exists — policies, groups, and applications created by administrators who may have left. A 5-year-old tenant has 5 years of undocumented decisions.

CountryLetterCode is the initial data residency declaration. This determines where Entra ID stores the directory metadata. If your country code doesn't match your organization's primary jurisdiction, investigate — this was set at tenant creation and may reflect where the original admin was located, not a deliberate data residency decision.

OnPremisesSyncEnabled — if True, your tenant has hybrid identity configured (identities synced from on-premises Active Directory). If False or null, you're cloud-only. This single property determines whether MSA1.4 (hybrid architecture) and MSA1.5 (legacy cleanup) are directly actionable for your environment or reference knowledge.

MultiGeoEnabled — if True, Multi-Geo Capabilities are configured and M365 data can reside in multiple regions. If False, all M365 data resides in the region associated with your tenant's country code.

Compare your output against these fields. If CreatedDateTime is several years old, you're inheriting accumulated configuration — every setting was added by someone who may no longer be at the organization. If OnPremisesSyncEnabled is True, your hybrid architecture means MSA1.4 and MSA1.5 are directly actionable. If False, you're cloud-only and those subs are reference knowledge.

Now query the verified domains to understand the identity namespace:

$org.VerifiedDomains | Select-Object Name, IsDefault, IsInitial,
  @{N='Capabilities';E={$_.Capabilities}}

Your output will show your verified domains. Most tenants have at least two: the custom domain (your organization's domain) and the initial .onmicrosoft.com domain.

How to interpret the output:

The custom domain (IsDefault: True, IsInitial: False) is the domain users see in their UPN and email address. This is the domain you configured during M365 setup and verified through DNS.

The .onmicrosoft.com domain (IsDefault: False, IsInitial: True) is the one Microsoft assigned when the tenant was created. It can't be removed and serves as the fallback if the custom domain expires or has DNS issues. The initial domain is also the identifier for the tenant in federation and B2B scenarios.

If you see more than two domains, your organization has added additional custom domains — each represents a UPN suffix that users can authenticate with. Multi-domain tenants are common after acquisitions or for organizations that operate under multiple brand names.

If you see two domains — your custom domain and the .onmicrosoft.com initial — that's standard for a single-entity organization. Additional domains may indicate acquisitions, brand consolidation, or test domains that should be reviewed.

These two queries give you the tenant's identity. But they don't tell you whether the architecture decision to use a single tenant was deliberate or accidental. That's what the ADR is for.

Why most organizations have one tenant

Microsoft's recommendation is unambiguous: use a single tenant unless specific requirements force you to operate multiple tenants. The Entra architecture guidance states that multi-tenant architectures "increase management overhead and complexity and should be used with caution" and recommends a single tenant "if your needs can be met with that architecture."

The reason is operational. A single tenant provides a single policy scope — one set of CA policies, one PIM configuration, one Identity Protection instance, one DLP framework, one Sentinel workspace, one set of administrators. Every security control you build operates at the same scope. Every audit covers the same boundary. Every user experience is consistent.

A second tenant doesn't just double the work. It introduces cross-tenant complexity that multiplies it. Users in Tenant A who need to collaborate with users in Tenant B become guest identities in each other's tenants. Guest identities have different CA evaluation paths, different license entitlements, and different attack surfaces (as CVE-2025-55241 demonstrated — guest identity attributes were exploitable for cross-tenant impersonation). Conditional Access policies in each tenant must account for guest identities separately. PIM in each tenant operates independently — an admin who has eligible roles in both tenants activates them separately. Sentinel in each tenant monitors separate log streams — cross-tenant correlation requires additional architecture.

For most organizations — a single legal entity with one administrative team, one compliance framework, one data residency requirement, and one licensing agreement — a single tenant is architecturally correct. There's typically no regulatory, sovereignty, or organizational reason to split. The decision should be documented explicitly even when it's straightforward, because future events (an acquisition, a new regulatory requirement, international expansion) may change the constraints.

Apply this test to your own organization: do you have a specific regulatory, sovereignty, or organizational requirement that can't be met with administrative delegation (Administrative Units, role-scoped administration, resource-level RBAC) within a single tenant? If yes, a second tenant is justified. If no, a single tenant with proper delegation is simpler and more secure.

Record your own answer. If your organization is a single entity with one compliance framework and one licensing agreement, single-tenant is almost certainly correct. Document this as ADR-MSA1-001 — even straightforward decisions deserve a record, because acquisitions or regulatory changes may revisit the question.

When multiple tenants are architecturally justified

Multiple tenants aren't wrong — they're appropriate for specific scenarios. The architectural discipline is knowing which scenario you're in and documenting the decision.

Regulatory data sovereignty. An organization operating in both the EU and US with data residency requirements that mandate EU data stays in EU infrastructure and US data stays in US infrastructure. A single tenant can only declare one primary region. Multi-Geo extends this for M365 workloads but doesn't address all services — Entra ID metadata, for instance, is always stored in the region associated with the tenant's primary country code. For organizations subject to strict data sovereignty regulations (financial services in Switzerland, healthcare in Germany, defense in the US), separate tenants may be the only way to satisfy the regulator.

Mergers and acquisitions. A company acquires another company that already has its own M365 tenant. The acquired company's tenant contains its own users, groups, policies, applications, and data. Consolidating into a single tenant is a major project — user migration, application re-registration, policy redesign, data migration. Until consolidation is complete, the organization operates two tenants with cross-tenant access configured between them. The architectural decision is whether to consolidate (target state: one tenant) or maintain separate tenants permanently (target state: multi-tenant with cross-tenant sync).

Divestiture. The opposite of acquisition — a business unit is being spun off or sold. The divested unit needs its own tenant before the separation is complete. The architectural work is splitting users, data, and applications cleanly.

Sovereign cloud requirements. Organizations serving US government contracts may need tenants in GCC, GCC High, or DoD clouds — separate Azure environments that don't interoperate with commercial Azure. An organization with both commercial and government work operates tenants in different clouds by regulatory requirement.

Strict isolation for development and testing. The Entra architecture guidance describes a "sandbox" pattern where a pre-production tenant is isolated from the production tenant. This is appropriate when development teams need to test applications that write to Entra ID (via Microsoft Graph) and could affect production objects. The isolation prevents a buggy development script from modifying production user accounts or CA policies.

For each scenario, the architectural question is: do the requirements exceed what a single tenant with administrative delegation (Administrative Units, role-scoped administration, resource-level RBAC) can provide? If yes, a second tenant is justified. If no — if the requirement can be met with delegation within a single tenant — the additional complexity of a multi-tenant architecture is unjustified overhead.

What the boundary controls — and what it doesn't

Understanding exactly what falls inside the tenant boundary helps you design architecture that works within it and identify what needs cross-boundary treatment.

Inside the boundary (shared across all identities in the tenant):

Conditional Access policies. Every CA policy evaluates sign-ins for identities in the tenant. A policy targeting "All Users" includes every user object — member users, synced users, guest users (unless explicitly excluded). Policies can be scoped to specific groups, roles, or applications, but the policy itself exists at the tenant level.

Entra ID Protection. One instance per tenant. Risk detections, risky sign-in policies, and user risk policies operate at the tenant scope. The risk engine evaluates every authentication event in the tenant and builds behavioral baselines per identity.

PIM. One PIM configuration per tenant. Eligible role assignments, activation policies, approval workflows — all scoped to the tenant's directory roles. An identity that needs privileged access in two tenants activates PIM separately in each.

Purview policies. DLP policies, sensitivity labels, retention policies, Insider Risk Management — all operate within the tenant's M365 services. A sensitivity label published in one tenant doesn't protect data shared externally to another tenant unless the external tenant also has Purview configured to honor the label.

Sentinel and Defender XDR. One Sentinel workspace (or set of workspaces) per tenant. Defender XDR correlates signals within the tenant's Defender products. Cross-tenant correlation requires explicit architecture — multi-workspace Sentinel with cross-workspace queries, or Azure Lighthouse for multi-tenant management.

Outside the boundary (requires cross-tenant architecture):

Guest user home tenant policies. When a guest user from Tenant B signs into Tenant A, the CA policies in Tenant A evaluate the sign-in. But the guest's home tenant (Tenant B) also applies its own policies through cross-tenant access settings. The interaction between home-tenant and resource-tenant policies is a source of architectural complexity that MSA3 addresses.

Partner and supplier collaboration. NE works with 40+ suppliers and engineering partners. Some have their own M365 tenants. Collaboration happens via B2B guest access — supplier employees are invited as guests into the organization's tenant. Each guest identity is an external identity with limited attributes, different licensing entitlements, and a different trust model.

On-premises Active Directory. Entra Connect Cloud Sync bridges the on-premises directory into the tenant, but the on-premises AD itself is outside the Entra ID boundary. On-prem group policies, Kerberos authentication, NTLM authentication, and domain controller security all exist in a separate scope. MSA1.4 covers this boundary in detail.

Querying your tenant's cross-boundary relationships

To understand how your tenant connects to the world outside its boundary, query the cross-tenant access settings:

Connect-MgGraph -Scopes "Policy.Read.All"
$crossTenant = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners"
$crossTenant.value | Select-Object tenantId, isServiceProvider,
  @{N='B2BInbound';E={$_.b2bCollaborationInbound.applications.accessType}},
  @{N='B2BOutbound';E={$_.b2bCollaborationOutbound.applications.accessType}},
  @{N='CrossTenantSync';E={$_.identitySynchronization.userSyncInbound.isSyncAllowed}}

If this returns entries, your tenant has explicit cross-tenant relationships. Each entry represents a partner tenant with configured trust settings. b2bCollaborationInbound controls what guest users from that partner can access in your tenant. b2bCollaborationOutbound controls what your users can access as guests in the partner's tenant. identitySynchronization controls whether cross-tenant user sync is enabled — the mechanism that automatically provisions B2B users between trusted tenants.

If this query returns empty results, no explicit cross-tenant partnerships are configured. External collaboration uses ad-hoc B2B invitations without a configured trust relationship. That's common — most organizations start with ad-hoc invitations and only configure explicit policies when they need to restrict or control cross-tenant access.

If you see results, each entry represents a deliberate trust configuration with a specific external tenant — inbound (what they can access in your tenant), outbound (what your users can access in their tenant), or both.

If this query returns empty results, no explicit cross-tenant partnerships are configured — external collaboration relies on ad-hoc B2B invitations. That's common, but it means guest access isn't governed by configured trust policies. If you work with external partners regularly, this gap is worth documenting for MSA4.6.

Documenting your tenant architecture decision

Whether your organization operates a single tenant or multiple tenants, the decision should be documented in an ADR. Even if the decision is obvious (single entity, single tenant), the ADR captures the reasoning so that a future architect — or your future self after an acquisition — understands the constraints that shaped the choice.

Your ADR should include: the current state (how many tenants, why), the constraints (regulatory, operational, technical), the alternatives considered (with specific rejection reasons), and the consequences (what the decision enables and requires).

If your tenant is a developer tenant, write the ADR as if it were your production environment. The skill is writing ADRs, not the specific content — you'll write 30+ ADRs across this course.

Worked example — the organization's tenant architecture ADR:

>

ADR-MSA1-001: Single-tenant architecture for your organization

>

Context. NE is a single legal entity operating 6 sites in the UK. All staff are employed by your organization Ltd. No regulatory requirement mandates data residency separation beyond the UK. One Active Directory forest serves all sites. One M365 license agreement covers all users. One compliance framework (ISO 27001 + Cyber Essentials Plus) applies uniformly.

Current tenant state:

(Get-MgOrganization).TenantType                    # AAD
(Get-MgOrganization).CountryLetterCode              # GB
(Get-MgOrganization).OnPremisesSyncEnabled           # True
(Get-MgOrganization).IsMultipleDataLocationsForServicesEnabled  # False
(Get-MgOrganization).VerifiedDomains.Count           # 2

Single workforce tenant, UK-based, hybrid sync enabled, single region. No Multi-Geo. Two verified domains (custom + initial).

Decision. Maintain single-tenant architecture. All identity, access, protection, detection, and governance controls operate within one tenant boundary. Supplier and partner collaboration via Entra ID B2B with cross-tenant access policies (to be configured in MSA3). No second tenant for development or testing — administrative delegation via Administrative Units (MSA1.6) provides sufficient isolation.

Alternatives Considered.

• Multi-tenant with separate dev/test — rejected. the organization's development team (12 engineers) doesn't build applications that write to Entra ID via Microsoft Graph. Their development activity is engineering CAD/PLM software, not M365-integrated applications. A separate tenant for dev/test adds administrative overhead without addressing a real requirement.
• Multi-tenant for acquired business unit — not applicable. the tenant has no current or planned acquisitions. If an acquisition occurs, this ADR should be revisited with the acquired entity's tenant state as input.
• Multi-Geo within single tenant — rejected. All NE operations are UK-based. Multi-Geo adds licensing cost (Multi-Geo Capabilities add-on) for a requirement that doesn't exist. Revisit if NE opens non-UK offices.

Consequences.

• Enables: One set of CA policies, one PIM configuration, one Identity Protection instance, one Purview framework, one Sentinel workspace, one administrative team. Every module in this course operates within a single scope.
• Breaks: Nothing — this is the existing state. The ADR documents it rather than changing it.
• Requires: Cross-tenant access policies for B2B collaboration with suppliers (MSA3). Administrative Units for delegated administration across 6 sites (MSA1.6).
• Dependencies: None — this is the foundational decision.

Residual Risk. If NE acquires a company with an existing M365 tenant, the single-tenant architecture will need to be either expanded (consolidate the acquired tenant) or modified (multi-tenant with cross-tenant sync). The consolidation project is significant — user migration, application re-registration, policy redesign. Residual risk: an acquisition could require 3–6 months of dual-tenant operation with temporary cross-tenant architecture.

Communication. "We're documenting that our single-tenant setup is the right architecture for NE — one company, one tenant, one set of security controls. If an acquisition happens, we revisit. For supplier collaboration, we'll configure explicit trust relationships rather than relying on ad-hoc invitations."

Before moving on, verify your understanding: Run the tenant properties query against your tenant. What is your OnPremisesSyncEnabled value? If True, you're hybrid — explain what this means for MSA1.4 and MSA1.5. If False or null, you're cloud-only — explain which MSA1 subs are directly actionable vs reference knowledge. Name three specific security controls from this course that operate within the tenant boundary and explain what happens to each if you have two tenants instead of one.

Reusable script — the commands from this sub assembled for operational use:

Copy the NE ADR (ADR-MSA1-001) into your architecture package at 01-identity/adrs/ADR-MSA1-001-tenant-architecture.md as a reference example. Then write the equivalent ADR for your own tenant — documenting whether single-tenant or multi-tenant is correct for your specific constraints. If you're using a developer tenant, write the ADR for your production environment (or for a fictional organization you define). The skill is the ADR writing process — documenting constraints, alternatives, and consequences — not the specific content.

Run these queries against your own tenant to populate the Context field:

# Tenant properties
Get-MgOrganization | Select-Object DisplayName, TenantType,
  CountryLetterCode, OnPremisesSyncEnabled,
  IsMultipleDataLocationsForServicesEnabled, CreatedDateTime

# Verified domains
(Get-MgOrganization).VerifiedDomains |
  Select-Object Name, IsDefault, IsInitial

# Cross-tenant partnerships
(Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners"
).value | Measure-Object | Select-Object Count

# Subscribed SKUs (how many license agreements?)
Get-MgSubscribedSku | Select-Object SkuPartNumber, ConsumedUnits

The answers determine whether your organization's single-tenant architecture is correct — or whether a documented multi-tenant decision is needed.