Zero trust configuration for multitenant defense organizations

This article shows multitenant organizations how to apply configurations in Microsoft Entra ID and meet common defense zero trust requirements. Follow these recommendations to establish the right multitenant identity architecture and implement zero trust in your environment.

Figure 1: Sample multitenant defense architecture with zero trust configurations.

Determine identity architecture

Microsoft Entra tenants are the foundation of your identity architecture. A tenant is an identity boundary in Microsoft Entra ID. An organization with one Microsoft Entra tenant has a single tenant architecture. Organizations using more than one Microsoft Entra tenant have a multitenant architecture.

Benefits of a single tenant. A single tenant is easier to manage and lower costs through operational efficiency. It allows you to configure a zero trust environment more easily. A single tenant avoids fragmenting the user experience with multiple sign-in credentials. It also helps prevent siloed solutions that you need to integrate later. You should strive to have your data, Microsoft 365, and Azure cloud services in a single tenant. If you already have multiple Microsoft Entra tenants, you should consider consolidating your environment to use a single tenant. You can consolidate tenants by transferring Azure subscriptions from your secondary tenants to the primary tenant. For more information, see transfer an Azure subscription to a different Microsoft Entra directory.

Multitenant use cases. There are reasons for a defense organization to use a multitenant architecture. Large and complex defense organizations might need multiple Microsoft Entra tenants for security, compliance, and collaboration (see table 1).

Table 1. Reasons to have or create multiple tenants.

If you require multiple Microsoft Entra tenants, you should use Microsoft Entra External ID (B2B) and Azure Lighthouse. These features help support multitenant defense environments. For more information, see Tenancy models for a multitenant solution.

Identify tenant types

Multitenant defense organizations can categorize Microsoft Entra instances they use as either primary or secondary. Each organization should identify and designate one tenant as the primary tenant. All other tenants are secondary. Figure 1 shows a defense organization with a primary tenant and n secondary tenants (two secondary tenants shown).

Identify the primary tenant. Most defense organizations create the primary tenant when they sign up for Microsoft 365. The primary tenant contains (1) all user identities and Microsoft 365 licenses, (2) devices, and (3) applications (see figure 1). Defense organizations often use Microsoft Entra Connect to synchronize the identities from Active Directory on-premises to the primary Microsoft Entra tenant.

Some defense organizations consume Microsoft 365 in a shared tenant owned and operated by an outside agency. This agency acts as a shared service provider for Microsoft 365. Your organization might not manage or control the shared tenant, but it contains the licensed Microsoft Entra identities your users likely use for Office 365 and other applications. In this scenario, the shared service provider tenant is your primary tenant.

Identify all secondary tenants (if multitenant). All other tenants that the organization manages are secondary tenants. You might have secondary tenants if you migrated applications to the cloud before standing up an enterprise-scale Azure landing zone. You typically use secondary tenants to manage (4) Azure workloads with external users (B2B guests) or (5) cloud only accounts (see figure 1).

Use the decision tree. The easiest way to find your primary tenant is to consider the identity licenses you have in Microsoft Entra ID.

The tenant with your Microsoft 365 licenses is your primary tenant (see figure 2). The primary tenant might not be the first tenant created by your organization, but it should be the main tenant with all your users and Microsoft 365 licenses.

If your organization doesn’t use Microsoft 365, any Microsoft Entra tenant with Enterprise Mobility and Security (EMS) licenses is your primary tenant. This tenant is where you added and verified your organization's domain name. The tenant often uses hybrid identity or integrates with a human resources (HR) system (see figure 2).

Figure 2. A decision tree to determine the Microsoft Entra primary tenant and secondary tenant.

To establish Microsoft Entra ID as a zero trust platform, you need a tenant populated with your user identities and licensed for user and device-based access policies. Microsoft 365 licensing bundles these zero trust capabilities with Office 365. If you don't use Microsoft 365, consider Enterprise Mobility + Security E5 to establish a cloud-based identity provider for zero trust. For more information, see Choosing your identity authority.

Configure zero trust

When managing identities in Microsoft Entra ID, you should consider the following recommendations for each tenant type. There are general recommendations for all tenant types that you should adopt first. After implementing those general recommendations, find the recommendations for your specific tenant type (primary or secondary) and then apply those recommendations.

To learn more about securing Microsoft Entra tenants with zero trust, see Zero Trust Rapid Modernization Plan and Security Rapid Modernization Plan.

All tenants

You should implement the following recommendations in all Microsoft Entra tenants.

