Conditional Access Phishing-Resistant MFA Policy CAU013-All Grant Require phishing resistant MFA for All users when Browser and Modern Auth Clients

This Policy in One Line

This Conditional Access phishing-resistant MFA policy requires users to authenticate with phishing-resistant authentication methods when accessing protected applications through browsers or modern authentication clients.

What This Conditional Access Policy Does

The design intention of this policy is to ensure that certain sign-in scenarios require the strongest authentication methods available in the identity platform. Instead of allowing any MFA method that satisfies basic multi-factor authentication, the policy enforces an authentication strength that specifically requires phishing-resistant authentication.

When Conditional Access evaluates a sign-in event that matches the policy scope, it checks whether the authentication method used satisfies the phishing-resistant MFA requirement. The permitted methods include Windows Hello for Business, FIDO2 security keys, and certificate-based multi-factor authentication. These authentication technologies rely on cryptographic proof tied to the user’s device or hardware token, which significantly reduces the risk of credential interception.

The security meaning of this configuration is clear: authentication must be resistant to phishing attacks. Even if a user is tricked into revealing their password, attackers cannot complete the sign-in process without the cryptographic authentication mechanism associated with the user’s device or security key. This design reflects a modern identity protection principle where stronger authentication methods are required for sensitive access scenarios.

Who the Policy Applies To

This policy targets users through group-based assignment. Instead of applying directly to individual identities, the policy scope is defined through a designated group that represents the population of users intended to be protected by this authentication requirement.

Conditional Access evaluates group membership during the sign-in process. If a user belongs to the targeted group, the authentication strength requirement becomes part of the access decision. This allows organizations to roll out stronger authentication requirements in a controlled and scalable way, ensuring that policy enforcement aligns with identity governance processes.

The configuration also includes exclusion groups. Organizations commonly use exclusion groups to support controlled exception management, allowing temporary or approved deviations from a policy requirement. These exclusions are often used during phased deployments, hardware rollout periods, or when specific service accounts cannot yet meet the stronger authentication requirements.

By combining targeted group inclusion with controlled exclusions, the policy provides both strong security enforcement and operational flexibility.

What Apps and Services the Policy Protects

The policy protects a broad set of cloud applications by applying the authentication requirement across the application landscape rather than targeting a single workload. This means that when users attempt to access services governed by the policy, Conditional Access evaluates whether the authentication strength requirement has been satisfied.

During the sign-in evaluation process, the identity platform checks whether the user is attempting to access any application within the protected scope. If the application falls within the defined coverage, the phishing-resistant MFA requirement becomes part of the access decision.

One application is specifically excluded from the scope of the policy. This type of exclusion is typically used when a service requires alternative authentication handling or when compatibility constraints exist. By deliberately defining which services remain outside the enforcement scope, the policy allows organizations to maintain operational continuity while strengthening authentication requirements for the rest of the application ecosystem.

This design pattern supports a layered identity protection model where strong authentication becomes the default expectation for accessing cloud services.

Platforms, Devices, and Client Apps in Scope

The policy specifically evaluates sign-ins originating from browsers and modern authentication clients. These two client categories represent the most common access paths to cloud services, including web-based portals, desktop productivity applications, and mobile applications that rely on modern authentication protocols.

When a user signs in through a browser, the authentication request is processed through web-based identity flows. Similarly, modern desktop and mobile applications authenticate using modern authentication protocols that interact directly with Microsoft Entra ID. The policy evaluates these authentication paths and determines whether the required authentication strength has been satisfied.

No device platform restrictions are configured within the policy. As a result, the authentication requirement applies regardless of whether the user signs in from Windows, macOS, mobile operating systems, or other supported platforms.

By focusing on client application types rather than device platforms, the policy ensures that strong authentication requirements apply consistently across common sign-in experiences.

How Access Is Decided

Conditional Access evaluates access through a sequence of policy checks that determine whether a sign-in attempt meets the defined security conditions. In this policy, the evaluation focuses on client application type, application scope, and user group membership.

Once a sign-in matches these conditions, the identity platform evaluates whether the authentication performed by the user satisfies the required authentication strength. The phishing-resistant MFA requirement means that only authentication methods meeting the defined strength criteria are accepted.

