Moving towards real time policy and security enforcement
Published Apr 21 2020 09:00 AM 38.8K Views

Hey folks,


I would like to start by saying how amazed I am by the great work security and identity teams worldwide are doing to enable new work paradigms while enhancing security. Folks who were considering Zero Trust models are now jumping in with both feet! It’s really an honor to be a part of your journey. Today I'm writing about an important new capability which should help minimize the time that an at-risk session stays active.


Microsoft services, such as Azure Active Directory and Office 365, use open standards and protocols to maximize interoperability (and as I’ve said before, standards are great for security too). Critical to this discussion are OpenID Connect (OIDC) for authentication and OAuth 2.0 for authorization. When a client application like Outlook connects to a service like Exchange Online, the API requests are authorized using OAuth 2.0 Access Tokens. By default, those Access Tokens are valid for one hour. When they expire, the client is redirected back to Azure AD to refresh them. That also provides an opportunity to re-evaluate policies for user access – we might choose not to refresh the token because of a Conditional Access policy, or because the user has been disabled in the directory.


Token expiry and refresh is a tried and true mechanism in the industry. That said, customers have expressed concerns about the lag between when risk conditions change for the user (e.g. moving from the corporate office to the local coffee shop, or user credentials discovered on the black market) and when policies can be enforced related to that change. We have experimented with the “blunt object” approach of reduced token lifetimes but found they can degrade user experiences and reliability without eliminating risks.


Timely response to policy violations or security issues really requires a “conversation” between the token issuer (e.g. Azure AD) and the relying party (e.g. Exchange Online). This two-way conversation gives us two important capabilities. The relying party can notice when things have changed (e.g. client coming from a new location) and tell the token issuer. It also gives the token issuer a way to tell the relying party to stop respecting tokens for a given user due to account compromise, disablement, or other concerns. The mechanism for this conversation is Continuous Access Evaluation (CAE).


Microsoft has been an early participant in the Continuous Access Evaluation Protocol (CAEP) initiative as part of the Shared Signals and Events working group at the OpenID Foundation. Identity providers and relying parties will be able to leverage the security events and signals defined by the working group to reauthorize or terminate access. It is exciting work and will improve security across many platforms and applications.


Because the security benefits are so great, we're rolling out a Microsoft-specific initial implementation in parallel to our continued work within the standards bodies. As we've worked to deploy these CAE capabilities across Microsoft services, we've learned a lot and are sharing this information with the standards community. We hope our experience in deployment can help inform an even better industry standard and are committed to implementing that standard once ratified, allowing all participating services to benefit.


Here’s what we’re doing at Microsoft with CAE right now:

We're implementing our initial approach to CAE in Exchange and Teams. The latest versions of the Outlook and Teams application on Windows, iOS, MacOS, and Android are capable of CAE and there's no action required from you if using these clients. We will expand the list of compatible clients in the coming months.


The following events will be enforced in this initial CAE rollout:

  • 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

In the future we will add more events into the instantly evaluated set, including but not limited to location and device state changes. While our goal is for enforcement to be instant, in some cases latency of up to 15 minutes may be observed due to event propagation time.

How does CAE work in Microsoft services?

CAE is implemented as follows:


Azure AD’s conversations with relying parties: Relying parties, like Exchange Online and Teams, subscribe to critical events from Azure AD. Upon receiving an event from Azure AD, the relying party knows that it should respond to future requests from the impacted client by telling the client to get a new token from Azure AD. Doing this requires that the client recognize the new response type and handle it appropriately. This is why only client applications that have implemented the flow can benefit from the behavior.


Relying parties’ conversations with Azure AD: Additionally, relying parties can synchronize key policy elements and notify Azure AD if the client varies from the terms of that policy. For example, if the policy is specific about the network the client must be on and the IP address of the client changes, the relying party can determine whether to redirect the client to Azure AD for token re-issuance.


CAE Graphic 2.png


