MFA Arbitrage: What You Need to Know

For Microsoft accounts, the MFA registration process varies by organization, but most commonly, users enroll themselves. Self-enrollment is typically user-friendly and quick.

ldeally, all users should enroll in MFA. However, some accounts may not have MFA set up yet, like dormant and new accounts. Users who only log in from trusted, on-premise devices might also bypass MFA registration requirements depending on the organization’s access policies.

For these MFA gaps, as covered in our earlier blog post, Behind The Breach: MFA Everywhere, Yes. MFA For Everyone, No MFA self-enrollment can inadvertently aid attackers. If an attacker gains access to an account that hasn’t yet enrolled in MFA, they can register their own method right after logging in. This allows the attacker to retain access to the account even after the session ends, access sensitive organization resources, and initiate a self-service password reset using their own MFA method.

How to Resolve

Fortunately, Microsoft Entra conditional access policies can enforce measures like device restrictions, IP restrictions, or Temporary Access Passes (TAP) to enhance MFA enrollment security.

For example, if your policy blocks security information registration from all locations except your trusted locations, attackers would need to access these trusted IP ranges to enroll a second authentication method, even if they have the compromised credentials of an account without a second factor.

To further secure self-service MFA enrollment, consider using Temporary Access Passes (TAP). TAPs are time-limited passcodes generated by admins for users to register authentication methods. This approach adds another layer of security since it requires admin assistance for users to self-register.

Microsoft Entra policies offer flexibility in securing your organization’s resources, but setting the conditions in a policy can get confusing. The rest of this post will address common misconfigurations and provide guidance on understanding conditional access policies to protect user MFA enrollment effectively.

Microsoft Entra Conditional Access Policies

Microsoft Entra conditional access policies evaluate conditions like a user’s location, device, and the resource being accessed to determine whether to block access, require MFA, or ask acceptance of the tenant’s Terms of Use. Included conditions trigger these responses while excluded conditions represent secure situations and allow access without additional authentication. Importantly, excluded conditions override include conditions.

Here are some tips to help you configure your tenant’s policy and avoid common mistakes:

Users, Roles, and Groups

When creating a new conditional access policy, it’s best to test with a few users to ensure the policy doesn’t disrupt essential functionality for your organization, but avoid extending the testing phase indefinitely. Once testing is complete, include all users to the policy for full coverage, excluding only break-glass accounts.

Locations

The ideal configuration is a policy that includes All Locations and Networks while excluding only Trusted Locations and Networks, like on-premises networks and trusted VPN ranges. Common mistakes are only including trusted or only including untrusted locations. The locations you include determine where access is blocked or requires MFA. Both mistakes create gaps in the policy by restricting coverage to unnecessary locations or to a few untrusted locations.

Response Choice

Microsoft Entra conditional access policies provide grant access options, but not all are suitable for security information registration policies.

For instance, only requiring users to accept the tenant’s Terms of Use for registering a new authentication factor is not recommended. Attackers can easily agree to the terms and proceed to register their own authentication method without any obstacles.

The best options for a security information registration policy are Block Access or Grant Access with MFA. When this policy is triggered, either option will prevent enrollment if the user has no MFA methods registered.

• A Block Access policy prevents all users — both those without a second method and those with at least one additional method registered — from registering new methods or accessing other security information if secure conditions, like being in a trusted location, are not met.
• A Grant Access with MFA policy blocks security information settings for users without MFA until secure conditions are met. Users with at least one additional method registered must authenticate with MFA to access security information, such as self-service password changes.

Creating and Configuring a Conditional Access Policy

Obsidian has released two new posture rules to help customers ensure they have properly secured the MFA registration process:

1. No Conditional Access Policy for MFA Registration:
   
   Determine whether there are any restrictions on MFA enrollment for your users.
   
2. Misconfigured Conditional Access Policy for MFA Registration
   
   Evaluate whether your policy’s current restrictions are meaningfully protecting the MFA enrollment process to most users and IP locations while avoiding common mistakes.
   

Along with detailed guidance on configuring a conditional access policy to secure MFA registration, these rules provide insight into MFA enrollment within your organization. Review these rules to take proactive measures in securing your tenant.