Public preview: Expansion of Conditional Access reauthentication policy for any resource.

Howdy folks! 

Today I'm thrilled to announce support for additional capabilities now available for Conditional Access reauthentication policy scenarios. Reauthentication policy lets you require users to interactively provide their credentials again - typically before accessing critical applications and taking sensitive actions. Combined with Conditional Access session control of Sign-in frequency, you can require reauthentication for users and sign-ins with risk, or for Intune enrollment. With today's public preview, now you can require reauthentication for any resource protected by Conditional Access. 

To tell you more about this capability, I’ve invited Inbar Cizer Kobrinsky, Principal Product Manager at Microsoft Entra, to talk about the scenarios and configuration. 

Thanks, and please let us know your thoughts!  

Alex Weinert 

-- 

Hi everyone! 

I’m excited to tell you more about the public preview capabilities that we’re adding to the “Sign-in frequency – every time” session control in Conditional Access. 

Single sign-on (SSO) using modern authentication is like a secret sauce for productivity and security. It improves productivity because users can access applications smoothly without signing in to each one with their credentials. SSO also enhances security because it reduces the risks of credential reuse and gives you a common point for control and logging for your Zero Trust deployments.  

However, there are situations where you may want the user's input, such as interactive authentication, before accessing a resource. One of these situations is token theft. A token theft attack occurs when threat actors compromise and replay tokens issued to a user, even if that user has satisfied multifactor authentication (MFA). Because authentication requirements are met, the threat actor is granted access to organizational resources by using the stolen token. Risk-based reauthentication policies can help lower the risk that results from a token theft, requiring threat actors to compromise a fresh token to regain system access.  

Now, let's look at some additional examples of these situations, where you may want to prompt the user for reauthentication: 

\n
• Accessing high-risk resources, such as connecting to a VPN. 
\n
• Activating a privileged role in Privileged Identity Management (PIM). 
\n
• Performing an action within an application, such as changing personal information in an HR application. 
\n
• Critical actions such as Intune enrollment or updating credentials.  
\n
• Risky sign-ins, as called out above, help reduce and mitigate the risk of token theft.  
\n

With the latest update, you now can create policies requiring interactive reauthentication for any application or authentication context protected by Conditional Access.  

In the example below, we’ve created a reauthentication policy for super sensitive actions, such as wire transfer. We’re using authentication context, which the developer has integrated into the application. Before a user can transfer any amount from the application, they must satisfy the Conditional Access policy that targets this authentication context. 

Figure 1: Create a \"sign-in frequency - every time\" policy for super sensitive actions using authentication context

The Conditional Access policy for this authentication context requires phishing-resistant authentication (using authentication strength) and “Sign-in frequency – every time”. The next time a user attempts to make a wire transfer, they will be required to reauthenticate with a phishing-resistant MFA. 

Figure 2: selecting the session control of “Sign-in frequency every time”

To learn more, check out our documentation about Sign-in frequency – every time. 

Let us know what you think! 

Inbar  

Learn more about Microsoft Entra: 

\n
• See recent Microsoft Entra blogs 
\n
• Dive into Microsoft Entra technical documentation 
\n
• Learn more at Azure Active Directory (Azure AD) rename to Microsoft Entra ID 
\n
• Join the conversation on the Microsoft Entra discussion space and Twitter 
\n
• Learn more about Microsoft Security  
\n

Howdy folks! 

Today I'm thrilled to announce support for additional capabilities now available for Conditional Access reauthentication policy scenarios. Reauthentication policy lets you require users to interactively provide their credentials again - typically before accessing critical applications and taking sensitive actions. Combined with Conditional Access session control of Sign-in frequency, you can require reauthentication for users and sign-ins with risk, or for Intune enrollment. With today's public preview, now you can require reauthentication for any resource protected by Conditional Access. 

To tell you more about this capability, I’ve invited Inbar Cizer Kobrinsky, Principal Product Manager at Microsoft Entra, to talk about the scenarios and configuration. 

Thanks, and please let us know your thoughts!  

Alex Weinert 

-- 

Hi everyone! 

I’m excited to tell you more about the public preview capabilities that we’re adding to the “Sign-in frequency – every time” session control in Conditional Access. 

Single sign-on (SSO) using modern authentication is like a secret sauce for productivity and security. It improves productivity because users can access applications smoothly without signing in to each one with their credentials. SSO also enhances security because it reduces the risks of credential reuse and gives you a common point for control and logging for your Zero Trust deployments.  

