Conditional Access Trusted IP Exclusion Not Working – MFA Still Prompted from Trusted Network

Answers are based on how Conditional Access evaluates locations and MFA Trusted IPs.

1. Can legacy MFA Trusted IPs conflict with Conditional Access?

Yes, they can interact and affect evaluation:

• The location condition option All trusted networks and locations explicitly includes both:
  1. All locations marked as trusted locations (named locations marked as trusted).
  2. Multifactor authentication trusted IPs, if configured.

  “This option applies to: 1. All locations marked as trusted locations. 2. Multifactor authentication trusted IPs, if configured.”

• The documentation also notes that using the MFA service-settings Trusted IPs is not recommended and is intended only for specific scenarios.

  “Using the trusted IPs section of multifactor authentication's service settings isn't recommended… designed for specific scenarios…”

• If both per-user MFA and Conditional Access policies are configured, Trusted IPs must be added to both the Conditional Access policy and the MFA service settings.

  “If both per-user MFA and Conditional Access policies are configured in the tenant, you need to add trusted IPs to the Conditional Access policy and update the MFA service settings.”

In practice, if Conditional Access policies are configured to require MFA except for “All trusted networks and locations”, but the legacy MFA Trusted IPs do not match the actual client IP (or are misconfigured), the sign-in may still be evaluated as outside trusted locations and trigger MFA.

2. Could the “Block Sign-In Outside …” policies still trigger MFA indirectly?

Yes. Any Conditional Access policy that:

• Includes the user,
• Targets the app being accessed,
• Has Conditions > Locations configured as Any network or location (or similar), and
• Does not exclude the trusted location or “All trusted networks and locations”,

will still apply and can require MFA.

The recommended pattern in the documentation for “require MFA except from corporate network” is:

1. Under Assignments > Network (Locations):
   • Configure = Yes.
   • Include = Any network or location.
   • Exclude = All trusted networks and locations.

“In this case they could add the following configuration to the policy: 1. Under Assignments, select Network. 1.1. Configure Yes. 1.2. Include Any network or location. 1.3. Exclude All trusted networks and locations.”

If the “Block Sign-In Outside …” policies are not using this pattern, or if they are block policies instead of grant/MFA policies, they may still be evaluated and cause MFA or blocks even from the trusted IP.

3. Other settings that can still enforce MFA prompts

From the provided context, the following can still cause MFA even when a trusted location is configured:

• MFA Trusted IPs misconfiguration (IPv4 only, public IP ranges only). If the client IP is not within the configured ranges, the sign-in will not be treated as trusted.
• Federated ‘insidecorporatenetwork’ claim: If using AD FS and the option Skip multifactor authentication for requests from federated users on my intranet is enabled, Conditional Access treats any request with the insidecorporatenetwork claim as coming from a trusted location.

  “Any request with the insidecorporatenetwork claim would be treated as coming from a Trusted location if that option is selected.”

  If this is enabled but AD FS is not issuing the claim correctly, some sign-ins may not be recognized as intranet and still require MFA.
• Multiple policies: If more than one Conditional Access policy applies, any policy that requires MFA (and does not exclude the trusted location) will cause MFA, even if another policy would allow access without MFA.

4. Validating that Entra ID sees the correct client IP

The context confirms how Entra ID uses IPs for location evaluation:

• Trusted IPs for cloud-based MFA accept only public IPv4 ranges.
• Named locations support both IPv4 and IPv6 ranges.

“For cloud-based Microsoft Entra multifactor authentication, you can use only public IP address ranges.”

To validate detection:

• In the sign-in logs, verify the Client IP shown for the sign-in.
• Confirm that this IP is within:
  • The CIDR ranges configured in Named locations, and
  • If using legacy MFA Trusted IPs, the ranges configured there.

For example, for a single IP, the range must be entered as x.x.x.x/32; for a /24 network, x.x.x.0/24.

“For a single IP address, use notation like xxx.xxx.xxx.xxx/32. Enter up to 50 IP address ranges. Users who sign in from these IP addresses bypass multifactor authentications.”

If the sign-in logs show a different IP (for example, a proxy or outbound NAT IP), that IP must be what is configured in the named location and/or Trusted IPs.

5. Recommended troubleshooting approach for trusted locations

Based on the documentation, a structured approach is:

1. Prefer Conditional Access named locations over legacy Trusted IPs
   • Define the office public IP as a Named location and mark it as trusted.
   • Use Conditional Access policies that:
     • Include Any network or location.
     • Exclude All trusted networks and locations.
   • Consider removing or simplifying legacy MFA Trusted IPs, since they are not recommended except for specific scenarios.
2. Verify Trusted IPs configuration if still used
   • In Multifactor authentication > Additional cloud-based MFA settings > Trusted IPs, ensure:
     • The correct public IPv4 ranges are entered in CIDR.
     • If using federated users, AD FS issues the insidecorporatenetwork claim and the option For requests from federated users on my intranet is correctly set.
3. Check Conditional Access evaluation for a failing sign-in
   • Open the sign-in record and review Conditional Access details:
     • Confirm which policies are Applied and which are Not applied.
     • For each applied policy, check the Network (location) condition and whether it shows Matched or Not matched.
   • Ensure that at least one applicable policy explicitly excludes All trusted networks and locations from MFA.
4. Align all policies with the same trusted-location logic
   • For each “Block Sign-In Outside …” or MFA policy, under Conditions > Locations:
     • Use Any network or location as Include.
     • Exclude All trusted networks and locations (or the specific named location) so that office IPs are consistently treated as trusted.
5. Consider report-only mode for testing
   • For new or modified policies, enable them in Report-only first and review the impact in sign-in logs before enforcing, as recommended in the Conditional Access guidance.

“After confirming your settings using policy impact or report-only mode, move the Enable policy toggle from Report-only to On.”

Following these steps ensures that:

• The correct client IP is used.
• Named locations and MFA Trusted IPs are not in conflict.
• All Conditional Access policies consistently respect the trusted office IP and only require MFA from untrusted networks.

References:

• Configure Microsoft Entra multifactor authentication settings
• Conditional Access: Network assignment
• Require multifactor authentication for all users
• Protect security info registration with Conditional Access policy
• Securing cloud resources with Microsoft Entra multifactor authentication and AD FS