Establish emergency access accounts and procedures. Create two or more emergency access accounts to avoid being locked out of your Microsoft Entra tenant. You need to assign the Global Administrator role to these accounts. The accounts should be cloud-only accounts. Cloud-only accounts use the *.onmicrosoft.com domain. For more information, see Manage emergency access admin accounts.

Protect Microsoft Entra ID from on-premises attacks. Follow best practices outlined in Securing Privileged Access. Only assign Microsoft Entra permissions to cloud-only user accounts with phishing-resistant credential like Hardware Passkey or Certificate-Based authentication. Don't use federated identities for administrative purposes. For more information, see Protect Microsoft 365 from on-premises attacks.

Use Privileged Identity Management. Use Microsoft Entra Privileged Identity Management (PIM) to manage role assignments for Microsoft Entra ID and Azure roles. You should also use PIM to manage eligible group membership for privileged security groups. Establish periodic access reviews for eligible administrators and external users (B2B guests).

Enable cloud-based authentication for all users. Cloud-based authentication methods are more secure than federated authentication. They offer a better single sign-on experience when combined with Microsoft Entra joined devices. Federated authentication exposes Microsoft Entra ID to on-premises Active Directory compromises.

Microsoft Entra certificate-based authentication (CBA) makes it unnecessary to federate Microsoft Entra domains. Microsoft Entra authentication supports the following passwordless authentication methods:

• Passkeys (FIDO2 security keys)
• Certificate-Based Authentication
• Microsoft authenticator
• Windows Hello for Business

Establish baseline conditional access policies. Conditional access baseline varies by organization and requirements. Establish a core set of conditional access policies for all Microsoft Entra tenants. Use identity, device, application, and risk conditions within your policy set. Exclude Emergency Access accounts from your Conditional Access policies.

Microsoft Entra ID Protection helps organizations detect, investigate, and remediate identity-based risks. To protect risky sign-ins and users, create Conditional Access policies with risk conditions. Use separate policies for risky users and risky sign-ins. Increase applied controls with risk level for each risk type. To balance user productivity with security, avoid using the Block control in risk-based policies.

Design Conditional Access policies for your organization, using the Example Conditional Access policy checklist (see table 2). Use report-only mode to test Conditional Access policies before deploying to production.

Table 2: Example Conditional Access policy checklist.

The example policy set in table 2 is for passwordless organizations where all users only use phishing-resistant MFA from managed devices. Privileged users use Intune-managed Privileged Access Workstations (PAW). Instead of requiring a password change for high risk users, the risky user policy enforces authentication strength and sign-in frequency controls. These controls offer some protections but don't remediate the user's risk level in Microsoft Entra ID Protection. Your security operations team should investigate and remediate high risk users.

To learn more about Conditional Access deployment, see Plan a Conditional Access deployment.

Use primary tenant identities for accessing all applications. Users should be able to access applications using their identity in the primary tenant. You need to register applications in the primary tenant. Establish a policy to register applications with the primary tenant, regardless of the application infrastructure hosting location.

For legacy applications that don't support modern authentication protocols, use Microsoft Entra application proxy service in the primary tenant. Microsoft Entra application proxy brings Microsoft Entra zero trust features to existing legacy applications without code changes.

When a shared service provider or an external agency controls your primary tenant, they should delegate application registration permissions. If the service provider doesn't offer this delegation, you need to register applications with the secondary tenant that your organization controls instead. However, users should still access these applications without creating a new identity in the secondary tenant. For this setup, assign user access using external identities (B2B guests) for your users in the primary tenant. For more information, see Secure applications with zero trust.

Use Microsoft Entra ID to manage other cloud environments. Microsoft Entra ID isn't just an identity platform for Azure and Microsoft 365. Use Microsoft Entra ID to gain access to other cloud environments. These environments include popular software-as-a-service (SaaS) products and cloud platforms like Amazon Web Services (AWS) and Google Cloud Platform (GCP). For more information, see the Microsoft Entra Application gallery.

Use a secure cloud computing architecture (SCCA). Each defense organization should deploy an SCCA-compliant landing zone architecture. The landing zone should be in Azure subscriptions attached to the primary tenant.

Segment Azure resource management in a single tenant. You should use Azure roles for resource and management isolation for subscriptions within an enterprise-scale Azure landing zone. Consider transferring subscriptions from secondary tenants to the primary tenant.

Use Microsoft Entra Permissions Management. Microsoft Entra Permissions Management is Microsoft’s Cloud Infrastructure Entitlement Management (CIEM) solution. You should use Microsoft Entra Permissions Management for visibility into permissions assigned to all identities. You should also use it to track permissions creep across your organization's multicloud environment.

