Internet Access web filtering (V2)
Microsoft's edit ·
Microsoft's commit message in MicrosoftDocs/entra-docs · commit 5ec9486 · +33 −4 lines · also on GitHub
⋯ 1 unchanged line
22
title: Web filtering in Global Secure Access (V2)
33
description: "Learn how the V2 web filtering object model works in Microsoft Entra Internet Access, including policies, rules, destination matching, and V1 coexistence."
44
ms.topic: concept-article
5
−ms.date: 07/21/2026
5
+ms.date: 08/18/2026
66
ms.subservice: entra-internet-access
77
ai-usage: ai-assisted
88
---
⋯ 58 unchanged lines
6767
6868
Conditional Access remains the delivery mechanism for user and context awareness. Security profiles are referenced by profile identifier (GUID) in Conditional Access session controls, and those references remain valid across the transition to V2.
6969
70
+V2 web filtering rules don't currently support user or group targeting. Apply user and group assignments to the security profile through Conditional Access.
71
+
7072
## Author a web filtering policy
7173
7274
You create a web filtering policy in the Microsoft Entra admin center by browsing to **Global Secure Access** > **Secure** > **Web Filtering Policies (V2)** and selecting **Create policy**. The create experience is organized into **Basics**, **Policy settings**, and **Review** tabs.
⋯ 30 unchanged lines
103105
104106
## How V2 coexists with V1
105107
106
−You can adopt V2 without interrupting your existing web filtering enforcement. The models are designed to run side by side during the transition.
108
+V1 and V2 can run side by side during the transition. However, they use different evaluation models, and migrating a policy can change the effective enforcement for users who match multiple security profiles.
107109
108110
- **Higher priority for V2**: V2 web filtering policies are evaluated at a higher priority than V1 web content filtering policies.
109111
- **Evaluation in series**: When both a V1 and a V2 policy apply, both modules run in series until you remove the V1 policy. For how a match in one module affects the other, see [How evaluation works across V1 and V2](#how-evaluation-works-across-v1-and-v2).
110112
- **Consistent logging**: Matches are recorded using the existing traffic logs schema, including web category and the profile, policy, and rule names and identifiers. To review traffic, browse to **Global Secure Access** > **Monitor** > **Traffic logs**.
111113
114
+## Before you migrate
115
+
116
+Review how your security profiles combine policy enforcement before you migrate:
117
+
118
+- **V1 can compose enforcement across profiles**: The V1 module evaluates policies from all applicable security profiles in priority order.
119
+- **V2 uses one applicable policy**: The V2 module evaluates the policy in the first applicable security profile that contains a V2 web filtering policy. It doesn't continue to another profile to compose an outcome from a second V2 web filtering policy.
120
+- **V2 rules don't support user or group targeting**: You can't replace profile-level targeting by assigning users or groups to individual rules.
121
+
122
+Where possible, consolidate your intended outcomes into one V2 policy with ordered rules and an appropriate default action. If your design relies on composing web filtering enforcement from multiple security profiles, remain on V1 until V2 supports your scenario.
123
+
124
+> [!IMPORTANT]
125
+> A like-for-like migration of individual policies might not produce like-for-like enforcement. Before you migrate, identify users who match multiple security profiles, compare their effective V1 policy with the proposed V2 policy, and test both allowed and blocked destinations.
126
+
112127
## How evaluation works across V1 and V2
113128
114129
When a user has both V1 and V2 policies applied, Global Secure Access evaluates them as two separate modules that run in sequence, not as one merged policy set:
115130
116
−1. The V2 module runs first. It finds the first security profile applicable to the user that contains a V2 web filtering policy and produces an outcome: either a matched rule's action or, if no rule matches, the policy's default action. A V2 policy always produces an outcome.
131
+1. The V2 module runs first. It finds the first security profile applicable to the user that contains a V2 web filtering policy and produces an outcome: either a matched rule's action or, if no rule matches, the policy's default action. A V2 policy always produces an outcome, so the module doesn't evaluate V2 web filtering policies in other applicable profiles.
117132
1. The V1 module runs second, only if V2 didn't block. If the V2 outcome is **Block**, the request is blocked and evaluation stops. If the V2 outcome is **Allow**, evaluation falls through to the V1 module, which evaluates all V1 policies linked to the user's profiles in priority order and applies the final action.
118133
119134
The key consequence is that **Block** and **Allow** aren't symmetric across the two modules:
⋯ 4 unchanged lines
124139
In short, a V2 policy can add blocks that override V1, but it can't force-allow traffic that a V1 policy blocks.
125140
126141
> [!IMPORTANT]
127
−> Because both modules evaluate across all of the user's applicable profiles rather than stopping at the highest-priority profile, a V2 **Block** on a lower-priority profile can override an **Allow** on a higher-priority profile. Review the following examples before you run a mixed V1/V2 configuration.
142
+> Profile priority determines which applicable V2 web filtering policy is selected, but the V2 module skips profiles that don't contain a V2 web filtering policy. As a result, a V2 **Block** on a lower-priority profile can override a V1 **Allow** on a higher-priority profile. Review the following examples before you run a mixed V1/V2 configuration.
128143
129144
**Example 1: A V2 Block overrides a higher-priority V1 Allow.** Profile 1 (priority 100) has a V1 policy that allows `espn.com` and no V2 policy. Profile 2 (priority 200) has a V2 policy that blocks the Sports category. The V2 module skips Profile 1 (no V2 policy), evaluates Profile 2's V2 **Block**, and blocks the request to `espn.com`. Profile 1's higher priority doesn't apply, because the V2 module runs first and **Block** is terminal.
130145
⋯ 1 unchanged line
132147
133148
> [!NOTE]
134149
> After you create a V2 web filtering policy, the V1 web content filtering experience becomes update-and-delete only. You can edit or remove existing V1 policies, but you can't create new ones. To return to authoring V1 policies, remove all V2 web filtering policies.
150
+
151
+## Frequently asked questions
152
+
153
+### What if I rely on multiple security profiles?
154
+
155
+Remain on V1 if users rely on web filtering enforcement composed from multiple security profiles. V2 evaluates the web filtering policy from only the first applicable profile that contains one.
156
+
157
+### How do I create equivalent behavior in V2?
158
+
159
+Consolidate the required destinations and actions into one V2 policy and use rule priority to control evaluation order. If the scenario requires different user or group assignments on individual rules, you can't model it equivalently in V2 today.
160
+
161
+### Can I return to V1?
162
+
163
+Yes. Remove all V2 web filtering policies to restore V1 policy authoring. Existing V1 policies remain available for you to update or delete while V2 policies exist.
135164
136165
## Next steps
137166
⋯ 2 unchanged lines
Microsoft's Markdown source from MicrosoftDocs/entra-docs, © Microsoft Corporation, under MIT. Changed lines with up to 3 unchanged lines around each; ChangeIntel kept this copy 9 Oct 23:21 UTC. The commit date is when the source changed, which can be hours or days before Learn published it.