We will initially enable CAE only for tenants with no Conditional Access policies. Because risk and policy are evaluated in real time, clients that negotiate CAE-aware sessions will rely on CAE instead of existing static Access Token Lifetime policies. Our first incremental step to this approach is to increase Access Token lifetime to 24 hours in CAE enabled sessions. Revocation is driven by risk and policy evaluation, not an arbitrary timeframe. This will increase the stability of your applications without affecting your security posture. We will use our learning from this phase of CAE to inform our ongoing rollout to additional Microsoft services.


I'm incredibly excited about this new capability – real time policy response is something we’ve discussed and worked towards in the industry for years, and this is an important step towards enhancing the security of your organizations and users.


As always, I ’d love to chat with you about the feature at @alex_t_weinert


Stay safe out there!



Sounds great, but likely wont make a big impact considering you are not enabling it for tenants that do have CA policies. On that note, how does it relate to Security defaults?

Occasional Contributor

How do I know if my tenant is enabled for CAEP?

New Contributor

When you say latest version of Outlook and Teams on Windows devices is that referring to monthly channel?

Frequent Contributor

how we can check this feature and we have already conditional access enabled. what is the user impact


@Kyle Berwaldt, the feature is enabled in Outlook monthly channel. Teams client is in the process of rolling out the change. Teams rollout will complete sometimes in May.  


@Sankarasubramanian Parameswaran , we are not rolling out this feature to tenants with Conditional Access policies just yet but stay tuned. 

Senior Member

What impact are these changes going to have on Power Platform connections to Outlook 365 and Teams? Are we suddenly going to start seeing lots of broken connections in our Flows and Power Apps?

Senior Member

Sounds Great! Looking forward to it! : -)

One Question though: I read that among the  enforced in case of CAE rolout :'MFA is enabled for the user' will that means that the user will be enofrced to use MFA if it is not configured and will there be a way to disable it? 

Senior Member

Will this provide a solution to the scenario where we would want to enforce MFA on every access to an application?
For certain apps like users 401k or Workday, who CAN move to Azure AD for SAML authentication, this would be a huge benefit.  In fact, the reason we have not moved a lot of these apps to AAD is because we cant enforce that today.  The current token behavior supercedes our ability to force it.

I understand this would require CA policy support so I hope that is coming very soon.

Senior Member

As a software vendor, how do we join this program to start working on this?  As I understand this is a continuation of the Azure AD Custom Controls program but there is very little guidance how to join this effort.



@alex335678 - there is no way yet - we are ways away from allowing non-Microsoft apps to participate in CAE as a Relying Party. Check back in 2021

@Mark Simone - no. prompting for re-authentication on access to application can be partially done is sign-in freqency


but your experience with SAML-based apps will vary - SIF will not expire existing sessions to SAML apps.

New Contributor

My User Sign-in logs are showing "IsCAEToken False" in the Additional Details tab. 
I was trying to figure out what this entry means which led me here to this post.

Does "IsCAEToken False" mean this feature is not enabled in our tenant?  We do have Conditional Access policies in place so I'm assuming so but would appreciate verification.

By extension, would this entry continue to appear but say "True" when Microsoft starts to apply this to tenants with CA policies? I want to be sure I can tell when this is enabled.

@Derek Pickell - if you are using Conditional Access you will not get benefit of CAE yet

New Contributor

@Daniel Stefaniak , thanks, I assumed so. 

However can you verify that the entry "IsCAEToken False" in the Additional Details tab is related to CAE?

@Derek Pickell it is. But it will be parsed out into something more readable in the future

Established Member

Hey @Daniel Stefaniak , it seems it's available now and there's no word in the documentation about Conditional Access limitation - is that true?
I can see the CAE blade and option to enable it on a tenant with CA's in place - what would happen if enabled?

Regular Visitor

@Daniel Stefaniak Your comment from 21.07.20
"there is no way yet - we are ways away from allowing non-Microsoft apps to participate in CAE as a Relying Party. Check back in 2021"

Any update on this? I would like to use it on my custom API's. Looking forward to your reply

Version history
Last update:
‎Jul 27 2020 07:11 PM
Updated by: