conditional access gap analyzer

Microsoft Entra Conditional Access Policy options explained

Posted on by Imran Rashid
Reading Time: 37 minutes


In this blog post I examine each of the configuration options available when configuring an Entra ID Conditional Access policy. There are a lot of Conditional Access policy configuration options, so grab hold of a drink and fasten your seat belt. 🙂

What is Microsoft Entra ID Conditional Access?
Conditional access is an intelligent policy engine that helps organisations better control how users access corporate resources. It brings together real time signals such as user context, device, location, and session risk information to determine when to allow, block, or limit access, or require additional verification steps. Use conditional access policies to check the device health and security posture of registered devices and ensure only healthy and trusted devices can access your corporate resources.

Conditional access takes in over 40TB of identity related security signals and analyses them using machine learning to determine the appropriate policy to apply to a resource.


Still confused about what Conditional Access has to offer? Let’s simplify Conditional Access further before we go through the options.

Conditional Access policies at their simplest are if-then statements; IF a user wants to access a resource, THEN they must meet certain requirements or complete an action. For example, if a user wants to access an application such as a Microsoft 365 application, then they must perform multifactor authentication (MFA) to gain access. Another example, IF a user is accessing a company application, THEN they must log in from a Windows 11 compliant device. These are just a couple of examples, Conditional Access offers a lot more and I’ll be going through what each configuration option inside a Conditional Access policy means. If you want to learn more about Conditional Access, visit the following link, What is Conditional Access.

Note: It is important that you plan your policies carefully to avoid undesirable results.

Let’s get started.

How do I access Conditional Access?
A great place to start would be knowing how to get to Entra Conditional Access.

There are a a number of ways to access Conditional Access. We’ll be focusing on two common places including access via entra.microsoft.com and the Azure portal at portal.azure.com

1. Entra portal: Visit entra.microsoft.com, expand Protection (from the left pane) and click Conditional Access.

2. Azure Portal: Visit portal.azure.com, search for Entra ID and click to access Entra ID. Click Security (under the Protect menu) from the left pane, and click Conditional Access.

Is conditional access free?
No, Conditional Access in Microsoft Entra ID is a premium feature which requires a minimum of Entra ID P1 licenses. However, if you wish to configure certain features, such as Identity Protection (user risk and sign risk detection), you will require Entra ID P2 licenses. User risk and Sign-in risks are configured within Conditional Access. I’ll cover the options later in this post. You can click the following link to learn more about Identity Protection, What is Identity Protection?

To summarise, Conditional Access is a licensed feature and requires a minimum of P1 licenses in most cases, however, certain features require P2 licenses.

Conditional Access policy options explained

Important note before we continue
It is important that you plan your policies carefully to avoid undesirable results. The purpose of this post is to go through the configuration options available in a Conditional Access policy. To learn more about Conditional Access policy best practices, visit the following link, Conditional Access Policy Recommendations.

For the purpose of this post, I will be accessing conditional access via entra.microsoft.com

1. Click the option to create a new Conditional Access policy as shown in the image below.
Access via entra.microsoft.com > expand Protection from the left pane and click Conditional Access.

2. This will get you started with an empty Conditional Access policy as shown in the image below.

Policy name


Give your policy a name, for example, for demo purposes I could use a name of Require multifactor for admins or Block legacy authentication.

There are recommendations for policy naming conventions from Microsoft that you may wish to consider when naming your policies, or you may have your own naming format. A properly defined naming convention helps you and your colleagues understand the purpose of a policy, which enables easier policy management and troubleshooting.

The recommended naming policy is based on personas, policy types, and apps. It looks like this:

<CANumber>-<Persona>-<PolicyType>-<App>-<Platform>-<GrantControl>-<OptionalDescription>

For example,

CA001-Admins-IdentityProtection-AdminPortals-AnyPlatform-AllowCompliantDeviceMFA

Whatever naming format you use, ensure it is easy to understand the purpose of the policy name.


Here is the link for further details, Conditional Access framework and policies.

Assignments

This is where you configure to whom you would like this policy to apply.

Click the option, O users and groups selected, as shown in the image below,


The below options will become available to you.

Options in image below show,

Tab: Include
– None
– All users
– Select users and groups



Tab: Exclude
– Guest or external users
– Directory roles
– Users and groups

There are a few options available. You could apply the policy to all users but be careful as the warning below advises.

Warning: Don’t lock yourself out! This policy will affect all of your users. We recommend applying a policy to a small set of users first to verify it behaves as expected.



It is important to understand that depending on the type of policy, you could block yourself and all admins from logging in. A call to Microsoft support maybe required to allow you back into the portal which is a task you want to avoid, as it could be a lengthy process.

Note: Microsoft offer a what-if tool which allows you test the impact of a policy if applied. Furthermore, there is also an option to enable the policy in report only mode. Both options can help you audit/test prior to enabling policies. I will discuss these options later in this post.

You also have the options to assign the policy to guest users, specific Entra ID directory roles or select users or groups from inside your organisation. Directory roles are built in Entra ID roles, such as Global Administrators, User Administrators and more. A list of all built in Entra ID roles including permissions each role is granted are documented at the following link, Microsoft Entra ID built-in roles.


The exclude option could be used to exclude certain users or roles from the policy. For example, depending on the type of policy, you may wish to exclude admins or break glass accounts.

Break glass accounts
It is important that you prevent being accidentally locked out of your Microsoft Entra organisation, because you won’t be able to sign in or activate another user’s account as an administrator if a policy blocks all access. You can mitigate the impact of accidental lack of administrative access by creating two or more emergency access accounts in your organisation. It is recommended to add the break glass accounts into a security group and then exclude the group. For more information on the importance of break glass accounts and how to monitor them, click the following link Azure Emergency Break Glass Accounts.


Guest or external users
Before moving onto the next tab, I would like to cover a few options available under Guests and external users.


When configuring a Conditional Access policy, you have granular control over the types of external users you want to apply the policy to. External users are categorised based on how they authenticate (internally or externally) and their relationship to your organisation (guest or member). The options available in the drop down down list include:

B2B collaboration guest users
This is your general guest account, where you invite a guest from outside your Entra ID tenant. For example, you may wish to invite someone who will be assisting you with a project.

B2B collaboration member users 
This B2B collaboration user has an account in an external Microsoft Entra organisation or an external identity provider (such as a social identity), however they have member level access to resources in your organisation. This scenario is common in organisations consisting of multiple tenants, where users are considered part of the larger organisation and need member level access to resources in the organisation’s other tenants. The user object created in Microsoft Entra directory has a user type of Member and not guest like the one we covered above.

B2B direct connect users 
B2B direct connect is a new way to collaborate with other Microsoft Entra organisations. This feature currently works with Microsoft Teams shared channels. With B2B direct connect, you create two way trust relationships with other Microsoft Entra organisations to allow users to seamlessly sign in to your shared resources and vice versa. B2B direct connect users aren’t added as guests to your Microsoft Entra directory. When two organisations mutually enable B2B direct connect, users authenticate in their home organisation and receive a token from the resource organisation for access. You’re basically creating a trust between two Entra ID environments without having to provision guest accounts in each tenant.

I have covered B2B collaboration previously in the two posts below.

Post 1: Entra ID cross-tenant access
Post 2: Azure Entra ID B2B External Collaboration Settings Explained.

Local guest users
Local guest users have credentials that are managed in your directory. Before Microsoft Entra B2B collaboration was available, it was common to collaborate with distributors, suppliers, vendors, and others by setting up internal credentials for them and designating them as guests by setting the user object User Type to Guest. This is still possible. You can create a user account and a password in your Entra ID Directory but configure the user as a guest so they don’t receive the permissions that a member/employee would receive in your organisation. This provides the guest with a user ID from your organisation, for example user@imranrashid.co.uk but limited to guest permissions instead of permissions an employee would receive as a member user. To learn more about default guest permissions, visit the links I posted above.

Service provider users
These are organisations that serve as cloud service providers for your organisation. An organisation that manages your Azure platform on your behalf. The isServiceProvider property in Microsoft Graph is set to true. If the value is not set to true and is null, these settings inherit the behavior configured in your default cross tenant access settings.

Other external users
Applies to any users who don’t fall into the above categories, but who aren’t considered internal members of your organisation, meaning they don’t authenticate internally via Microsoft Entra ID, and the user object created in the resource Microsoft Entra directory doesn’t have a User Type of Member.

Target resources

Here we can configure what cloud apps we wish to target.


Click No target resources selected as shown in the image above. This will direct you to the area where you can control target resources as shown in the image below.


Be careful when selecting specific cloud apps as this could cause a problem when new apps are added to your environment in future as they will not be included and therefore won’t be protected. You may want to include all apps so it covers all apps and automatically include any new apps you introduce in the future. Be careful when pushing out a policy to all cloud apps so you don’t lock yourself out as the warning suggests below. I’ll discuss ways to test your policies before pushing them out to production later in this post. Make use of exclusions and exclude accounts such as break glass accounts as I mentioned earlier. This will ensure that you have a way to log back into the environment to investigate and resolve the issue.

For the purpose of this demo I’ll be selecting an individual cloud app so I can go through a few of the options available.


Click the option Select Apps and click None under Select


I could select Office 365,


This means whatever policy I configure would apply to 365 applications, such as:

I could also include my own Entra ID registered applications or utilise the built-in Entra ID applications. These could be my own apps where I have utilised Entra ID as an identity solution, allowing my users to login using their existing login account. For example, the same account they use to login to 365 services such as Teams, Exchange Online, SharePoint online and so on.

Microsoft Admin Portals

I could select Microsoft Admin Portals as shown in the image below.


Microsoft Admin Portals would apply the policy to all admin portals, listed below at the time of writing this post. For example, I could create a policy that requires admins to go through MFA before being allowed to login to any of the below admin portals.

Source: Microsoft website

Microsoft Azure Management

Microsoft Azure Management covers access to the Azure Portal, portal.azure.com and the Microsoft Entra admin centre, along with other services, such as Azure Resource Manager, Azure Data Lake, Applications Insights API, Log Analytics API, Azure Powershell, Azure CLI, Azure DevOps and more. A complete list is available at the following link, Microsoft Azure Management.


Intune enrollment

Another example, you may want to specify that if an admin attempts to enroll a device into Intune, they must go through Multi Factor Authentication.


That’s just a few cloud apps. Note that only 30 results are listed, however, using the search box, you can search for additional apps, such as Salesforce. See image below.


As always, you could also use the exclude option to remove certain apps from this policy.


There is an Edit Filter option available under Cloud Apps as per the screenshot below. This option allows you to use Entra ID Custom Security attributes as part of your conditional access policies. Why would you use this? For example, you could create and apply a Security Attribute for users who are security cleared or have a certain certification. Then use this option in conditional access to only allow access to a sensitive application for users who are certified. I published a post on Custom Security Attributes. Click the following link to learn more, Microsoft Entra ID Custom Security Attributes.


Here are the options I have available as I have previously created a custom security attribute in Entra ID.


User actions


There are two options available when clicking user actions,


Register security information:
Prior to combined registration, users registered authentication methods for Microsoft Entra multifactor authentication and self service password reset (SSPR) as two separate tasks. This caused confusion as similar methods were used for multifactor authentication and SSPR. Microsoft introduced combined registration, allowing users to register once and get the benefits of both multifactor authentication and SSPR.

A scenario where you could utilise the option Register Security Information is if an organisation would like to enforce users registering for Microsoft Entra multifactor authentication and SSPR from a central/trusted location like an office instead of from an untrusted location, or from a compliant device and so on. I’ll cover the compliant device option later.

Register or join devices:
An organisation may wish to enable this policy to enforce MFA (Multi Factor Authentication) for users registering or joining devices to Entra ID. This provides an extra layer of security. Previously, prompting a user for MFA prior to a device being joined to Entra ID was possible, however, this was a global setting via Identity > Devices > Overview > Device Settings. This option available in conditional access allows additional granular control.

Global Security Access (Preview)


What is Entra Global Security Access?
Global Security Access is a feature recently introduced and still in preview at the time of writing this post. At its core, Microsoft Entra Global Secure Access serves as a gateway, allowing users to connect to corporate applications, data, and services securely, regardless of their physical location. It has two major components including Microsoft Entra Internet Access and Microsoft Entra Private Access.

Microsoft Entra Private Access
You may be familiar with Application Proxy. Thousands of customers use it to access private web apps hosted on-premises. Entra Private Access is the premium version of Application Proxy, where Microsoft have extended those components to do much more. Entra Private Access allows users to access resources located on-premises without requiring a VPN client. As mentioned above, it’s a premium version of Application Proxy, however, with private access we can access non web based services, such as SSH, RDP, SMB, TCP/UDP based applications and http/https. Entra ID App Proxy only supports web applications.

Microsoft Entra Internet Access
Microsoft Entra Internet Access is a Secure Web Gateway (SWG) offering secure access for internet, SaaS (Software as a Service), and M365 (Microsoft 365) apps and resources whilst protecting your users from internet threats. The Internet traffic can be managed through traffic profiles. It’s basically designed to protect your users from threats on the Internet. For example, you can block access to all external destinations for your high risk users or non compliant devices except self service password reset pages. It also extends the conditions of Conditional Access with network conditions. This would prevent, for example, a stolen access session token from being replayed by requiring a user to be on a compliant network to access resources. We discuss compliant networks later.

Administrators can use Conditional Access policies to secure traffic profiles. They can mix and match controls as needed like requiring multifactor authentication, requiring a compliant device, or defining an acceptable sign-in risk. For more information, visit the following link, Universal Conditional Access through Global Secure Access and What is Global Secure Access (Preview).

Authentication context


Authentication context is used to secure data and actions in applications such as SharePoint, Microsoft Defender for Cloud Apps (MDCA), and Entra ID Privileged Identity Management.

For this to work, we first create a Authentication Context via Conditional Access and then clicking Authentication Context from the left pane. We can then create a Conditional Access Policy and select the newly created authentication context. The conditional access policy could be configured with additional options such as require MFA or require the device to be Entra ID joined.

But why would we do this? well, now that we have created a conditional access policy we could assign this to services such as Azure Privileged Identity Management (PIM). A new option is available in PIM which allows you to integrate role activation to use conditional access via a authentication context. Previously, a user could activate a high privileged role using MFA only. With authentication context we can now use Conditional Access policies so that a high privileged role can only be activated by the user if the users device is marked as complaint and the device is Entra ID joined, or if the user is using passwordless. We have a lot more control with authentication context.

If you’re wondering where this option is available in PIM, see image below. Thanks to authentication context we can now secure the process of activating a role combined with conditional access.


Another use case of authentication context
An organisation may keep files in SharePoint sites like the lunch menu or their top secret chilli sauce recipe. Everyone may have access to the lunch menu site, but users who have access to the top secret chilli sauce recipe site may need to access the ingredients from a managed device and agree to specific terms of use. You could apply the authentication context to a site or using Microsoft Purview sensitivity labels to apply the authentication context to labeled sites. More info including license requirements, implementation instructions and limitations are available at the following link Conditional access policy for SharePoint sites.

The option to configure authentication contexts is available from the left pane.

Conditions

Back to the options on the left, we have conditions


Click O conditions selected to go into the configurable options as shown in the image above.

User Risk and Sign-in risks are features of Entra Identity Protection (P2 license feature if you wish to enable automated user remediation). Microsoft Entra ID Protection helps organisations detect, investigate, and remediate identity based risks. For example, if a sign-in risk is detected, where a user is trying to sign in from an anonymous IP address, or from an unknown location where they have never logged in from before or other suspicious behavior, Identity Protection could prompt the users to prove that it is really them who is logging in by requesting for MFA. With Conditional Access policies you can configure the detection of user and sign-in risks based on low, medium and high risk. You can learn more about this feature at the following link, What is Identity Protection

Note: Microsoft recommend you configure User risk and Sign-risk via conditional access policies instead of using the legacy identity protection pane which is due to be retired October 1, 2026. The migration process from legacy Entra Identity Protection to Conditional Access can be found at the following link, Migrate Risks Policies from Entra ID Protection to Conditional Access.


