Identity-driven security is a core pillar of our Zero Trust model.
Identities define the Zero Trust security boundary, and we use identity as the primary factor in how we allow access to corporate resources. When an identity tries to access any resource, we verify that identity with strong authentication, and we ensure that access is compliant and follows the access patterns typical for that identity. We also confirm that the identity follows least-privilege access principles.
With these processes in place, verified identity contributes to the broader framework for Zero Trust, alongside the other pillars of verified devices, verified access, and verified services.
[Check out verifying devices in a Zero Trust model. | Read more about implementing a Zero Trust security model at Microsoft.]
Unifying the identity environment
A unified identity environment is crucial to verified identity in our Zero Trust model. To enable a single user identity for authentication and offer a unified experience, we integrated on-premises Windows Server Active Directory forests with Microsoft Azure Active Directory (Azure AD). Azure AD provides a centralized, cloud-based identity directory on which all our identity-related processes depend. We use Azure AD Connect and Microsoft Azure Active Directory Federation Services (AD FS) to unify identity data within Azure AD so that Microsoft Azure–based applications can confirm the individual user attributes that make up an identity—location, organization, or job title, for example.
Every employee or partner who needs access to corporate resources is assigned an identity that is synchronized to Microsoft Azure AD and gives the user access to corporate resources, Microsoft Office 365, Microsoft software as a service (SaaS) applications, and third-party SaaS and platform as a service (PaaS) applications.
A key part of our business is working closely with partner companies. To enable more seamless collaboration with our partners, we’re pioneering a new multifactor authentication feature to mitigate multiple credential prompts that some users experienced. Previously, external users who had already authenticated with a second factor in their home tenant were prompted again for a different two-factor authentication to access internal Microsoft resources. Now, if our external partner has already signed in to their home tenant using multifactor authentication, they won’t encounter a separate multifactor authentication prompt when accessing our Microsoft resources.
Goals for verifying identity in Zero Trust
Our internal security team and the Microsoft Digital Employee Experience team’s approach to verified identity is rooted in three primary goals specifically related to human-based identities as they’re stored in our unified identity environment:
- Ensure that strong identity is verified and enforced.
- Eliminate password-focused authentication in favor of biometrics.
- Limit access to resources based on job function by using least-privilege access principles.
Enforcing strong identity
Enforcing strong identity depends on a centralized, modern, cloud-based directory solution, which we have in Microsoft Azure AD. Azure AD helps us bridge our cloud and on-premises identities by using Microsoft Azure AD Connect and AD FS, and it provides key functionality for enforcing strong identity across our hybrid environment:
- Microsoft Defender for Identity: We use Defender for Identity to monitor our on-premises Microsoft Active Directory signals to identify, detect, and investigate advanced threats and compromised identities. Defender for Identity supplies invaluable insights on identity configurations and suggested security best practices. Defender for Identity helps us dramatically reduce the attack surface area, making it more difficult for attackers to compromise user credentials and advance an attack.
- Integrate Microsoft Azure Advanced Threat Protection with Microsoft Cloud App Security: We use Microsoft Azure Advanced Threat Protection to identify risky user behavior when users access on-premises, nonmodern resources, such as file shares. This behavior analysis is factored into overall user risk assessment to block further access in the cloud.
- Application integration with Microsoft Azure AD: We require all applications to integrate with Azure AD by using OAuth 2.0 with the most up-to-date Microsoft Authentication Library (MSAL) We also use an extensive single-sign on store to enable strong authentication for third-party applications.
- Multifactor authentication: We require multifactor authentication to verify a user’s identity before giving them access to corporate resources when they’re not connected to the corporate network. People use multifactor authentication in a few ways, including Windows Hello for Business with PIN or biometric sign-in and Microsoft Azure AD multifactor authentication that uses a phone or the Microsoft Authenticator app. On domain-joined devices that we manage, multifactor authentication has become almost transparent to users.
Reducing dependency on passwords
Reducing password dependency to eliminate password usage has been in process at Microsoft for some time. Deploying a companywide strategy for eliminating passwords wasn’t easy, but it also wasn’t as complicated as many organizations might think it is. The goal isn’t to eliminate password data but to reduce the need for the user to repeatedly use that password as part of the authentication process. We’re working toward eliminating passwords at Microsoft by using several platforms and technologies:
- Multifactor authentication: Multifactor authentication is critical in reducing password usage. In Microsoft Azure AD, multifactor authentication enables the necessary factors for removing the password requirement for authentication. We widely use Azure AD multifactor authentication, Microsoft Authenticator, and Windows Hello for Business to facilitate multifactor authentication, but we also use other technology to enable multifactor authentication across a wide scope of platforms and use cases. For example, we use Fast Identity Online (FIDO) keys as a replacement for biometric data in Windows Hello and smart cards to control administrative access.
- Windows Hello for Business: We’re using two-factor biometric authentication with Windows Hello for Business. This adds another dimension to the multifactor authentication environment across Windows 10 and Windows 11 devices and enables our users to replace password data with biometric data, such as a fingerprint. We’re using Windows Hello for Business to support smart card–like scenarios by using a certificate-based deployment, which provides easy certificate renewal and remote-access compatibility.
- Modernized hardware: Modernizing our hardware portfolio was an important part of enabling multifactor authentication and Windows Hello for Business capability, both of which rely on technologies such as Trusted Platform Module (TPM) 2.0 and FIDO 2.0 for core biometrics support.
Limiting access to data with least-privilege access
Implementing least-privilege access reduces the attack surface area for our identities with elevated privileges and ensures that our employees are always granted the level of access they require to perform the tasks their role requires. By default, identities begin with no access. In the least-privilege access model, systems grant access only when needed. Applications, services, and infrastructure only provide the minimum set of access required by their users. Our approach to least-privilege access involves several focal points:
- Reduce the impact of a compromised identity by progressively eliminating unnecessary access.
- Simplify implementation: Pursue complex implementation only when it corresponds with significant risk reduction, as with administrative accounts or high-risk environments.
- Invest in simplifying access-administration solutions for users and application owners.
- Prioritize central, preventative controls over distributed manual configurations.
- Prioritize a cloud-first approach, where the Zero Trust model is strongest and most active.
The first step in implementing least-privilege was the identification and classification of those roles that absolutely required elevated access. However, not all elevated-privilege accounts are created equal. Limiting the attack surface visible to potential aggressors depends not only on reducing the number of elevated-privilege accounts. It also relies on only providing elevated-privilege accounts with the least-privilege access needed to get their respective jobs done.
We can provide conditional access to applications with AD FS rules. We can vary the granularity of how we enforce multifactor authentication at an application level. AD FS is flexible and allows us to designate people or groups that can access an application, and how they must authenticate when they’re on or outside the corporate network. Most users who access applications from the corporate network are allowed single-factor authentication, while users who access applications from the internet require multifactor authentication. Some applications are so critical that they require multifactor authentication even when the user accesses them from the corporate network.
Identity is a primary factor in determining access to corporate resources in the Zero Trust model. By enforcing strong identities, reducing dependency on passwords, and limiting access to data by using least-privilege access, we’re creating an identity framework on which the entire Zero Trust model rests. As we continue to strengthen our processes for verifying identity throughout our digital estate, we’re strengthening the remaining three pillars: device, access, and services, and, in turn, the entire Zero Trust model.
