Limiting Access When Critical Events Occur

Continuous access evaluation (CAE) is a feature that flew under the radar over the past two years. Even so, CAE for Azure Active Directory is an extremely important feature that will not only increase the security posture of your environment but reduce the amount of time before a user loses access to resources when certain critical events happen.

This article discusses the need for the feature and how to work with it. Before we dive into the Azure AD implementation, let’s take a step back and review the Azure AD authentication process.

Authentication Process in Azure AD

Azure AD uses OAuth 2.0 as one of its authentication protocols. OAuth stands for Open Authorization and is one of the standards used to authenticate users and applications to Azure AD. OAuth supports different authentication flows used for different scenarios (application login, device code login, etc.) The most common OAuth flow is the ‘auth code grant’, which is used when a user interactively logs in to a website or desktop application.

During the authentication process, the device receives a refresh and access token. An access token is shared in every request and is used to authenticate the user to the server. The access token contains information about the identity of the user (username, device information) and their permissions, and has a lifetime of 1 hour. To avoid the user needing to log in each hour, applications use the refresh token together with a valid access token to regenerate a new access token.

One Hour Can be a Long Time

The lifetime of an access token means a user can consume resources for one hour without the app needing to contact Azure AD. Therefore, if an administrator blocks a user’s account or updates their location (which might cause a Conditional Access policy to block them), it can take up to one hour before Azure AD locks the user account.

One hour can be especially problematic when urgent cases occur, such as an immediate dismissal of an employee. This hour could potentially give the user enough time to execute malicious actions or download confidential data. For more detail around how to block a user’s access to Office 365, refer to the article How to Block User Access to Office 365. Removing the validity of the access token is a critical step in blocking access.

Introducing Continual Access Evaluation for Microsoft 365

Continual access evaluation solves the problem by enabling a conversation between Azure AD and client applications. If the client application detects a change (such as a change in location), it notifies Azure AD and potentially invalidates the access token.

It also works the other way around: If Azure AD identifies a change (like the disabling of an account), it sends a message to the application to invalidate the current access token. This causes a reauthentication to Azure AD, which might result in the user being blocked or requiring a multifactor authentication approval.

During its preview, customers had the option to enable CAE selectively for sets of users or groups. Since becoming generally available in January 2022, CAE is now enabled on every tenant by default, but it can be disabled through Conditional Access. Having the feature enabled by default provides a huge value to organizations, as it ensures user access is governed as closely as possible and guarantees a user is blocked as soon as a change happens.

Capabilities Limited to Main M365 Workloads

While continual access evaluation is an excellent feature, it isn’t perfect. It doesn’t support every scenario, and not all workloads and applications support CAE. Currently, support for workloads is limited to Microsoft Teams, SharePoint, and Exchange Online.

Support for CAE is also limited in terms of clients. While the most common applications, such as Outlook (both Desktop and clients) and the Microsoft 365 web apps support CAE, support is lacking in certain use cases. Take the OneDrive sync client on Windows, for example – one of the applications which doesn’t support CAE. So, if an organization doesn’t realize these limitations exist, they might develop a false sense of security thinking CAE is supporting all scenarios and clients.

Personally, I would like to see Microsoft broaden the scope for CAE support in the future. Especially since many organizations enable Azure AD single sign-on (SSO) for mission-critical applications such as an ERP system or accounting software, these would benefit greatly from CAE support as well.

The Azure AD sign-in log captures information about CAE usage in client connections, and administrators can use this information to understand how many sessions CAE is active for (Figure 1):

Why Continuous Access Evaluation (CAE) for Azure AD Matters
Figure 1: Checking whether a sign-in is affected by CAE.

Disabling CAE with Conditional Access

Conditional Access is a feature that requires an Azure AD Premium Plan 1 license. Although continuous access evaluation is enabled by default, it’s possible to turn CAE off in certain scenarios using conditional access policies. However, I don’t see any point in disabling CAE if an organization doesn’t have an Azure AD P1 license.

To disable CAE, you should create a new Conditional Access Policy scoped to all cloud apps without any conditions. When configuring the policy, you can opt to disable CAE in the ‘Sessions’ tab (Figure 2):

Why Continuous Access Evaluation (CAE) for Azure AD Matters
Figure 2: Disabling continuous access evaluation.

However, I do not recommend turning off CAE. I personally haven’t had any issue with it, only observed the benefits. A potential side effect could be line-of-business apps not functioning as well with the feature enabled, but I haven’t heard any reports about this happening specifically.

Read more: Planning for Azure AD Conditional Access Policies

CAE Summary

Every year, Microsoft makes Azure AD more secure with features such as continuous access evaluation. Although it’s not necessary to worry about CAE since there’s not much to configure, you should still know how the underlying process works.

Understanding how access tokens function, along with their importance in allowing user access to applications, will help you better manage Azure AD. While CAE might not be a very noticeable feature, it can benefit the security posture of your organization’s environment immensely.

About the Author

Thijs Lecomte

Thijs is a security consultant out of Belgium, working at The Collective, an MSSP with a Microsoft-focused Security Operations Center. His work consists out of leading the SOC team and implementing Microsoft Security solutions (such as Microsoft Sentinel and Defender) as a consultant. He is an MVP in the Security category and is a regular speaker at events and user groups. His best-known publication is as co-author of the 'Microsoft 365 Security for the IT Pro' ebook.


  1. Frank Ludovic


    Thank you for your article, in Microsoft documentation about CAE for Workload identities “The continuous access evaluation for workload identities public preview scope includes support for Microsoft Graph as a resource provider.
    The preview targets service principals for line of business (LOB) applications”
    That’s mean CAE for workload also support thirt party application registred in Azure AD ?

    Thank you for your reply

    1. Avatar photo
      Thijs Lecomte

      Hi Frank

      A workload identity is an app registration with application permissions. So this means a backend script running or a scheduled task. For those app registrations which are using the Graph API (no other API’s are supported), CAE will take into effect

  2. Dave

    This seems excellent but I was running into issues when I had to connect/disconnect from the VPN. Obviously it makes sense, my IP and location had changed, but it was annoying.

    Wondering if in future we could identify networks that don’t count as “change”.

    1. Avatar photo
      Thijs Lecomte

      I fear that’s not going to be possible. Did it cause reauthentication at that time? Do you have different CA policies setup based on IP locations?

      1. David Gorman

        Yes, we use known IP addresses in some CA polices.

        I might see if they could be based more on the device itself rather than IP though.

Leave a Reply