An image of the legacy Entra ID Protection portal is shown below with the following message,

“We recommend migrating user risk policy to Conditional Access for more conditions and controls.”


You would receive a similar message when clicking Sign-in risk policy from the left pane.

“We recommend migrating sign-in risk policy to Conditional Access for more conditions and controls.”


User risk and Sign-in risks via Conditional Access

User risk and Sign-in risks should be configured in Conditional Access as shown in the images below.


Insider risk (preview)

At the time of writing this post, Insider risk was a new option available in Conditional Access.

Before discussing this new option available inside Conditional Access, it’s important to know that Insider Risk Management is part of Microsoft Purview. Insider risk is more than just a security problem as it involves insiders who already have access to your environment. The majority of data breaches resulting in data theft, around 63% of all incidents, are caused by people, insiders, working inside your organisation. Source: Rethinking Security from the Inside, Microsoft.

With all the activities that your employees and vendors perform in Microsoft 365 each day, it can be difficult to know which ones might be posing a risk to your organisation. This is where Insider Risk Management can help detect a broad range of user activities across Microsoft 365, allowing you to investigate those activities to identify potential risks. This can be performed whilst anonymising user names if needed to help meet privacy standards. When setting Insider Risk for the first time, you can perform a scan to detect recent user activities across Microsoft 365 locations. When completed, you can review anonymised potential risks, for example, files were shared externally by 3% of users, 1% copied sensitive data to a USB, 2% of users sent email externally and more. Based on the results, Inside Risk Management can recommend data theft and data leak policies to set up. Once you have decided what types of risk activities you wish to detect, you can setup your first policy by selecting a policy template, for example, Data Theft, Data Leaks or Security Policy Violations related to the activity you want to track. You then add the users whose activity you want to analyse and select indicators such as the ones below. You can track activity across SharePoint, Teams, 3rd party apps and more.

  • Deleting files, such as SharePoint files.
  • Unusual number of downloads
  • Copy files to USB
  • Email sensitive Information
  • Add external users to sensitive teams
  • Delete sensitivity labels
  • Multiple failed logins
  • Send sensitive message
  • Downloading content from OneDrive
  • Sharing SharePoint files with people outside of your organisation
  • Using a browser to upload files to the web
  • Printing files
  • Reading sensitive files on a device
  • Files copied to remote desktop session
  • and more.

Next, you select a triggering event which determines when the policy starts assigning risk scores to a user’s activity, such as events based on a user resignation trigger, poor performance trigger, job level change trigger and more. For example, if you selected the template for data theft template, you can trigger a policy to assign a risk score when a resignation date is added for a user by HR.

When a triggered event is detected, for example a user has submitted their notice to resign in 4 weeks time and that user performs an activity which matches the policy threshold, such as downloading data from SharePoint, an alert appears including which activities the user performed, including risks scores assigned to each activity, for example,

Deletion: Files were deleted – Risk score 80/100
Exfiltration: Files were printed – Risk score 50/100
Collection: Files were downloaded from SharePoint – Risk score 31/100
Obfuscation: Files were renamed – Risk score 24/100
Sequence: Files exfiltrated and cleaned up – 90/100

You can further dig down and explore which files names, location such as SharePoint, device name, any applied sensitivity labels (such as Confidential), sensitive info types (such as Credit Card Number) and more.

If an alert needs to be investigated further, you can create a case to dive deeper and identify the activities which is also capable of creating workflows, for example, automatically creating a Microsoft Team to help you collaborate with others who can assist with the investigation. You can review all activity related to the user from a single pane of glass. If a further legal review is required you can escalate the case to create an advanced eDiscovery case where legal teams can review and take further action.

So back to the topic 🙂

How does this work with Conditional Access and how can we stop such threats?
With the new Insider Risk condition in Microsoft Entra’s Conditional Access. Insider risk protections which is powered by the existing adaptive protection available as part of Microsoft Purview, ensure that users can access resources as usual when their risk level is low. However, if something changes to elevate their insider risk level, access to critical assets can be blocked automatically. This is powerful in situations where the user inside of your organisation is the perpetrator of a data breach versus an external threat that has compromised the user account. Insider risk assigns an insider risk level to a user across three tiers, minor, moderate, and elevated, and policy controls can be defined for each risk level. For example, if specified, a user with an elevated risk can be automatically blocked from accessing Microsoft 365, SaaS apps, and even your on prem resources. 

This new feature within Conditional Access can also be combined with other options available within Conditional Access, such as user risk and sign-in risk part of Identity Protection incase there is a genuine attempt to compromise the user’s account or the likelihood the users sign-in has been compromised. You can also include other conditions such as the users device, location, private access and so on.


We have three options available inside Conditional Access including Elevated, Moderate or Minor.

Elevated:
For example, you may wish to automatically block access to critical assets when insider risk levels are at an elevated level, ensuring data security and compliance. A user today may be marked as moderate or minor, but in future they hand in their resignation which raises their risk level to elevated. They now decide to connect to an on-premises virtual machine to put in place software on a machine which can serve as a jump box allowing them to connect to resources after they leave the company. Insider Risk in Conditional Access combined with with Entra Private Access (covered earlier in this post) could block access to the on-premises machine.