However, there are situations where you may want the user's input, such as interactive authentication, before accessing a resource. One of these situations is token theft. A token theft attack occurs when threat actors compromise and replay tokens issued to a user, even if that user has satisfied multifactor authentication (MFA). Because authentication requirements are met, the threat actor is granted access to organizational resources by using the stolen token. Risk-based reauthentication policies can help lower the risk that results from a token theft, requiring threat actors to compromise a fresh token to regain system access.  

Now, let's look at some additional examples of these situations, where you may want to prompt the user for reauthentication: 

\n
• Accessing high-risk resources, such as connecting to a VPN. 
\n
• Activating a privileged role in Privileged Identity Management (PIM). 
\n
• Performing an action within an application, such as changing personal information in an HR application. 
\n
• Critical actions such as Intune enrollment or updating credentials.  
\n
• Risky sign-ins, as called out above, help reduce and mitigate the risk of token theft.  
\n

With the latest update, you now can create policies requiring interactive reauthentication for any application or authentication context protected by Conditional Access.  

In the example below, we’ve created a reauthentication policy for super sensitive actions, such as wire transfer. We’re using authentication context, which the developer has integrated into the application. Before a user can transfer any amount from the application, they must satisfy the Conditional Access policy that targets this authentication context. 

Figure 1: Create a \"sign-in frequency - every time\" policy for super sensitive actions using authentication context

The Conditional Access policy for this authentication context requires phishing-resistant authentication (using authentication strength) and “Sign-in frequency – every time”. The next time a user attempts to make a wire transfer, they will be required to reauthenticate with a phishing-resistant MFA. 

Figure 2: selecting the session control of “Sign-in frequency every time”

To learn more, check out our documentation about Sign-in frequency – every time. 

Let us know what you think! 

Inbar  

Learn more about Microsoft Entra: 

\n
• See recent Microsoft Entra blogs 
\n
• Dive into Microsoft Entra technical documentation 
\n
• Learn more at Azure Active Directory (Azure AD) rename to Microsoft Entra ID 
\n
• Join the conversation on the Microsoft Entra discussion space and Twitter 
\n
• Learn more about Microsoft Security  
\n

Public preview: Expansion of Conditional Access reauthentication policy for any resource.

RufioIK708 I have just tested out activating multiple roles. and i am getting MFA prompts for every new PIM ROLE activation.
And it should be this way, when the setting states \" Every time\" not every 10-15 min.
I should be a gate keeper, i am getting this picture that needs to revalidate MFA no mater the time.

In my testing, the prompt would trigger 10 to 15 minutes after sign in, don't have the exact timing. It seems maybe there's a cool down or grace period for back to back mfa prompts. I'm ok with it. It's reasonable to expect someone not to have to redo the with if they just signed in. If they've been working an hour and then need to activate PIM, being prompted then is what we are looking for 

mickiwForce yea probably, but good to hear that it is indeed working as expected, just not on my test 🙂 thanks for your quick reply!

FelixLemmen 
Hmm maybe it's just preview problem then 🙂
(will not be the first time though)

mickiwForce strange, i build it exactly like this with session control \"sign in frequency eq every time\" but after i log in confirming login with mfa it just passes my pim activation without forcing me to do mfa again. (tested it after one day again to confirm the ca policy correctly applies)

FelixLemmen 
Yes I have tested it and it works:

You need to couple your CA policy target resource, with an Auth context, and then define the auth context on a PIM Role on the respective PIM owner/member setting.

mickiwForce

i was thinking the same. Sadly, my test was not successful. I've built this scenario in my dev environment and I’m not getting prompted for MFA when activating a PIM Role. Are you able to do a test do confirm this? The technet article reads “preview for some apps”. Maybe this get fixed later. 

I am testing this out for my environment.  We have a CAP that enforces MFA for all users.  This is regular MFA so push notification or SMS are valid.  We also have a policy just like the one above for PIM, with passwordless methods for the auth strength.  When users sign-in and complete MFA with push notification or SMS, and they try to activate a role, it triggers a new prompt. Awesome!  However, when users sign in initially with a passwordless method (Fido2 or MS Auth app phone sign-in), there is no prompt, and they are able to activate their roles right away.  Is this the designed behavior or one of the preview kinks to work out?

Finally we can require MFA for every PIM elevation, and not rely on the already authenticated session token.

Love to see sign-in frequency - require every time in the news.

I was pounderinf what to do about risky sign-ins when we require mfa for every connection. Looks like we have a lead in here.

maybe some future updates on https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-configure-risk-policies?