Use Microsoft Entra ID Governance. Use Microsoft Entra ID Governance to automate access assignment lifecycle for users and guests. Conduct access reviews to remove access to your cloud environment for users that no longer need it.

Secure workload identities. Use Microsoft Entra Workload ID features to manage and apply adaptive zero trust policies for application identities (service principals) in Microsoft Entra ID.

Enable Defender for Cloud for your enterprise. Use Defender for Cloud for your multicloud environment. Make sure you turn on the enhanced security features to monitor Azure resources and remediate configuration risk. Defender for Cloud protection extends beyond Azure to help you secure hybrid and multicloud environments.

Deploy Sentinel and connect all available data sources. Aggregate security signals in a SIEM like Microsoft Sentinel. Deploy Sentinel and connect all security signal data sources by configuring data connectors.

Primary tenants

You should implement the following recommendations in the primary tenant only.

End users only have one identity in Entra ID. Synchronize on-premises Active Directory Domain Services with the primary Microsoft Entra tenant. The synchronization populates Microsoft Entra ID with users, groups, and devices for the organization. External B2B guests might exist in secondary tenants, but users only need to remember one username for all applications and services. The user experience and zero trust outcomes are best when you use the identities in the primary tenant for Windows sign-in and application access.

Join and manage devices with the primary tenant. The primary Microsoft Entra tenant contains all users and devices within the organization. Microsoft Entra join (or Microsoft Entra hybrid join) Windows devices to the primary tenant and manage with Microsoft Intune. Use Intune policy to deploy Microsoft Defender for Endpoint enabling extended detection and response (XDR) capability.

Delegate application registration permissions. Enterprise Apps, including application code running in any Azure subscription, use the primary Microsoft Entra ID tenant for user identity. Make developers eligible for the Application Developer Microsoft Entra role or a custom app registration role using Privileged Identity Management. This configuration allows developers building applications in secondary tenants to register them with the primary tenant for identity.

Attach platform-as-a-service (PaaS) services that need end user identity. Some PaaS services, like Azure Files and Azure Virtual Desktop, depend on hybrid identity configuration or license entitlements. You must deploy these services to Azure subscriptions in the primary tenant.

Secondary tenants

You should implement the following recommendations in the secondary tenant.

Procure licenses required for Microsoft Entra management. You need licenses to turn on advanced security features in secondary tenants. Consider the licenses you need for users, workloads, and devices.

User identities. You need to have Microsoft Entra ID Premium P2 licenses for tenant administrators and emergency access accounts. If you use an external identity (B2B guest) management model, you must assign at least one Microsoft Entra ID Premium P2 license to a local user in the tenant. This setup allows you to enable premium features like Conditional Access and Identity Protection. For more information, see Common considerations for multitenant user management.

Workload identities. You should use workload identities premium to secure workload identities with access to resources in the primary tenant, such as MS Graph API.

Device management. You might need to manage devices with Microsoft Intune in the secondary tenant. If so, you need to procure Enterprise Mobility and Security (EMS) licenses.

Configure cross-tenant access policies (XTAP). Microsoft Entra External ID (Microsoft Entra B2B collaboration) cross-tenant access settings allow a secondary tenant to trust certain claims from the home primary tenant. Add the primary Microsoft Entra tenant as an organization and update the inbound trust settings to include:

• Trust multifactor authentication (MFA) from Microsoft Entra tenants
• Trust compliant devices
• Trust Microsoft Entra hybrid joined devices
• Optional: Automatically redeem invitations with the tenant

Manage the secondary tenant with identities from the primary tenant. Reduce administrative overhead and cost by using external users (B2B guests) from the primary tenant to manage the secondary tenant and Azure resources. Assign Microsoft Entra roles following least-privilege Microsoft Entra role by task using Microsoft Entra Privileged Identity Management. Use end-user initiated access or cross-tenant synchronization to reduce management overhead onboarding external identities in the secondary tenant.

Use Azure Lighthouse to facilitate Sentinel access from the primary tenant. Azure Lighthouse gives you another way to manage Azure across tenants. Azure Lighthouse uses Azure Resource Manager (ARM) templates to assign Azure roles to identities in an external tenant. This approach doesn't use B2B guest user objects. When an administrator signs in to the portal to manage Azure, they see all resources across all tenants. This consolidated view includes subscriptions with permissions assigned by Azure Lighthouse. Since there's no B2B guest object, the administrator doesn't need to switch directories. Use Azure Lighthouse to facilitate managing Microsoft Sentinel across tenants.

Next step

Related links

• Identity essentials
• Zero trust configurations
• Centralized security operations