Moderate:
User performed activities that might indicate a moderate degree of risk. While not as severe as an elevated risk, you may still take appropriate actions to prevent further risky activity from occurring such as requesting passwordless authentication and asking the user to accept a data terms of use so they can acknowledge the company policy before continuing into an application such as Salesforce. I’ll cover setting up terms of use later in this post.

Minor:
User performed activities that might indicate a minimal degree of risk.

Device platforms

This options allows you to select what devices you require your policy to apply or exclude.

For example, apply the policy to IOS (iphone, Ipad) devices only.

Note: Conditional Access identifies the device platform by using information provided by the device, such as user agent strings. Since user agent strings can be modified, this information is unverified. Device platform should be used along with Microsoft Intune device compliance policies or as part of a block statement.

Microsoft recommends that you have a Conditional Access policy for unsupported device platforms. As an example, if you want to block access to your corporate resources from Chrome OS or any other unsupported clients, you should configure a policy with a Device platforms condition that includes any device and excludes supported device platforms and Grant control set to Block access.

Locations

Here we can assign a policy based on a location.

These named locations could include the public IPv4 or IPv6, country/region, unknown areas that don’t map to specific countries/regions, and Global Secure Access compliant network.


You could also create a custom trusted locations list, for example, including office IP addresses. This can then be included in your Conditional Access policy. To setup a locations list, go back to the conditional access overview page and click named locations under the Manage section in the left pane.


You can then select Countries location or IP ranges location.


What is All Compliant Network locations (in preview)


This feature was in preview at the time of writing. If it’s not visible it’s because you have not enabled Global Secure Access. I provided an explanation of this service further up in this post.

Organisations who use Conditional Access along with Global Secure Access can prevent malicious access to Microsoft apps, third party SaaS apps, and your business apps using multiple conditions to provide defense in depth. These conditions may include device compliance, location, and more to provide protection against user identity or token theft. Global Secure Access introduces the concept of a compliant network within Conditional Access and continuous access evaluation. This compliant network check ensures users connect from a verified network connectivity model for their specific tenant and are compliant with security policies enforced by administrators. You can configure custom policies that, for example, would block access to resources unless connected to the Microsoft Security Service Edge which is part of Global Secure Access.

More info and configuration steps on how to activate Global Secure Access in your tenant is available at the following link, Enable compliant network check with Conditional Access

Note: Global Secure Access was in preview at the time of writing this post.

Client apps


Modern Authentication Clients


Modern authentication clients include web-based applications that use security protocols such as SAML, WS-Federation or Open ID Connect. These are modern authentication methods supported in Entra ID.

Legacy Authentication Clients


Sign-in from legacy authentication clients don’t support multifactor authentication (MFA) so can bypass MFA. MFA is a common requirement to improve security posture in organisations. It’s recommended that legacy authentication is disabled if possible. If you have accounts which must use legacy authentication, you must either exclude those accounts from the policy, or configure the policy to only apply to modern authentication clients. Legacy authentication clients include older office clients and mail protocols (POP, IMAP, SMTP and MAPI). Legacy authentication protocols can’t enforce MFA, making them preferred entry points for adversaries attacking your organisation.

Based on Microsoft’s analysis more than 97 percent of credential stuffing attacks use legacy authentication and more than 99 percent of password spray attacks use legacy authentication protocols. These attacks would stop with basic authentication disabled or blocked.

Filter for devices

Filter for devices allow you to apply policies to devices based on a criteria. For example, you could specify to apply a policy to machines using certain operating systems, device manufacturer, model and more. You’ll find a number of built in properties in the list, however, you can also create your own custom attributes, known as extensions.

Authentication flows (Preview)

Authentication flows was in preview at the time of writing this post. Authentication flows include two configurable options, Device code flow and Authentication transfer.

Device code flow
Use case: you’re on a device which is not able to perform self authentication, for example, you are not able to open a browser, and instead you have to use command based access such as Azure CLI using the command az login –use-device-code.

When you use a device flow on that device, for example using a command as mentioned above, the device will generate a code and will provide a url. That url can now be accessed from a different device where browser access is available. You access the provided URL and input the code, login with an account you wish to authenticate with such as your Entra ID account, and the session is authenticated from that secondary device on behalf of the original device.

Note: You should only allow device code flow where necessary. Microsoft recommends BLOCKING device code flow wherever possible. Device code flow can be prone to a phishing attack, for example a bad actor calls a user and says I am from “Microsoft” and we have noticed some unusual activity on your account. I need to confirm that I am talking to the user and not someone else. The bad actor could trick the user by providing them the code they generated and ask the user to authenticate the code using their identity. The bad actor has now been authenticated and acting as the user.

Authentication transfer
Use case: Authentication transfer is a way to transfer authenticated state from one device to another. For example, you could be presented with a QR code within the desktop version of Outlook that, when scanned on your mobile device, transfers the authenticated state to the mobile device via the Authenticator App. This is not as prone to a phishing attack compared to a device code flow, but it can still be used in a phishing attack, for example, a bad actor asks you to send them a picture of the QR code.

Note: you should block Authentication transfer unless there is a requirement.

In Conditional Access we can block the above capability for all cloud apps and all users (excluding certain accounts). However, we could allow where there are reasons to do so by securing the process further by enabling additional checks such as is the machine compliant.


Check Authentication Transfer and Device Code Flow Logs
If you wish to check if you’re using device code flows or Authentication transfers in your organisation, you can check this within the Entra ID sign-in logs by filtering for Authentication Protocol and Device Code or Authentication Transfer. Further logs can be collected by filtering for Original transfer method and then click Device code flow or Authentication transfer.

Grant

Back to the left pane, we have grant. This is the THEN part of Conditional Access. Here is where we configure what we want the policy to do IF conditions are met.

We can block or grant access.

Let’s go through the available options.

Require multifactor authentication

The user must perform Multi Factor Authentication such as authenticating via the Authenticator App, phone call or text before they are allowed to proceed with signing in.

Require Authentication Strength

Authentication strengths can enforce that only phishing resistant authentication methods be used to access a sensitive resource. For example, a HR user wishes to use a HR app which includes sensitive data. You could force HR users to use a FIDO2 Yubi Key to authenticate. We can choose from three built in authentication strengths including Multifactor authentication strength, Passwordless MFA strength, and Phishing resistant MFA strength. We can also create a custom authentication strength based on the authentication method combinations we want, for example, you don’t wish to use SMS and voice call based MFA, but instead you enforce that users use Authenticator App or Phishing resistant authentication methods such as FIDO2 and Windows Hello For Business. The advantage of Authentication Strengths is that we can mix authentication strengths as needed and then use Conditional Access to apply them.


You can create custom strengths or view the built in ones by clicking Authentications Strengths from the left pane.

Require device to be marked as compliant
Organisations that deploy Intune can use the information returned from their devices to identify devices that meet specific policy compliance requirements. Intune sends compliance information to Microsoft Entra ID so Conditional Access can decide to grant or block access to resources based on the state of the device, for example, the device must have Windows 10 or above installed, must have Endpoint protection installed and so on. You could base your Conditional Access policy on the status of a device such as organisation owned and users personal devices, and if the device is compliant. If not, you may decide to block or provide reduced access to your organisational resources.

Require Microsoft Entra hybrid joined device

Microsoft Entra hybrid joined devices are joined to your on-premises Active Directory and also registered with Microsoft Entra ID. Organisations can require that user devices are Microsoft Entra hybrid joined or access is not granted.

Require approved client app


Note: The approved client app option is retiring in early March 2026. Organisations have until March 2026 to migrate to Application Protection Policy. Covered in the next section below.

After March 2026, Microsoft will stop enforcing require approved client app control, and it will be as if this grant isn’t selected. Use the following steps to migrate to App Protection Policy before March 2026 to protect your organisation’s data. Migrate approved client app to application protection policy.


The following client apps support approved client app.

Source: Grant controls in Conditional Access policy

Require app protection policy

App protection policies come from Intune and are rules that ensure an organisation’s data remains safe or contained in a managed app so users can not copy and paste data outside of your organisation applications, such as preventing the saving of company app data to a personal storage location. Furthermore, you can use app protection policies to require a mobile pin or finger print before a user accesses corporate email on their personal or business device. For more information and additional capabilities of app protection policies visit the following link App protection policies overview – Microsoft Intune.

In Conditional Access policy, you can require that an Intune app protection policy is present on the client app before access is available to the selected applications. If an Intune app protection policy is not present, access could be denied.


A further link appears under the option Require app protection policy advising that there is a list of policy protected client apps this control supports. Below is the current list.

Source: Grant controls in Conditional Access policy – Microsoft Entra ID

For multiple controls – require all the selected controls or require one of the selected controls

Specify whether you wish for all selected controls to apply, for example, the device must be compliant and MFA (Multi Factor Authentication) is required, or the user needs to meet one of the conditions, either MFA or the device must be compliant.

Session

Back to the left pane, we continue to session controls.


and we have the following options



Use app enforced restrictions


This configuration only supports Office 365, Exchange Online and SharePoint Online. The reason why the below option is greyed out is because I need to go back to the Cloud App settings and select 365, Exchange Online or SharePoint from the drop down list. Note that before configuring app enforced restrictions there are steps you need to take for Exchange Online or SharePoint online.

So what does this setting do in Conditional Access? you could prevent users from downloading email attachments from an outlook browser that your user may access from a non company managed device. If a user attempts to login to Outlook online from a non company device and attempts to download an attachment, they would be presented with a message such as the one below.

“Your organisation doesn’t allow you to download or print attachments from this device or browser. You can still view the attachments in your browser, For more information, contact your IT administrator“

For SharePoint, this control within Conditional Access could disable the download option if a user attempted to access SharePoint online from a non company managed device.


Use Conditional Access App Control

This feature integrates with Defender for Cloud Apps


It allows you to add additional control to SaaS (Software as a Service) third party applications in Entra ID, such as SalesForce, or you could apply the policy to Microsoft cloud apps such as Microsoft Teams.

You could setup a policy that integrates with a policy inside Defender for Cloud Apps, for example,

If a user attempts to access Salesforce from an unmanaged device, prompt them for MFA, however provide them with limited access to Salesforce only, and prevent the download of PDFs within Sales Force.

Another example could be,

If a user attempts to download a Word Document containing certain keywords, wrap the document with a sensitivity label of confidential which could then implement restrictions to the document such as preventing the user from copy/paste, printing and download.


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 Microsoft Entra ID default configuration for user sign-in frequency is a rolling window of 90 days. Asking users for credentials often seems like a sensible thing to do, but it can backfire. Users that are trained to enter their credentials without thinking can unintentionally supply them to a malicious credential prompt. It might sound alarming to not ask for a user to sign back in, in reality any violation of IT policies will revoke the session anyway. Some examples include (but aren’t limited to) a password change, an incompliant device, or account disable. The Microsoft Entra ID default configuration comes down to “don’t ask users to provide their credentials if security posture of their sessions didn’t change.”

