Implement Conditional Access policies
- 10 minutes
Conditional Access is a feature of Microsoft Entra ID that allows administrators to control who can access the organization's resources based on certain conditions. These conditions can include the user's identity, device, location, network, app, and risk level. Conditional Access policies can help protect the organization from unauthorized or risky access, while providing a seamless experience for the users.
Microsoft 365 uses Conditional Access policies to evaluate each sign-in attempt and apply the appropriate access controls based on the policy settings. For example, a policy can require users to perform multifactor authentication when they sign in from outside the corporate network, or block access to certain apps from unmanaged devices. Conditional Access policies can also use the Microsoft Entra ID Protection service, which detects and responds to sign-in risks based on machine learning and behavioral analytics.
Conditional Access policies can be customized to suit the needs and security requirements of different organizations. For example, a small to medium-sized business might create the following Conditional Access policies:
- A policy that requires all users to register for multifactor authentication within 14 days of their first sign-in. This policy can help improve the security posture of the organization by enabling a second factor of authentication for all users.
- A policy that blocks access to SharePoint Online and OneDrive from devices that aren't compliant with the organization's device management policy. This policy can help prevent data leakage from devices that aren't secure or up to date.
- A policy that grants access to Exchange Online only from the Outlook app and requires app protection policy. This policy can help protect the organization's email data from unauthorized or malicious apps.
Conditional Access policies at their simplest are if-then statements. If a user wants to access a resource, then they must complete an action. For example, consider a payroll manager who wants to access the company's payroll application. Before the manager can access the application, they must have multifactor authentication turned on.
Administrators have two primary goals: empower users to be productive regardless of location or time, and protect their organization's assets. By using Conditional Access policies, you can apply the right access controls when needed to keep your organization secure and stay out of your user's way when not needed.
Conditional Access also extends its capabilities to Microsoft 365 services. For example, organizations can use Conditional Access with Microsoft Intune compliance policies. This combination can control the devices and apps that connect to your email and company resources. When integrated, you can gate access to keep your corporate data secure. This design gives users an experience that allows them to do their best work from any device, and from any location.
Note
Conditional Access is a Microsoft Entra ID capability that requires a Microsoft Entra Premium P1 license. To find the right license for your requirements, see Compare generally available features of Microsoft Entra ID. Customers with Microsoft 365 Business Premium licenses can also access Conditional Access features.
Through Microsoft Entra ID, Conditional Access brings signals together to make decisions, and enforce organizational policies. Intune enhances this capability by adding mobile device compliance and mobile app management data to the solution. Common signals include:
- User or group membership.
- IP location information.
- Device details, including device compliance or configuration status.
- Application details, including requiring use of managed apps to access corporate data.
- Real-time and calculated risk detection, when you also use a mobile threat defense partner.
Important
The system enforces Conditional Access policies after it completes first-factor authentication. Microsoft 365 doesn't intend Conditional Access to be an organization's frontline of defense for scenarios like denial-of-service (DoS) attacks. However, it can use signals from these events to determine access.
Conditional Access integrated with Microsoft Defender for Endpoint and Microsoft Intune
When devices exceed the threat level set by their organization, the Conditional Access service in Microsoft Entra ID can block their access to corporate resources, such as SharePoint Online or Exchange Online. This service enforces Conditional Access policies for Microsoft 365 and other Microsoft cloud services. When Microsoft Defender for Endpoint deems a device noncompliant, the Conditional Access service receives a notification and can take action to block access to corporate resources for that device.
In summary:
- Microsoft Defender for Endpoint provides the threat intelligence and risk assessment data the Conditional Access service uses to determine whether a device is compliant.
- Microsoft Intune deploys compliance policies to devices and ensures they meet the required security standards.
- The Conditional Access service in Microsoft Entra ID blocks devices that exceed the threat level set by an organization.
Conditional Access works with Intune device configuration and compliance policies, and with Intune Application protection policies.
Device-based Conditional Access. Intune and Microsoft Entra ID work together to make sure only managed and compliant devices can access email, Microsoft 365 services, Software as a service (SaaS) apps, and on-premises apps. You can also set a policy in Microsoft Entra ID to enable only domain-joined computers or mobile devices enrolled in Intune to access Microsoft 365 services. These policies include:
- Conditional Access based on network access control
- Conditional Access based on device risk
- Conditional Access for Windows PCs (both corporate-owned and bring your own device (BYOD))
- Conditional Access for on-premises Exchange Server
For more information, see device-based Conditional Access with Intune.
App-based Conditional Access. Intune and Microsoft Entra ID work together to make sure only managed apps can access corporate e-mail or other Microsoft 365 services. For more information, see app-based Conditional Access with Intune.
Common signals
Common signals that Conditional Access can take into account when making a policy decision include:
User or group membership
- Conditional Access can target policies to specific users and groups. This design gives administrators detailed control over access.
IP Location information
- Organizations can create trusted IP address ranges that Conditional Access uses when making policy decisions.
- Administrators can specify entire countries/regions IP ranges to block or allow traffic from.
Device
- Conditional Access can enforce policies for users with devices of specific platforms or marked with a specific state.
- Use filters for devices to target policies to specific devices like privileged access workstations.
Application
- Users attempting to access specific applications can trigger different Conditional Access policies.
Real-time and calculated risk detection
- Signals integration with Microsoft Entra Identity Protection allows Conditional Access policies to identify risky sign-in behavior. Policies can then force users to change their password, do multifactor authentication to reduce their risk level, or block access until an administrator takes manual action.
Microsoft Defender for Cloud Apps
- Monitors and controls user application access and sessions in real time. This feature increases visibility and control over access to and activities done within your cloud environment.
Common decisions
Common decisions built into Conditional Access policies include:
Block access
- Most restrictive decision
Grant access
Least restrictive decision. It can still require one or more of the following options:
- Require multifactor authentication.
- Require that a device is marked as compliant.
- Require that a device is Hybrid Microsoft Entra-joined.
- Require an approved client app.
Common Conditional Access policies
Many organizations have common access concerns that Conditional Access policies can help with. These common Conditional Access policies include:
- Require multifactor authentication for users with administrative roles.
- Require multifactor authentication for Azure management tasks.
- Block sign-ins for users attempting to use legacy authentication protocols.
- Require Microsoft Entra multifactor authentication for all users.
- Require Microsoft Entra multifactor authentication for Azure management.
- Require Microsoft Entra multifactor authentication for risky sign-in.
- Require password change for risky users.
- Require compliant or hybrid-joined devices.
- Require organization-managed devices for specific applications.
- Require approved app or app protection policy.
- Block or granting access from specific locations.
- Block risky sign-in behaviors.
Create a Conditional Access policy
Complete the following steps to create a Conditional Access policy based on device compliance:
You must begin by navigating to the Microsoft Intune admin center. To do so, on the Microsoft 365 admin center, select Show all in the navigation pane. Under the Admin centers group, select Endpoint Manager.
In the Microsoft Intune admin center, select Endpoint security in the left-hand navigation pane.
On the Endpoint security | Overview page, under the Manage section in the middle pane, select Conditional Access.
On the Conditional Access | Policies page, select +New policy on the menu bar.
On the New page, enter a policy Name. Then define the Assignments and Access controls associated with the policy. For example:
Under the Assignments section:
Under Users, an administrator can include a user, group, or workload identity assignment as one of the signals in the decision process. These identities can be included or excluded from Conditional Access policies. The following options are available:
None
All users
Select users and groups
- Guest or external users
- Directory roles
- Users and groups
Under Target resources, an administrator can assign controls to specific applications, services, actions, or authentication context. Administrators can:
- Choose from the list of applications or services that include built-in Microsoft applications and any Microsoft Entra integrated applications including gallery, non-gallery, and applications published through Application Proxy. For example, the Windows Azure Service Management API suite groups several Azure tools together, such as the Azure portal, Azure PowerShell, Azure CLI, Visual Studio Code extension, REST API, and Client SDKs.
- Choose to define policy on a user action like Register security information or Register or join devices rather than on a cloud application. Doing so allows Conditional Access to enforce controls around those actions.
- Target traffic forwarding profiles from Global Secure Access for enhanced functionality.
- Use authentication context to provide an extra layer of security in applications.
Under Network, an administrator can target specific network locations as a signal. They can include or exclude these locations as part of their policy configuration. These networks might include public IPv4 or IPv6 network information, countries/regions, unknown areas that don't map to specific couintries/regions, or Global Secure Access' compliant network. Organizations might use these locations to require multifactor authentication for users accessing a service when they're off the corporate network. Or, they may use locations to block access from specific countries/regions their organization never operates from. A user's location is found using their public IP address or the GPS coordinates provided by the Microsoft Authenticator app. Conditional Access policies apply to all locations by default. When you configure the location condition, you can distinguish between:
Any network or location. By default, selecting Any location causes a policy to apply to all IP addresses, which means any address on the Internet. This setting isn't limited to IP addresses you configure as named locations. When you select Any location, you can still exclude specific locations from a policy. For example, you can apply a policy to all locations except trusted locations to set the scope to all locations, except the corporate network.
All trusted networks and locations. This option applies to all locations marked as trusted locations and multifactor authentication trusted IPs, if configured.
Multifactor authentication trusted IPs. Using the trusted IP section of multifactor authentication's service settings is no longer recommended. This control only accepts IPv4 addresses and should only be used for specific scenarios covered in the article Configure Microsoft Entra multifactor authentication settings. If you have these trusted IPs configured, they show up as MFA Trusted IPs in the list of locations for the location condition.
All compliant network locations. Organizations with access to Global Secure Access preview features have another location listed that is made up of users and devices that comply with your organization's security policies. For more information, see the section Enable Global Secure Access signaling for Conditional Access. It can be used with Conditional Access policies to perform a compliant network check for access to resources.
Selected networks and locations. With this option, you can select one or more named locations. For a policy with this setting to apply, a user must connect from any of the selected locations. When you choose Select, you're presented with a list of defined locations. For each location, the list displays the location's name, type, and whether the network location is marked as trusted. Locations are defined and exist in the Microsoft Entra admin center under Protection > Conditional Access > Named locations. Named locations can include locations like an organization's headquarters network ranges, VPN network ranges, or ranges that you wish to block. Named locations contain IPv4 address ranges, IPv6 address ranges, or countries/regions.
IP ranges. When defining a named location using public IPv4 or IPv6 address ranges, it's necessary to provide a name for the location and at least one public IP range. You can mark the location as a trusted location if desired. Let's say your corporate headquarters is in Paris, France, and you want to mark this office as a trusted location and exclude it from a conditional access policy. In this scenario, the most suitable Named Location option is IP ranges because it allows you to specify the exact network ranges used by your Paris office. As such, only devices within those ranges are recognized as trusted. Keep in mind, however, that certain restrictions apply to this IP ranges option.
- A maximum of 195 named locations can be established, and each named location can contain no more than 2000 IP ranges.
- Only CIDR masks greater than /8 are permitted when you specify an IP range.
- For devices within a private network, you should use the IP address the network uses to connect to the public internet, such as 198.51.100.3. You shouldn't use the IP address of the user's device on the intranet, such as 10.55.99.3.
Trusted locations. An administrator can designate IP-based locations as trusted, such as their organization's public network ranges. However, once an administrator marks a location as trusted, they can't remove the location until they revoke the trusted status. The "trusted location" designation plays a role in various features. For example:
- Conditional Access policies can be configured to either include or exclude trusted locations.
- When sign-ins occur from trusted named locations, it enhances the precision of risk calculations performed by Microsoft Entra ID Protection.
Countries/regions. Organizations can ascertain a geographic country/regional location by using IP addresses or GPS coordinates. Keep in mind that if you're looking to target an office in a specific city or location, then the IP ranges option would be more suitable than the Countries/regions options. How so? Consider the earlier example that wanted to exclude the corporate headquarters in Paris, France, from a conditional access policy. In this example, using the Countries/regions option would trust all sign-ins from France rather than just the Paris office. The following features apply to this option:
- To establish a named location based on country/region, it's essential to supply a name for the location.
- You must then decide whether to define the country/region by IP address or GPS coordinates. Once you make that decision, you can then add one or more countries/regions to the named location.
- You can also include unknown countries/regions if desired. Some IP addresses don't map to a specific country/region. To capture these IP locations, select the Include unknown countries/regions option when defining a geographic location. This option allows you to choose if these IP addresses should be included in the named location.
Under Conditions, an administrator can make use of one or more signals to enhance their policy decisions. Multiple conditions can be combined to create fine-grained and specific Conditional Access policies. When users access a sensitive application, an administrator might factor multiple conditions into their access decisions like:
- Sign-in risk information from ID Protection
- Network location
- Device information
Under the Access controls section:
Under Grant, an administrator can use access controls to grant or block access to resources.
Block access. The control for blocking access considers any assignments and prevents access based on the Conditional Access policy configuration. Block access is a powerful control that you should apply with appropriate knowledge. Policies with block statements can have unintended side effects. Proper testing and validation are vital before you enable the control at scale. Administrators should use tools such as Conditional Access report-only mode and the What If tool in Conditional Access when making changes.
Grant access. Administrators can choose to enforce one or more controls when granting access. By default, Conditional Access requires all selected controls. These controls include the following options:
Under Session, an administrator can make use of session controls to enable limited experiences within specific cloud applications. The available controls include:
Application enforced restrictions. Organizations can use this control to require Microsoft Entra ID to pass device information to the selected cloud apps. The device information allows cloud apps to know if a connection is from a compliant or domain-joined device and update the session experience.
Conditional Access application control. Conditional Access App Control allows you to enforce access controls on your organization’s apps based on certain conditions. The conditions define what user or group of users, cloud apps, and locations and networks a Conditional Access policy applies to. After you determine the conditions, you can route users to Microsoft Defender for Cloud Apps where you can protect data with Conditional Access App Control by applying access and session controls. Conditional Access App Control enables user app access and sessions to be monitored and controlled in real time based on access and session policies. Access and session policies are used within the Defender for Cloud Apps portal to refine filters and set actions to take.
Sign-in frequency. Sign-in frequency defines the time period before a user is asked to sign in again when attempting to access a resource. Administrators can select a period of time (hours or days) or choose to require reauthentication every time. The Sign-in frequency setting works with apps that implement OAUTH2 or OIDC protocols according to the standards. Most Microsoft-native applications for Windows, Mac, and Mobile, including the following applications, follow this setting:
- Word, Excel, PowerPoint Online
- OneNote Online
- Office.com
- Microsoft 365 Admin portal
- Exchange Online
- SharePoint and OneDrive
- Teams web client
- Dynamics CRM Online
- Azure portal
Persistent browser session. A persistent browser session allows users to remain signed in after closing and reopening their browser window.
Customize continuous access evaluation. Continuous access evaluation is automatically enabled as part of an organization's Conditional Access policies. For organizations who wish to disable continuous access evaluation, this configuration is now an option within the session control within Conditional Access. Continuous access evaluation policies can be scoped to all users or specific users and groups.
Disable resilience defaults. During an outage, Microsoft Entra ID extends access to existing sessions while enforcing Conditional Access policies. If resilience defaults are disabled, access is denied once existing sessions expire.
Require token protection for sign-in sessions (Preview). Token protection (sometimes referred to as token binding in the industry) attempts to reduce attacks using token theft by ensuring a token is usable only from the intended device. When an attacker is able to steal a token, by hijacking or replay, they can impersonate their victim until the token expires or is revoked. Token theft is thought to be a relatively rare event, but the damage from it can be significant.
Require Global Secure Access security profile (Preview). Using a security profile with Conditional Access unifies identity controls with network security in Microsoft's Security Service Edge (SSE) product, Microsoft Entra Internet Access. Selecting this Session control allows you to bring identity and context awareness to security profiles, which are groupings of various policies created and managed in Global Secure Access.
Under the Enable policy section, you can select one of the following options:
Report-only. Report-only mode enables administrators to evaluate the impact of Conditional Access policies before enabling them in their environment.
- Conditional Access policies can be evaluated in report-only mode except for items included in the "User Actions" scope.
- During sign-in, policies in report-only mode are evaluated but not enforced.
- Results are logged in the Conditional Access and Report-only tabs of the Sign-in log details.
- Customers with an Azure Monitor subscription can monitor the impact of their Conditional Access policies using the Conditional Access insights workbook.
On. The policy is enabled.
Off. The policy isn't enabled.
Select Create once you finish reviewing and verifying the details. The new policy should appear in the list of Conditional Access policies. If it doesn't immediately appear, select the Refresh option on the menu bar.
Conditional Access authentication strength
Authentication strength is a Conditional Access control that specifies which combinations of authentication methods can be used to access a resource. Users can satisfy the strength requirements by authenticating with any of the allowed combinations. For example, an authentication strength can require that only phishing-resistant authentication methods be used to access a sensitive resource. To access a nonsensitive resource, administrators can create another authentication strength that allows less secure multifactor authentication (MFA) combinations, such as password + text message.
Authentication strength is based on the Authentication methods policy, where administrators can scope authentication methods for specific users and groups to be used across Microsoft Entra ID federated applications. Authentication strength allows further control over the usage of these methods based upon specific scenarios such as sensitive resource access, user risk, location, and more.
Authentication strengths can help customers address these scenarios:
- Require specific authentication methods to access a sensitive resource.
- Require a specific authentication method when a user takes a sensitive action within an application (in combination with Conditional Access authentication context).
- Require users to use a specific authentication method when they access sensitive applications outside of the corporate network.
- Require more secure authentication methods for users at high risk.
- Require specific authentication methods from guest users who access a resource tenant (in combination with cross-tenant settings).
Administrators can specify an authentication strength to access a resource by creating a Conditional Access policy with the Require authentication strength control. They can choose from three built-in authentication strengths:
Multifactor Authentication strength. MFA requires users to provide two or more forms of authentication before accessing a resource. It enhances security by combining different factors (for example, something the user knows, something the user has, or something the user is).
- Use case. This option is ideal for scenarios where strong security is essential, such as accessing sensitive data or critical applications.
- Example methods. Password + text message, smart card + PIN, biometric + PIN.
Passwordless MFA strength. Passwordless MFA eliminates the need for traditional passwords. Users authenticate using alternative methods, such as biometrics or security keys.
- Use case. Enhances convenience and security by removing reliance on passwords.
- Example methods. FIDO2 security keys, Windows Hello biometrics.
Phishing-resistant MFA strength. This strength focuses on preventing phishing attacks. It encourages the use of methods that are less susceptible to phishing attempts.
- Use case. Protects against credential theft due to phishing.
- Example methods. FIDO2 security keys (which are resistant to phishing), Windows Hello biometric
You can also create a custom authentication strength based on the authentication method combinations you want to allow.
Built-in authentication strengths
Built-in authentication strengths are combinations of authentication methods that Microsoft predefined. Built-in authentication strengths are always available and can't be modified. Microsoft updates built-in authentication strengths as new methods become available.
The combinations of authentication methods for each built-in authentication strength are listed in the following diagram. These combinations include methods that users must register and that are enabled in the Authentication methods policy or the legacy MFA settings policy.
How an authentication strength policy is evaluated during sign-in
The authentication strength Conditional Access policy defines which methods can be used. Microsoft Entra ID checks the policy during sign-in to determine the user’s access to the resource. For example, an administrator configures a Conditional Access policy with a custom authentication strength that requires a passkey (FIDO2 security key) or Password + text message. The user accesses a resource protected by this policy.
During sign-in, all settings are checked to determine the following factors:
- The allowed methods.
- The registered methods.
- The methods the Conditional Access policy requires.
To sign in, the method must be:
- Allowed
- Registered by the user (either before or as part of the access request)
- Satisfy the authentication strength
When multiple Conditional Access policies apply for a sign-in, all conditions from all policies must be met. In the same vein, when multiple Conditional Access authentication strength policies apply to the sign-in, the user must satisfy all of the authentication strength conditions. For example, if two different authentication strength policies both require passkey (FIDO2), the user can use a FIDO2 security key to satisfy both policies. If the two authentication strength policies have different sets of methods, the user must use multiple methods to satisfy both policies.
The following factors determine if the user gains access to the resource:
- Which authentication method was previously used?
- Which methods are available for the authentication strength?
- Which methods are allowed for user sign-in in the Authentication methods policy?
- Is the user registered for any available method?
When a user accesses a resource protected by an authentication strength Conditional Access policy, Microsoft Entra ID evaluates if the methods they previously used satisfy the authentication strength. If a satisfactory method was used, Microsoft Entra ID grants access to the resource. For example, let's say a user signs in with password + text message. They access a resource protected by MFA authentication strength. In this case, the user can access the resource without another authentication prompt.
Let's suppose they next access a resource protected by Phishing-resistant MFA authentication strength. At this point, they're prompted to provide a phishing-resistant authentication method, such as Windows Hello for Business.
If the user didn't register for any methods that satisfy the authentication strength, they're redirected to combined registration. Users are required to register only one authentication method that satisfies the authentication strength requirement. If the authentication strength doesn't include a method that the user can register and use, the user is blocked from sign-in to the resource.
Knowledge check
Choose the best response for each of the questions below.