Prompt users for reauthentication on sensitive apps and high-risk actions with Conditional Access

[ad_1]

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:

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

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 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”