However, depending on your requirements, you could override the default 90 day sign-in frequency.



Persistent browsing

A persistent browser session allows users to remain signed in after closing and reopening their browser window. Persistent browser only works correctly when all cloud apps have been selected. If the option is greyed out, it’s because you have not applied the policy to all cloud apps.


Customize continuous access evaluation (CAE)


In Entra ID, Azure uses OAUTH 2.0 as one of it’s authentication protocols and is one of the standards used to authorise users and applications to Entra ID. During the authentication process a device receives a refresh and access token. The access token includes the user identity information and has a default lifetime of 60 – 90 minutes. If an incident occurs and you need to disable the user, Continuous Access Evaluation (CAE), a feature enabled by default and for free allows access tokens to be revoked based on critical events and policy evaluation in real time rather than relying on token expiration at the end of the 60 -90 minute time frame. CAE was made generally available in January 2022. Here is the announcement link, Continuous Access Evaluation in Azure AD is now generally available! – Microsoft Community Hub

Continuous access evaluation currently evaluates and can revoke the token when a

  • user account is deleted or disabled
  • password for a user is changed or reset
  • multifactor authentication is enabled for the user
  • administrator explicitly revokes all refresh tokens for a user
  • high user risk detected by Microsoft Entra ID Protection
  • Change of location

However, for customers licensed to use Conditional Access (with Entra P1 licenses), CAE can be configured further, such as being disabled (not recommended) or configuring the new locations setting (in preview) as seen in the image above. There are a number of key benefits CAE brings:

  • when a user account is disabled or the password is changed, the user session revocation is enforced in near real time. Enabled by default and for free for all customers.

  • network location change: Conditional Access location policies are enforced in near real time. You could assign the policy to a trusted named location. If a laptop is taken from a trusted location and the bad actor attempts to open your cloud app and access company data, they would be prevented from doing so due to a change in IP address. This may be a little difficult to configure especially if users are working from different locations.

  • Token export to a machine outside of a trusted network can be prevented with Conditional Access location policies (Strictly enforce location policies in preview at the time of writing). Token export could refer to a bad actor stealing the users access token and replaying it on a different device. The bad actor may steal the token by sending the user a phishing email including a link which when clicked resembles the Microsoft sign-in page. The user inputs their details and the bad actor retrieves the token.

Note: this feature does not currently support all services, visit the following link for limitations.

Note: Continuous Access Evaluation (CAE) does not currently support report-only mode. More on report-only mode later.


Disable resilience defaults


Resilience defaults are automatically enabled for all new and existing policies, and Microsoft highly recommends leaving the resilience defaults enabled to mitigate the impact of an outage (don’t click the option to disable). Admins may disable resilience defaults for individual Conditional Access policies.

What is the purpose of resilience defaults? Let’s find out.

If there was an outage of the primary authentication service, the Microsoft Entra Backup Authentication Service (Resilience Defaults) would automatically issue access tokens to applications for existing sessions when the 60 – 90 minute access token expires. This functionality may significantly increase Microsoft Entra resilience, because reauthentications for existing sessions account for more than 90% of authentications to Microsoft Entra ID, meaning most of your users would continue working without issues.

The Backup Authentication Service doesn’t support new sessions or authentications by users, so if there was an outage, new users/sessions would not be able to authenticate. However, as mentioned above, existing users would who are already logged in and have had an access token and refresh token issued would not be affected. Clicking to disable this feature within Conditional Access means that you don’t wish to use the backup service in the event there was an issue with Entra ID. If resilience defaults are disabled and there is an outage with the Microsoft Authentication service, access will be denied for all users once existing tokens/sessions expire.

For more information on how this service works under the hood, click the following link, Resilience defaults for Microsoft Entra Conditional Access.


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 replaying a token, 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.

Token protection creates a cryptographically secure tie between the token and the device (client secret) it’s issued to. Without the client secret, the bound token is useless. When a user registers a Windows 10 or newer device in Microsoft Entra ID, their primary identity is bound to the device. Therefore if a bad actor steals the token and attempts to replay it on a new device, it will not work.

Report-only mode

Enabling a policy in report-only mode will allow you to evaluate the impact of Conditional Access policies before enabling them in your environment. You can review the reports in Entra ID sign-in logs and after you feel confident that the policy will not cause issues, you can switch the policy to on. Off will disable the policy.

Create new policy from Microsoft provided templates

Conditional Access templates provide a convenient method to deploy new policies aligned with Microsoft recommendations. These templates are designed to provide maximum protection aligned with commonly used policies across various customer types and locations. Basically, instead of you having to create a policy manually, most of the work has been done for you via Microsoft provided templates that you can review and apply to your environment.

Conditional Access Coverage

This tab will provide you with statistics on top applications with and without conditional access coverage in the last 7 days. This can give you an idea of where you’re not applying Conditional Access policies.


Another useful tool is the Conditional Access gap analyser workbook. With the Conditional Access gap analyser workbook you can detect gaps in your Conditional Access implementation. This is great as it provides you with an overview of where you may not have applied Conditional Access Policies. As an IT administrator, you want to ensure that your Conditional Access policies work as expected to ensure that your resources are properly protected as missing resources could pose a security risk. This workbook highlights user sign-ins that have no Conditional Access policies applied to them and allows you to ensure that there are no users, applications, or locations that have been unintentionally excluded from Conditional Access policies.

