Identity and Access Architecture
Design identity architectures for Zero Trust — covering Entra ID tenant design, external identity strategies (B2B, External ID), workload identities, and identity as the primary control plane.
Identity and Access Architecture
Identity as the Primary Control Plane
In traditional network-centric security, the network perimeter was the control plane — if you were inside the firewall, you were trusted. Zero Trust dismantles this assumption. Instead, identity becomes the primary control plane:
- Every request must be authenticated (who are you?)
- Every request must be authorized (are you allowed to do this?)
- Every request is evaluated in context (what device, location, risk level?)
- Access is granted with least privilege and just-in-time
This means your identity architecture is foundational. A poorly designed identity system undermines every other security control, because attackers who compromise identity bypass network controls entirely.
Identity for Different Resource Types
SaaS applications — Users authenticate through Entra ID (directly or via federation). Conditional Access evaluates risk signals before granting access. Single sign-on (SSO) eliminates password sprawl across applications.
PaaS services — Applications authenticate using managed identities or service principals. Developers should never embed credentials in code. Role-based access control (RBAC) determines what the application can do.
IaaS resources — Virtual machines and other infrastructure use managed identities for service-to-service authentication. Admin access uses just-in-time elevation through PIM. Azure Bastion provides secure administrative access without exposing management ports.
On-premises resources — Hybrid identity (Entra Connect or Cloud Sync) synchronizes on-premises AD with Entra ID. Application Proxy publishes on-premises web apps without VPN. Kerberos-based apps can use Entra ID for authentication through Application Proxy with constrained delegation.
Entra ID Tenant Architecture
The tenant is the fundamental boundary of identity in Microsoft’s cloud. Every Entra ID tenant is an isolated identity boundary — users, groups, applications, and policies in one tenant are completely separate from another tenant.
Single Tenant (Most Common)
One Entra ID tenant for the entire organization. All users, regardless of location or business unit, exist in the same directory.
Advantages: Simplest to manage. Unified policies. Single Conditional Access configuration. No cross-tenant complexity. Users can seamlessly collaborate across business units.
When to use: Most organizations. Unless you have a regulatory or structural reason to separate identity boundaries, single tenant is the default recommendation.
Multi-Tenant
Multiple Entra ID tenants — typically one per subsidiary, region, or regulatory boundary. Each tenant has its own users, policies, and administrative boundary.
Advantages: Hard isolation between identity boundaries. Separate administrative control. Compliance with regulations requiring distinct identity management per jurisdiction.
When to use:
- Mergers and acquisitions where acquired companies maintain their own identity infrastructure during integration
- Regulatory requirements that mandate separate identity management per region or industry
- Organizational structure where subsidiaries are legally independent entities
- Sovereign cloud requirements (government tenants isolated from commercial)
Challenges: Users need guest accounts or cross-tenant access to collaborate. Policy consistency requires deliberate effort. Admin overhead increases with each tenant.
Cross-Tenant Access Settings
When you have multiple tenants (or need to collaborate with partner organizations), cross-tenant access settings control the trust relationship:
- Inbound settings: Control how users from OTHER tenants access YOUR resources
- Outbound settings: Control how YOUR users access resources in OTHER tenants
- Trust settings: Decide whether to trust another tenant’s MFA claims, compliant device claims, or hybrid joined device claims
This is critical for M&A scenarios where the acquiring company wants to trust the acquired company’s MFA without forcing users to re-enroll.
External Identity Strategies
Almost every organization needs to give external users (partners, vendors, customers, auditors) access to internal resources. The architecture decision is how to represent these external identities.
| Feature | B2B Collaboration | B2B Direct Connect | Microsoft Entra External ID |
|---|---|---|---|
| Who is it for? | Partner employees who need access to your Microsoft 365 or Azure resources | Partner employees who need real-time collaboration in Teams shared channels | External customers who need to access your consumer-facing application |
| How it works | External user gets a guest account in YOUR tenant. They authenticate with their home organization. | No guest account created. Users remain in their home tenant and access shared resources directly. | Customers create accounts (or use social identity providers like Google, Facebook) in an external tenant configuration. Note: Azure AD B2C is legacy/end-of-sale for new customers — Microsoft Entra External ID is the replacement. |
| Identity lives where? | Guest object in your Entra ID (shadow account) | User stays in their home tenant — no object in your directory | External ID tenant — completely separate from your corporate Entra ID |
| Access control | Same Conditional Access, RBAC, and governance policies as internal users | Controlled by Teams shared channel policies and cross-tenant access settings | Custom policies in the External ID tenant — separate from corporate policies |
| Best for | Ongoing partner access to SharePoint, Teams (standard channels), Azure resources, custom apps | Real-time Teams collaboration without creating guest accounts | Customer-facing applications (portals, e-commerce, self-service) |
B2B Collaboration Deep Dive
When you invite a partner user via B2B collaboration, a guest account is created in your tenant. The user authenticates with their home identity provider (their own Entra ID, or a social account) and gets a session in your tenant.
Key architecture decisions:
- Who can invite guests? Restrict to admins or allow any member to invite (balance collaboration speed vs control)
- Which domains are allowed? Allow-list specific partner domains or deny-list risky ones
- What Conditional Access applies? Guest users can (and should) have different CA policies than members — for example, requiring MFA from all locations, blocking unmanaged devices
- Lifecycle management: How do you remove guest accounts when the partnership ends? (Entitlement Management with access packages handles this)
B2B Direct Connect Deep Dive
B2B direct connect is specifically for Teams shared channels. No guest account is created — the external user accesses the shared channel using their own identity, authenticated by their home tenant.
Key architecture decisions:
- Requires mutual consent — both tenants must configure cross-tenant access settings to allow direct connect
- Trust settings determine whether you trust the partner tenant’s MFA and device compliance claims
- Less administrative overhead (no guest accounts to manage) but limited to Teams shared channels
🌐 Elena Designs Multi-Tenant Architecture for Acquisitions
Meridian Global Industries has acquired two companies in the past year — a German manufacturing firm and a Japanese logistics company. Both have their own Entra ID tenants, and Elena needs to design the identity architecture.
“We’re not merging the tenants immediately,” Elena tells Marcus Chen, the board chair. “Identity migration for 15,000 users is a 6-12 month project, and we can’t disrupt operations during integration.”
Elena’s phased approach:
- Phase 1 (Now): Configure cross-tenant access settings between all three tenants. Trust the acquired companies’ MFA claims so their users don’t have to re-enroll in Meridian’s MFA. Set up B2B collaboration for users who need access to Meridian’s SharePoint and Teams.
- Phase 2 (3 months): Deploy cross-tenant synchronization to automatically create guest accounts in Meridian’s tenant for users who need access. Set up entitlement management with access packages — German users request access to manufacturing systems, Japanese users request access to logistics platforms.
- Phase 3 (6-12 months): Evaluate full tenant consolidation. Move users from acquired tenants into the Meridian tenant, retire the legacy tenants, or maintain multi-tenant if regulatory requirements demand it.
“Germany has strict data residency requirements,” Li Wei notes. “Their HR data and some operational data must stay in the EU.”
“That’s why we might keep the German tenant permanently,” Elena replies. “Multi-tenant with cross-tenant access may be the long-term architecture, not a temporary state. The regulatory landscape will determine the final design.”
Workload Identities
Workload identities are the identities used by applications, services, and automated processes — not humans. They’re often overlooked in identity architecture, but compromised workload identities are a growing attack vector.
Managed Identities (Preferred)
Azure automatically manages the identity lifecycle. No credentials to store, rotate, or manage. The identity exists only in Entra ID and is tied to the lifecycle of the Azure resource.
- System-assigned: One identity per Azure resource. Deleted when the resource is deleted. Simplest option.
- User-assigned: Independent identity that can be shared across multiple Azure resources. Useful when multiple resources need the same permissions.
When to use: Always prefer managed identities when the workload runs on Azure (VMs, App Service, Functions, Logic Apps, AKS pods). Zero credential management overhead.
Service Principals
The application object and its local representation (service principal) in Entra ID. Service principals can authenticate with secrets (passwords) or certificates.
When to use: For applications that don’t run on Azure (on-premises apps, third-party tools) or applications that need to authenticate across tenants. Service principals with certificates are more secure than those with secrets.
Risk: Secrets and certificates expire. If rotation isn’t automated, applications break. Over-permissioned service principals are a common finding in security assessments.
Workload Identity Federation (Federated Credentials)
Instead of storing a secret, the workload presents a token from an external identity provider (GitHub Actions, Kubernetes, other cloud providers) and exchanges it for an Entra ID token. No secrets are stored anywhere.
When to use: CI/CD pipelines (GitHub Actions, Azure DevOps), Kubernetes workloads, and cross-cloud scenarios. Eliminates the secret management problem entirely.
💰 Ingrid Designs External Access for Auditors
Ingrid Svensson at Nordic Capital Partners needs to give external auditors access to compliance documents and financial reports. The auditors come from three different auditing firms that each have their own Entra ID tenants.
“We can’t have auditor accounts lingering in our directory after the audit is complete,” Ingrid tells Harald Eriksen, her compliance lead. “Last year, we found active guest accounts from an audit firm we stopped working with two years ago.”
Ingrid’s design:
- Entitlement Management access packages — each auditing firm gets an access package containing the SharePoint sites and Teams channels they need
- Time-limited access — access packages expire at the audit end date. No manual cleanup needed.
- Quarterly access reviews — automated reviews ask the audit manager to confirm each auditor still needs access
- Conditional Access for guests — MFA required from all locations, no access from unmanaged devices, session timeout after 8 hours
- Cross-tenant access settings — trust the auditing firms’ MFA claims (they’re reputable firms with strong security), but don’t trust their device compliance (we don’t know their device management standards)
“What about the firms that don’t have Entra ID?” Yuki Tanaka asks.
“We use email one-time passcode (OTP) for those,” Ingrid replies. “They get invited via B2B, authenticate with an OTP sent to their email, and the same access package lifecycle and Conditional Access policies apply. They don’t get a weaker experience just because they don’t have Entra ID.”
SC-100 Exam Strategy: Identity Architecture
Meridian Global Industries has acquired a German company with 3,000 users in their own Entra ID tenant. The German company's users need immediate access to Meridian's SharePoint and Teams. German data residency regulations require HR and operational data to remain in the EU. What should Elena recommend?
A development team is deploying an Azure Function app that needs to read secrets from Azure Key Vault and write data to Azure SQL Database. The team is currently using a service principal with a client secret stored in application settings. What should the security architect recommend?
🎬 Video coming soon
Next up: Conditional Access and Identity Governance — We’ll design the Zero Trust policy engine, build Conditional Access patterns for different user populations, and set up governance to ensure access stays appropriate over time.