Implementing a Zero Trust security model at Microsoft

At Microsoft, our shift to a Zero Trust security model—which began more than seven years ago—has helped us navigate many challenges.

The increasing prevalence of cloud-based services, mobile computing, internet of things (IoT), and bring your own device (BYOD) in the workforce have changed the technology landscape for the modern enterprise. Security architectures that rely on network firewalls and virtual private networks (VPNs) to isolate and restrict access to corporate technology resources and services are no longer sufficient for a workforce that regularly requires access to applications and resources that exist beyond traditional corporate network boundaries.

The shift to the internet as the network of choice and the continuously evolving threats led us to adopt a Zero Trust security model internally here at Microsoft. Though our journey began many years ago, we expect that it will continue to evolve for years to come.

Carmichael Patton, a principal security architect at Microsoft, shares about the work that his team in the Chief Information Security Office (CISO) organization has been doing to support a Zero Trust security model.

The Zero Trust model

Based on the principle of verified trust—in order to trust, you must first verify—Zero Trust eliminates the inherent trust that is assumed inside the traditional corporate network. Zero Trust architecture reduces risk across all environments by establishing strong identity verification, validating device compliance prior to granting access, and ensuring least privilege access to only explicitly authorized resources.

Zero Trust requires that every transaction between systems (user identity, device, network, and applications) be validated and proven trustworthy before the transaction can occur. In an ideal Zero Trust environment, the following behaviors are required:

• Identities are validated and secure with phishing-resistant authentication (MFA) everywhere. Using phishing-resistant authentication eliminates password expirations and eventually will eliminate passwords. The added use of biometrics ensures strong authentication for user-backed identities.
• Devices are managed and validated as healthy. Device health validation is required. All device types and operating systems must meet a required minimum health state as a condition of access to any Microsoft resource.
• Telemetry is pervasive. Pervasive data and telemetry are used to understand the current security state, identify gaps in coverage, validate the impact of new controls, and correlate data across all applications and services in the environment. Robust and standardized auditing, monitoring, and telemetry capabilities are core requirements across users, devices, applications, services, and access patterns.
• Least privilege access is enforced. Limit access to only the applications, services, and infrastructure required to perform the job function. Access solutions that provide broad access to networks without segmentation or are scoped to specific resources, such as broad access VPN, must be eliminated.

Zero Trust scenarios

We have identified four core scenarios at Microsoft to help achieve Zero Trust. These scenarios satisfy the requirements for strong identity, enrollment in device management and device-health validation, alternative access for unmanaged devices, and validation of application health. The core scenarios are described here:

• Scenario 1: Applications and services have the mechanisms to validate multifactor authentication and device health.
• Scenario 2: Employees can enroll devices into a modern management system which guarantees the health of the device to control access to company resources.
• Scenario 3: Employees and business guests have a method to access corporate resources when not using a managed device.
• Scenario 4: Access to resources is limited to the minimum required—least privilege access—to perform a specified function.

Zero Trust scope and phases

We’re taking a structured approach toward Zero Trust, an effort that spans many technologies and organizations and requires investments that will carry over multiple years. The graphic below represents a high-level view of the Zero Trust goals—grouped into our core Zero Trust pillars—that we continually work toward.

While these goals don’t represent the full scope of the Zero Trust efforts and work streams, they capture the most significant areas of Zero Trust effort at Microsoft.

Pillars of the Microsoft Zero Trust model

Scope

Our initial scope for implementing Zero Trust focused on common corporate services used across our enterprise—our employees, partners, and vendors. Our Zero Trust implementation targeted the core set of applications that Microsoft employees use daily (e.g., Microsoft 365 apps, line-of-business apps) on platforms like iOS, Android, MacOS, Linux, and Windows. As we have progressed, our focus has expanded to include all applications used across Microsoft. Any corporate-owned or personal device that accesses company resources must be managed through our device management systems.

Verify identity

To begin enhancing security for the environment, we implemented MFA using smart cards to control administrative access to servers. We later expanded the multifactor authentication requirement to include all users accessing resources from outside the corporate network. The massive increase in mobile devices connecting to corporate resources pushed us to evolve our multifactor authentication system from physical smart cards to a phone-based challenge (phone-factor) and later into a more modern experience using the Microsoft Azure Authenticator application.

The next step in this area is the widespread deployment of Windows Hello for Business for biometric authentication. While Windows Hello hasn’t completely eliminated passwords in our environment, it has significantly reduced password usage and enabled us to remove our password-expiration policy. Additionally, multifactor authentication validation is required for all accounts, including guest accounts, when accessing Microsoft resources.

Our most recent efforts involve rolling out phishing-resistant authentication credentials through Passkey options in the Microsoft Authenticator app, with YUBIKeys as an option for limited-scale use cases. Additionally, all new employee onboarding is now run through a process for Passkey configuration, without the use of a password from day one.

Verify device

Our first step toward device verification was enrolling devices into a device-management system. We have since completed the rollout of device management for Windows, Mac, Linux, iOS, and Android. Many of our high-traffic applications and services, such as Microsoft 365 and VPN, enforce device health for user access.