To access this workbook,

  1. Access entra.microsoft.com
  2. From the left pane expand Identity
  3. Click to expand Monitoring & Health
  4. Click Workbooks
  5. Here you can access a number of different workbooks including Conditional Access Gap Analyzer

What if

The Conditional Access What If policy tool allows you to understand the result of Conditional Access policies in your environment. Instead of test driving your policies by deploying a a policy to production and then performing multiple sign-in tests manually, this tool enables you to evaluate a simulated sign-in of a user. The simulation estimates the result this sign-in has on your policies and generates a report. The benefit is that you get an idea of what the result will be, for example, if a user logs in from a Windows 11 device which is not compliant and logs in from a specific location.

  1. To access the What if tool, click Policies from the left pane


2. and then click What if


Here you can test the impact of your policy before enabling.

Custom controls (Preview)

Update May 2nd 2024:
The new External authentication methods announced on 2nd of May 2024 and in public preview at the time of writing are the replacement of custom controls, and they provide several benefits over the custom controls approach. These include:

  1. External authentication method integration, which uses industry standards and supports an open model, supporting a larger number of third party providers.
  2. This feature will allow you to use your preferred multifactor authentication (MFA) solution with Entra ID.  Some organizations have already deployed MFA and want to reuse that MFA solution with Entra ID. External authentication methods allows organizations to reuse any MFA solution to meet the MFA requirement with Entra ID.
  3. External authentication methods are managed the same way as Entra methods
  4. External authentication methods are supported for a wide range of Entra ID use cases (including PIM activation)

Here is the article: Public preview: External authentication methods in Microsoft Entra ID – Microsoft Community Hub

I explore Custom Controls below, however, the new External authentication methods announced on 2nd of May 2024 and in public preview at the time of writing this post are the replacement of custom controls below. See note titled Update May 2nd 2024 above.


Custom controls were in preview at the time of writing and there are still a number of limitations and ongoing changes.

When using custom controls, your users can be redirected to a compatible service to satisfy authentication requirements outside of Microsoft Entra ID. When a user attempts to sign-in, they can be redirected to a third party, perform authentication and return to Microsoft Entra ID for validation before the user is allowed to continue.

As per a blog post Alex Simons at Microsoft, there was an announcement that in future it may be possible to use Custom Controls to redirect to a third party MFA (Multi Factor Authentication) solution. Here is the post, Upcoming changes to Custom Controls – Microsoft Community Hub. Note that preview features can be removed and there is no guarantee that it will make it to GA (General Availability).

Custom Controls works with a limited set of approved authentication providers. Each non Microsoft provider has its own process and requirements to sign up, subscribe, or otherwise become a part of the service. At that point, the provider gives you a block of data in JSON format. This data allows the provider and Conditional Access to work together for your tenant, creates the new control and defines how Conditional Access can tell if your users have successfully performed verification with the provider.

Terms of use

Terms of use policies provide a simple method to present information to end users. Organisations can use Terms of use along with Conditional Access policies to require employees or guests to accept your Terms of use policy before they are allowed access.


After creating a policy, a Terms of use checkbox will appear in the grant control list when creating a Conditional Access policy as per the image below. If selected, users would need to accept Terms and conditions before being able to access your applications.

VPN connectivity


With Microsoft Entra Conditional Access for virtual private network (VPN) connectivity, you can help protect your VPN connections. You can enforce Conditional Access to remote users who connect in to your environment using VPN. For example, prompting users for MFA, ensure a device is compliant, restrict to locations and more.

Here is where you would create the certificate.


For more information on VPN integration with Conditional Access, visit the following link, Configure conditional access for VPN connectivity using Microsoft Entra ID

Insights and reporting

This workbook was designed to help admins understand the impact of their Conditional Access policies by aggregating sign-in results. The Conditional Access insights and reporting workbook enables you to understand the impact of Conditional Access policies in your organisation over time. During sign-in, one or more Conditional Access policies might apply, granting access if certain grant controls are satisfied or denying access otherwise. Because multiple Conditional Access policies might be evaluated during each sign-in, the insights and reporting workbook lets you examine the impact of an individual policy or a subset of all policies. This feature requires that you setup a Log Analytics Workspace to store the data and once data is gathered over time, you’re presented with a dashboard and statistics allowing you to review past and ongoing Conditional Access policy data.

and before we end this post, here are a few Conditional Access policy configurations to avoid.

Conditional Access policy configurations to avoid

  • Block access for ALL, including users, cloud apps and all platforms. You don’t want to be blocking your entire organisation.

  • Require ALL devices to be marked as compliant for all users and cloud apps
    For users who have not yet enrolled their devices, this policy blocks all access including access to the Intune portal. If you are an administrator without an enrolled device, this policy blocks you from getting back into the Azure portal to change the policy.

  • Require Hybrid Microsoft Entra ID domain joined device for all users and cloud apps
    This access blocking policy has the potential to block access for all users in your organisation if they don’t have a hybrid Microsoft Entra ID joined device.

  • Require app protection policy for all users and cloud apps
    This access blocking policy has the potential to block access for all users in your organisation if you don’t have an Intune policy. If you are an administrator without a client application that has an Intune app protection policy, this policy blocks you from getting back into portals such as Intune and Azure.

and that’s it.

I hope you found this post useful. If you have any questions or feedback, please feel free to comment below.

Thank you and see you at the next post 🙂