Conditional Access Sign-In Risk MFA Policy CAU006-All Grant access for Medium and High Risk Sign-in for All Users when Browser and Modern Auth Clients require MFA
Introduction
Conditional Access sign-in risk MFA policies are designed to address a very real security challenge: not every login attempt carries the same level of risk. A user signing in from their usual device during business hours is very different from a login attempt that triggers identity protection signals indicating suspicious activity. Microsoft Entra ID continuously analyzes authentication behavior and assigns risk levels to sign-in events when patterns resemble known attack techniques or compromised credential usage.
When risk signals appear, organizations need a way to respond immediately without disrupting normal access for every user. That is where Conditional Access becomes an important part of a modern identity security strategy. Instead of blocking access outright, a policy can introduce stronger identity verification when suspicious sign-in activity is detected.
This Conditional Access policy demonstrates a common security design pattern. When the sign-in risk level reaches medium or high, access to cloud applications still remains possible, but only after the user successfully completes multifactor authentication. In practice, this approach allows legitimate users to continue working while adding a strong identity verification layer that helps stop attackers using stolen credentials.
This Policy in One Line
When Microsoft Entra ID detects a medium or high risk sign-in, this Conditional Access policy allows access only after the user completes multifactor authentication.
What This Conditional Access Policy Does
This policy introduces risk-based authentication by linking Microsoft Entra ID sign-in risk detection with a multifactor authentication requirement. When the identity protection system evaluates a login attempt and classifies the sign-in as medium or high risk, the policy immediately becomes part of the access decision process.
Rather than denying access outright, the design requires the user to complete multifactor authentication before access can continue. In practical terms, the authentication flow changes the moment elevated risk is detected. A user who would normally sign in with only a primary credential is prompted for an additional authentication factor.
The intention behind this configuration is to provide a balanced response to suspicious activity. Identity protection signals may indicate unusual behavior such as unfamiliar sign-in patterns or other anomalies. Instead of assuming the account is fully compromised, the policy asks the user to verify their identity through multifactor authentication. This allows legitimate users to continue working while making it significantly harder for attackers to proceed with stolen credentials.
Risk-based policies like this are an important element of modern Conditional Access design because they allow security controls to activate only when the risk level justifies stronger verification.
Who the Policy Applies To
This Conditional Access policy targets all users within the environment, meaning the risk-based authentication rule applies broadly across the identity platform. By including the full user population, the design ensures that risk signals are handled consistently regardless of the individual account involved in the sign-in attempt.
At the same time, the configuration excludes specific groups. Organizations commonly use exclusion groups to manage controlled exceptions. These groups often exist to support operational flexibility, such as temporarily bypassing a rule during troubleshooting, supporting service dependencies, or enabling time-bound exception processes that are reviewed and approved through internal governance procedures.
Using group-based exclusions rather than excluding individual accounts is considered a best practice in Conditional Access architecture. It allows exception management to follow structured processes rather than relying on permanent manual configuration changes. Security teams can place accounts into an exception group when necessary and remove them once the condition requiring the exception has been resolved.
This approach helps maintain strong coverage across the environment while still supporting operational scenarios that occasionally require temporary flexibility.
What Apps and Services the Policy Protects
The policy evaluates access attempts across all cloud applications integrated with the identity platform. This broad scope ensures that any authentication attempt involving Microsoft Entra ID participates in the risk-based evaluation process.
By applying the rule to all applications, the design avoids security gaps where attackers might target less protected workloads. If a sign-in attempt triggers a medium or high risk classification, the multifactor authentication requirement applies regardless of which cloud service the user is trying to access.
This is an intentional design principle in Conditional Access architectures. Instead of securing applications individually, security teams often implement identity-driven policies that follow the user across the entire cloud environment. Because identity is the control plane for modern SaaS platforms, protecting the authentication process itself provides a consistent security layer for every application relying on the directory.
As a result, the policy acts as a universal safeguard whenever elevated sign-in risk is detected.
Platforms, Devices, and Client Apps in Scope
The policy evaluates sign-in attempts coming from browser sessions as well as modern authentication clients such as mobile and desktop applications. These client types represent the most common ways users access cloud services today, covering interactive browser access and application-based authentication.
By including both client categories, the configuration ensures that the risk-based verification requirement is applied consistently regardless of how the user connects. Whether a sign-in originates from a web browser or from an application using modern authentication protocols, the identity platform still evaluates the risk level of the sign-in and enforces the multifactor authentication requirement when necessary.
No platform restrictions are defined in the configuration, meaning the policy does not differentiate between operating systems or device types. The decision to enforce multifactor authentication is therefore driven entirely by the risk assessment of the sign-in event rather than device characteristics.
This reinforces the policy’s core purpose: responding to suspicious authentication behavior rather than enforcing device-based restrictions.
How Access Is Decided
Conditional Access evaluates this policy during the authentication process whenever Microsoft Entra ID assigns a medium or high risk level to a sign-in attempt. At that moment, the policy contributes to the overall access decision.
If the risk condition is met, the user must complete multifactor authentication before access can continue. The authentication requirement acts as the gatekeeper that determines whether the session proceeds.
In addition to the multifactor authentication requirement, the policy also enforces a sign-in session behavior where authentication is evaluated each time access occurs. This design ensures that the authentication process remains fresh and that risk signals are reconsidered during new sign-in attempts rather than relying on long-lived sessions.
The result is a layered authentication decision. The platform first evaluates the sign-in risk level, then requires multifactor authentication when elevated risk is detected, and finally ensures that each authentication event remains closely tied to a verified identity.
What the User Experience Looks Like During Sign-In
From the user’s perspective, the experience only changes when the identity platform detects unusual activity. On a normal day, the user signs in as expected with their primary authentication method.
However, if the sign-in triggers a medium or high risk classification, the authentication process changes. The user is prompted to verify their identity using multifactor authentication before access can continue.
This moment is often where legitimate users realize something unusual is happening. They may be signing in from a new location, using a different network, or accessing resources from an unfamiliar environment. The additional authentication factor confirms that the person behind the login attempt is indeed the legitimate account holder.
If the user successfully completes multifactor authentication, access continues normally. If the challenge cannot be satisfied, the sign-in cannot proceed.
This design ensures that suspicious activity is challenged immediately while allowing legitimate users to recover access through identity verification.
Why This Policy Matters for Security and the Business
Credential theft remains one of the most common attack techniques in cloud environments. Attackers often rely on stolen usernames and passwords obtained through phishing, credential reuse, or malware.
Risk-based Conditional Access policies provide an effective defense against these attacks because they focus on behavior rather than just credentials. Even if an attacker obtains a password, the authentication attempt may still trigger risk signals due to unusual sign-in patterns.
When this happens, multifactor authentication becomes the barrier that attackers typically cannot bypass. The policy therefore reduces the likelihood that compromised credentials can be used to access cloud resources.
For organizations, this approach provides a strong balance between usability and security. Normal authentication flows remain simple for everyday access, but elevated risk automatically triggers stronger identity verification.
Is This a Foundational or Must-Have Policy?
Policies that respond to sign-in risk levels are widely considered foundational components of a modern Conditional Access deployment.
They allow security teams to introduce adaptive authentication without forcing multifactor authentication on every login event. Instead, stronger controls activate only when risk indicators suggest that the authentication attempt may not be legitimate.
This adaptive approach improves security posture while minimizing friction for everyday users. It also aligns closely with Microsoft Entra ID identity protection capabilities, which continuously analyze authentication signals across the platform.
For many organizations, implementing risk-based multifactor authentication is one of the earliest steps toward building a mature identity security architecture.
Important Design Choices and Things to Notice
Several design choices stand out in this configuration. First, the policy responds specifically to medium and high sign-in risk levels rather than applying the requirement to every authentication event. This ensures that multifactor authentication is triggered by elevated risk signals rather than used indiscriminately.
Second, the scope covers all cloud applications and all users, creating consistent protection across the identity environment. This avoids situations where less protected workloads become attractive targets for attackers.
Third, the inclusion of both browser access and modern authentication clients ensures that common user access paths are protected by the same identity verification requirement.
Finally, the use of group-based exclusions allows controlled exception management without weakening the broader security coverage of the policy.
Together, these design decisions reflect a typical enterprise approach to implementing risk-aware Conditional Access policies.
Conditional Access Design Principles Behind This Policy
This policy illustrates several important Conditional Access design principles. One of the most important is risk-driven authentication. Instead of applying static rules, the policy reacts dynamically to signals generated by the identity protection system.
Another principle is identity-centric security. By focusing on the authentication process rather than specific devices or networks, the policy protects every application connected to the identity platform.
The configuration also demonstrates layered authentication design. Risk detection, multifactor authentication, and session evaluation all contribute to the final access decision.
These principles reflect how modern organizations secure cloud identities: by combining behavioral analysis with adaptive authentication requirements that activate when risk is detected.
Final Thoughts
Risk-based Conditional Access policies play an important role in protecting cloud identities against credential-based attacks. By requiring multifactor authentication when medium or high risk sign-ins are detected, organizations introduce a strong identity verification layer exactly when it matters most.
The design allows legitimate users to continue working while preventing attackers from progressing beyond the initial authentication attempt. Instead of relying solely on passwords, the policy ensures that suspicious sign-ins must pass a stronger identity check.
When combined with other Conditional Access controls, risk-driven authentication policies help create an identity security architecture that adapts to threats in real time.
