Understand network, service, and tenant isolation in Microsoft 365

  • 6 minutes

Breach boundaries are a key security principle that informs the design of Microsoft 365. Microsoft 365 services are built on shared infrastructure and are designed to prevent the actions of one tenant from affecting the security or accessing the content of other tenants. Microsoft 365 leverages network, service, and tenant isolation to create breach boundaries in our services, preventing a compromise of one boundary from leading to compromise in others.

Network and service isolation

The goal of network isolation is to restrict the ability of different parts of the Microsoft 365 service infrastructure from communicating with each other except for the minimum necessary for the service to operate. Microsoft 365 services inter-operate with each other but are designed and implemented so they can be deployed and operated as autonomous, independent services. In addition, customer traffic in online services is isolated from our corporate network. Combined with other controls, such as our Zero Standing Access implementation of least privilege, network, and service isolation allow us to establish breach boundaries between services and service components within Microsoft 365.

At its core, network isolation in Microsoft 365 is designed to block unnecessary and unauthorized traffic between service components and network segments. Network isolation is not only about preventing unwanted authentication from one service to another. It also helps our services defend against unauthenticated attacks. Some of the most dangerous zero-day exploits involve unauthenticated remote code execution (RCE) that exploits sensitive network paths between machines. The ability to establish a connection with a target before authentication is attempted must be as restricted as possible. Strong network isolation in Microsoft 365 provides critical protection against these types of attacks.

Microsoft cloud infrastructure monitors and controls network traffic at external boundaries, key internal boundaries, and on hosts using access control lists (ACLs). ACLs are the preferred mechanism for restricting communications and are implemented using network devices such as routers, network and host-based firewalls, and Azure Network Security Groups (NSGs). Network traffic that does not fulfill an explicit operational need is denied by default. We closely scrutinize all network traffic rules as part of maintaining our architecture and data flow diagrams (DFDs). DFDs document approved network flows between service components, and help our engineers visualize network traffic patterns and restrict unnecessary traffic at the host, firewall, and router layers of the network.

When core Microsoft 365 services grow, traffic from newly provisioned capacity into previously established parts of the service is denied by default. Teams must manually open network paths that are necessary for a new service feature to operate, and we closely scrutinize any attempts to do so to ensure that only the minimal required paths are opened. Our key security principles are at play here; even freshly provisioned capacity is not trusted to be secure, and our network isolation policies are automatically applied as the service scales.

Tenant isolation

One of the primary benefits of cloud computing is the ability to leverage shared infrastructure across numerous customers simultaneously, leading to economies of scale. This concept is called multi-tenancy. Microsoft works continuously to ensure that the multi-tenant architectures of our cloud services support enterprise-level security, confidentiality, privacy, integrity, and availability standards. All customer content in Microsoft 365 tenants is isolated from other tenants and from operations and systems data used in the management of Microsoft 365. Multiple forms of protection are implemented throughout Microsoft 365 to minimize the risk of compromise of any Microsoft 365 service or application.

Microsoft cloud services were designed with the assumption that all tenants are potentially hostile to all other tenants. As a result, we have implemented security measures to prevent the actions of one tenant from affecting the security or accessing the content of another tenant. The two primary goals of maintaining tenant isolation in Microsoft 365 are:

  • Preventing leakage of, or unauthorized access to, customer content across tenants.
  • Preventing the actions of one tenant from adversely affecting the service for another tenant.

Logical isolation of customer content within each tenant is built into each service by design and achieved through Microsoft Entra ID and role-based access control. Specifically, each tenant container in Microsoft 365 is defined by the tenant's Organizational Unit (OU) in Microsoft Entra ID. Tenants have their own security boundaries and User Principal Names (UPNs) to prevent information leakage and unauthorized access between tenants. User authentication in Microsoft 365 verifies not only the user identity, but also the tenant identity the user account is part of, preventing users from accessing data outside their tenant environment. Tenant-specific encryption at the service level provides an additional layer of protection for each customer tenant.

Individual services may provide additional layers of tenant isolation at the data and application layers of the service. For example, SharePoint Online provides data isolation mechanisms at the storage level by encrypting and storing customer content in separate databases. Exchange Online requires authentication at the mailbox level and allows encryption of mailboxes with customer-managed encryption keys using Customer Key.

Learn more