If the user authenticates using Windows Hello for Business, a FIDO2 security key, or certificate-based authentication, the authentication requirement is satisfied. These methods rely on cryptographic keys that are bound to the user’s device or hardware token, making them resistant to credential phishing.

If the authentication method does not meet the phishing-resistant requirement, the sign-in cannot satisfy the policy condition. In this way, the policy acts as a gate that allows access only when strong identity verification has been performed.

What the User Experience Looks Like During Sign-In

From the user’s perspective, the experience depends on the authentication method they attempt to use during sign-in. When a user accesses an application through a browser or modern authentication client, Microsoft Entra ID begins the authentication process as usual.

However, once the sign-in matches the conditions defined in the policy, the identity platform checks whether the authentication method satisfies the phishing-resistant requirement. If the user signs in using Windows Hello for Business, a FIDO2 security key, or certificate-based authentication, the process completes normally.

If the user attempts to authenticate with a method that does not meet the phishing-resistant requirement, the sign-in flow requires a stronger authentication method before access can be granted.

This experience encourages users to adopt passwordless or hardware-backed authentication methods. Over time, it guides the organization toward stronger identity verification practices while maintaining a consistent sign-in experience.

Why This Policy Matters for Security and the Business

Credential theft remains one of the most common entry points for identity-based attacks. Traditional MFA methods improve security but can still be vulnerable to social engineering, push fatigue attacks, or phishing proxies that capture authentication tokens.

By requiring phishing-resistant MFA, the policy significantly raises the security bar for authentication. Attackers cannot simply steal passwords or manipulate MFA requests. They must also possess the hardware-bound authentication mechanism tied to the user’s device or security key.

For organizations, this translates into a meaningful reduction in identity compromise risk. It protects access to cloud applications without relying on complex network controls or device restrictions.

This approach aligns with modern Zero Trust security principles where identity verification becomes the primary security boundary.

Is This a Foundational or Must-Have Policy?

A phishing-resistant MFA policy is often considered a foundational control in mature identity security architectures. As organizations move toward passwordless authentication and hardware-backed identity verification, enforcing stronger authentication methods becomes a natural next step.

While traditional MFA policies provide a baseline level of protection, phishing-resistant authentication policies introduce a higher assurance level. They are particularly valuable in environments where protecting cloud identities is critical to maintaining business operations and data protection.

Because this policy focuses on authentication strength rather than device trust or location restrictions, it serves as a core identity protection control that can operate alongside other Conditional Access policies.

Important Design Choices and Things to Notice

Several design choices within this policy reveal a deliberate approach to identity security. First, the authentication requirement is defined through authentication strength rather than individual authentication methods. This approach ensures that only methods meeting a specific security standard are allowed.

Second, the policy targets both browser access and modern authentication clients. These two access paths represent the majority of user sign-in activity across cloud environments, ensuring that the authentication requirement applies to the most common entry points.

Third, the use of group-based targeting allows organizations to control the rollout of phishing-resistant authentication requirements. Administrators can introduce stronger authentication methods gradually while managing exceptions through designated groups.

Together, these design choices demonstrate a practical approach to implementing strong authentication controls without disrupting normal access patterns.

Conditional Access Design Principles Behind This Policy

This policy reflects several core principles used in modern Conditional Access design. One of the most important principles is identity assurance. Instead of relying solely on passwords or weaker authentication methods, the policy ensures that access decisions are based on cryptographic identity verification.

Another design principle is consistent access control. By applying the authentication requirement across a wide range of applications and sign-in paths, the policy avoids fragmented security coverage.

The policy also supports progressive security adoption. Organizations can deploy stronger authentication technologies such as FIDO2 security keys or Windows Hello for Business while maintaining a consistent Conditional Access framework.

These principles help create an identity security model where authentication strength becomes a central pillar of access control.

Final Thoughts

Strong authentication has become one of the most important defenses against modern identity attacks. Policies that require phishing-resistant MFA help organizations move beyond traditional password-based security models and toward cryptographic identity verification.

By enforcing authentication strength during browser and modern client sign-ins, this Conditional Access policy strengthens identity protection across the application landscape. It ensures that access decisions are based on authentication methods that cannot easily be intercepted, replayed, or manipulated by attackers.

As organizations continue to adopt passwordless authentication and hardware-backed identity verification, policies like this one form a critical part of a resilient identity security strategy.