Additionally, we’ve started using device management to enable proper device health validation, a foundational component that allows us to set and enforce health policies for devices accessing Microsoft resources. We’re using Windows Autopilot for device provisioning, which ensures that all new Windows devices delivered to employees are already enrolled in our modern device management system.

Devices accessing the corporate network must also be enrolled in the device-management system. This includes both Microsoft-owned devices and personal BYOD devices. If employees want to use their personal devices to access Microsoft resources, the devices must be enrolled and adhere to the same device-health policies that govern corporate-owned devices.

For devices where enrollment in device management isn’t an option, we’ve created a secure access model called Microsoft Azure Virtual Desktop. Virtual Desktop creates a session with a virtual machine that meets the device-management requirements. This allows individuals using unmanaged devices to securely access select Microsoft resources.

There is still work remaining within the verify device pillar. We’re in the process of maturing device management for Linux devices and expanding the number of applications enforcing device management to eventually include all applications and services. We’re expanding the number of resources available when connecting through the Virtual Desktop service. We’re also expanding to other devices, such as the Meta Quest headsets, conference room devices, and kiosks. Finally, we’re making device-health policies more robust and enabling validation across all applications and services.

Verify access

In the verify access pillar, we focused on segmenting users and devices across purpose-built networks, migrating all Microsoft employees to use the internet as the default network, and automatically routing users and devices to appropriate network segments. We successfully deployed several network segments, both for users and devices, including internet-default wired and wireless networks across all Microsoft buildings. All users received policy updates to their systems, thus making this internet-based network their new default.

As part of this network rollout, we deployed a device-registration portal. This portal allows users to self-identify, register, or modify devices to ensure that the devices connect to the appropriate network segment. Through this portal, users can register guest devices, user devices, and IoT devices.

We also created specialized segments, including purpose-built segments for the various IoT devices and scenarios used throughout the organization. We completed the migration of our highest-priority IoT devices in Microsoft offices into the appropriate segments.

Verify services

In the verify services pillar, our efforts center on enabling conditional access across all applications and services. To achieve full conditional access validation, a key effort requires modernizing legacy applications or implementing solutions for applications and services that can’t natively support conditional access systems. This has the added benefit of reducing the dependency on VPN and the corporate network.

Microsoft has adopted a hybrid workplace and a large percentage of our employees have transitioned to work from home. This shift has meant greatly increased use of remote network connectivity. Gradually, we have been able to successfully engage application owners in our plans to make applications and services accessible over the internet without VPN, and we’ve been able to transition 98% of our workloads to internet-facing services.

For those services that remain on-premises or are behind Azure Private Endpoints, we have enabled Azure VPN, which we’ve migrated from “always on” to manual access when a VPN is required. Our goal is to further reduce dependency on VPNs in order to restrict access to only required services, rather than the broader access that VPNs provide. We also further reduced the risk of lateral movement by implementing the Entra Secure Service Edge solution.  

Implementing Entra SSE allows us to provide secure tunnel access through Private Access and Internet Access for Microsoft Services. For Microsoft-specific SaaS solutions like Microsoft 365 and Microsoft Dynamics, the Internet Access for Microsoft Services gives us important functionality, including token protection and the ability to prevent man-in-the-middle (MitM) attacks.

We are also working on onboarding our on-premises and Private Endpoints through Private Access. In addition to helping deal with MitM attacks and token protection, this allows for direct service connections from the client to the service, without allowing broader access to other services that an employee should not have direct access to.

Zero Trust architecture with Microsoft services

The graphic below provides a simplified reference architecture for our approach to implementing Zero Trust. The primary components of this process are Intune for device management and device security policy configuration, Microsoft Entra Conditional Access for device health validation, and Microsoft Entra ID for user and device inventory.

The system works with Intune, by pushing device configuration requirements to the managed devices. The device then generates a statement of health, which is stored in Microsoft Entra ID. When the device user requests access to a resource, the device health state is verified as part of the authentication exchange with Microsoft Entra ID.

Microsoft Security Zero Trust access model

A transition that’s paying off

In our transition to a Zero Trust model, we continue to make consistent progress. Over the last several years, we’ve increased identity-authentication strength with expanded coverage of strong authentication, a transition to biometrics-based authentication by using Windows Hello for Business, and phishing-resistant credentials for all supported platforms. We’ve deployed device management and device-health validation capabilities across all major platforms. We’ve also launched a Windows Virtual Desktop system that provides secure access to company resources from unmanaged devices and is Zero Trust compliant by design.

As we continue our progress, we’re making ongoing investments in Zero Trust. We’re expanding health-validation capabilities across devices and applications, increasing the Virtual Desktop features to cover more use cases, and implementing better controls on our network. After reducing (and eliminating when possible) our dependencies on VPN, our next chapter is to migrate to a more modern secure tunnel per application.

Each enterprise that adopts Zero Trust will need to determine what approach best suits their unique environment. This includes balancing risk profiles with access methods, defining the scope for the implementation of Zero Trust in their environments, and determining what specific verifications they want to require for users to gain access to their company resources. In all of this, encouraging the organization-wide embrace of Zero Trust is critical to success, no matter where you decide to begin your transition.