A screenshot showing the presence of the new "Continuous Access Evaluation" setting in the Azure AD portal

I’d not spotted this in my own tenant, but an eagle eyed user (Thomas Naunheim) flagged it on Twitter yesterday… much to my (nerdy!) excitement. Continuous Access Evaluation (CAE) is now in Public Preview! Those of you who follow my ramblings will know I’m a sucker for identity related feature enhancements. Whilst this ticks that box, it also represents a whole lot more… ushering in a significant change to the way that risky and non-compliant sessions are managed by Azure AD. I thought it would be worth taking some time to explore the feature; outlining what it is and what it might mean for you…

Continuous Access Evaluation (CAE) was first mentioned a few months ago in the Azure AD Tech Community blog. Building on open standards (OIDC and OAuth 2.0), CAE makes it possible for user sessions to be evaluated in real time. This enables more effective and robust policing of user access, and alignment of Zero Trust principles.

What’s changing?

The interface within Conditional Access settings which allows the customisation of session times using the "Sign-in frequency" setting.

Let’s consider how access is governed under during a “normal” session today. When a user accesses an online service (e.g. Exchange Online), requests are authorised via tokens issued by the authentication provider (Azure AD). These are provided at the point a successful authentication takes place, with a default validity of one hour. During this time all requests from the presenting party are authorised. Whilst we can manipulate this using Conditional Access session controls (see image) or by modifying token lifetimes, in either scenario we’re reliant on a period of time passing before a request is refused. This isn’t always ideal.

Why does this matter? Consider the scenario where an administrator needs to block access to a service immediately by disabling an account. Under the “normal” model the right to access is maintained until such time as the token refresh interval is reached. Only at this point is the user access denied which may not be desirable (consider a bad leaver). In another example, a user might legitimately satisfy a Conditional Access policy based on location (such as the corporate office) and then reappear in an unauthorised location within the session lifetime. In these examples we would prefer the session to be invalidated via the account being disabled, or through re-evaluation of the request by Conditional Access.

Continuous Access Evaluation Protocol (CAEP) changes all of this, providing a way for the resource provider (relaying party) to be notified by the identity provider where tokens should no longer be honoured. The trigger for this could be any number of things… a state change, a security event, an administrative action. Relaying parties will also be able to synchronise key policy elements to enable proactive session termination (i.e. not based on the IDP issuing a signal). Irrespective, and regardless of the token validity, the user can be prompted by the resource provider to re-authenticate – potentially denying access. Very cool!

Enabling Continuous Access Evaluation

CAE can be enabled within the Security section of the Azure AD Portal (direct link), however you should be aware of some limitations in the short term. Obviously “preview” carries some caveats… limited support, likely to undergo some changes etc. etc. I don’t need to tell you that 🙂 Unique to CAE though are some specifics around where / how it applies.

First and foremost, CAE assumes “compatible” relaying parties and clients. Those which can interpret event information from the Identity Provider, and handle the requirement to permit access or invoke re-authentication based on that information. At present, this is limited to Exchange Online, SharePoint, and Microsoft Teams (with more planned for future).

In a similar vein, only certain conditions are supported at the moment. These are listed as:

  • User Account is deleted or disabled
  • Password for a user is changed or reset
  • MFA is enabled for the user
  • Admin explicitly revokes all Refresh Tokens for a user
  • Elevated user risk detected by Azure AD Identity Protection

…again, more planned for the future.

Where CAE applies, Microsoft make an important note regarding “old” access token lifetimes:

Because risk and policy are evaluated in real time, clients that negotiate continuous access evaluation aware sessions will rely on CAE instead of existing static access token lifetime policies, which means that configurable token lifetime policy will not be honored anymore for CAE-capable clients that negotiate CAE-aware sessions. Token lifetime is increased to be long lived, up to 28 hours, in CAE sessions. Revocation is driven by critical events and policy evaluation, not just an arbitrary time period. This change increases the stability of applications without affecting security posture.

Continuous access evaluation: Microsoft Docs

Where CAE cannot be applied, regular access token lifetimes will be obeyed.

Summary

When I began writing up this article the “Learn More” link for CAE in the Azure AD portal wasn’t working. This has now been rectified and you can discover more about the inner workings here.

Tying in with some of my previous posts on Security in general (and specifically Zero Trust), I see the implementation of CAE as a huge positive. The underlying mechanism(s) by which authentication requests are processed have long been a blocker for true “Zero Trust” application and whilst minimal, the associated risks can’t be entirely mitigated.

CAE is a big step forward. Providing intelligence between the session, the endpoint, the connected application, and the administrator in way which far more logically aligns with a Zero Trust mentality. It marks the beginning of a new era for Azure AD aligned applications in my mind. It’s significant.

Stay tuned for more feedback on how it operates in practice, how it scales to other applications, and when it dips out of preview. In the meantime I’d encourage you to have a read of the supporting documentation and a play in your own environments. If you have questions I can help with, don’t hesitate to get in touch via the comments below, or find me on Twitter.