5 Steps to Building an ID-Based Cloud SWG Strategy with Microsoft Entra Internet Access

The Revolution of Web ID-Centric Security: What is Microsoft Entra Internet Access?

We’ve entered an era where web security can no longer be simplified as just an issue “inside or outside the corporate network.” With remote work, business trips, and partner environments becoming the norm, users connect to the internet (Web) from anywhere, and data flows through SaaS applications. Traditional perimeter security (firewalls, on-premises proxies) often hits a wall with one crucial question: “Who is generating this traffic, and under what context?”
This is precisely where Microsoft Entra Internet Access (part of Global Secure Access’s Internet Access) offers a clear solution — redefining web access control with a Secure Web Gateway (SWG) that fuses ID and context awareness.

Solving Web Security Not by “Network” but by “ID”

The essence of Microsoft Entra Internet Access can be summed up in one sentence:

User’s internet traffic is forwarded to the cloud,
Where traffic undergoes domain (FQDN) and web category-based filtering,
Yet policy decisions pivot primarily on Microsoft Entra ID + Conditional Access,
Controlling web access according to user, group, device, and session conditions (context).

In other words, instead of simply saying “Block this URL because it’s risky,” policies now speak the language of:
“Allow/Block/Monitor this user, under these conditions, accessing this web category or domain.”

What Does It Offer as a Secure Web Gateway (SWG)? Core Features Focused on FQDN/Category

As of now, Entra Internet Access’s SWG capability centers on Web Content Filtering.

Category-based control: Apply allow/block/monitor policies based on categories like Adult, Ads, etc.
FQDN-based control: Support for wildcard domain rules like *.example.com
And crucially, all rules operate in tight integration with Conditional Access, enabling truly user-aware, context-aware enforcement.

The key takeaway is scope: this stage isn’t a “full feature SWG” yet. Rather, it’s a model that prioritizes domain/category-axis control combined with identity, implemented proactively in the cloud. This means instead of radical URL path-level granularity or deep content inspection, the focus is on building the framework of ID-based control upfront.

How Web Traffic Is Actually Controlled: Global Secure Access Architecture

For Entra Internet Access to work effectively, user web traffic must first be forwarded via Global Secure Access. The typical flow is:

User attempts to access a website via browser
Global Secure Access client (mainly on Windows) captures and tunnels the traffic to the cloud service
The service gains DNS-based visibility to identify requested FQDN and category
Evaluates security profile + web content filtering policies
Based on the evaluation, traffic is either allowed (forwarded to the internet) or blocked (block response/page)

A very practical operational constraint arises here. As the document states, this model depends on retrieving FQDN based on DNS queries, requiring DNS over HTTPS (DoH) to be disabled. Organizations face a policy trade-off and control challenge between “DNS encryption for privacy” and “visibility for web filtering.”

Surpassing Existing Web Limitations: The Power of Integration with Conditional Access

Traditional web filtering was mostly defined by network equipment rules (proxies/firewalls). Even when users were identified, additional agents or directory integrations were often bolted on. Entra Internet Access flips this by weaving SWG tightly with the ID platform.

“Only allow Group A access to Web Category A, block B”
“Apply stronger filtering for login sessions deemed high-risk”
“Permit access to certain domains only on company-managed devices”

These policies flow naturally using the language of Conditional Access. As a result, web security shifts from a focus on network location to a focus on “Who (Identity) + What state (Context).” This transition is the essence of the ID-centric security revolution that Microsoft Entra Internet Access champions.

At the Heart of Web Technology: How FQDN-Based Web Content Filtering Works

Controlling web access based on domain names? It sounds simple, but the true success lies in where the client sends the traffic and how the service uses clues to determine what site it is. Microsoft Entra Internet Access’s Global Secure Access (a Web Content Filtering-based SWG) is designed precisely around the structure of DNS queries + traffic forwarding at this critical point.

The Path Web Traffic Takes into the Security Service: Client Forwarding Architecture

For FQDN-based filtering to work properly, the user’s web traffic must first be “visible” as it enters the Global Secure Access cloud. Two core prerequisites enable this:

Activating Internet Traffic Forwarding (Traffic Forwarding Profile)
This is a set of rules that reroute a user’s internet traffic through Global Secure Access. Only users/groups with this profile applied have their traffic subjected to SWG policy evaluation.
Installing the Global Secure Access Client (Windows) + Assigning the Profile
The client locally acquires and tunnels traffic, while administrators can verify which forwarding rules are applied through the client’s diagnostic interface.

In summary, this SWG doesn’t block on network edge devices but implements web access control by sending traffic from the endpoint to the cloud security service first.

The Key to Identifying Web Sites: Why ‘FQDN’ and Why ‘DNS’?

The primary scope of this product is based on FQDNs (e.g., news.example.com, *.example.com), not URL path components. In other words, policies focus on “is the user trying to access a site categorized under a specific domain/category?”

The crucial point is how the service discovers the FQDN. This Web Content Filtering assumes DNS queries as the foundation for identifying FQDNs, which brings about these requirements:

Disabling DNS over HTTPS (DoH)
If DoH is enabled, DNS queries are encrypted within the browser and go out via separate channels, making it difficult for the security service to reliably determine “which FQDN this connection is headed to.”
The SWG’s FQDN visibility is tightly linked to the premise of “seeing names through DNS,” and DoH becomes a variable that diminishes this visibility.

In essence, this architecture prioritizes accurately knowing the connection’s target name (FQDN) over deep content inspection.

How Web Policies Are Actually Applied: A Conceptual Workflow

The most confusing part at the field level is “where policies are evaluated and based on what information.” Conceptually, the flow is as follows:

The user attempts to access a website from the browser.
According to the traffic forwarding profile, the client tunnels the internet traffic to the Global Secure Access service.
The service identifies the target’s FQDN and maps it to a web category (e.g., Adult, Ads) or compares it against administrator-defined FQDN rules (including wildcards).
The decision to “allow or block” is not just a simple network policy but includes user, group, and session context.
This is because the SWG policy bundles into a Security Profile and ultimately integrates with Entra Conditional Access session control, applying the security profile per user context.
If allowed, traffic is forwarded to the internet; if blocked, the browser receives a block response (typical SWG blocking experience).

The key takeaway: this web filtering performs “domain blocking” with a conditional access grammar of ID (who) + context (under what conditions).

Limitations From the Web Perspective Stem From This Architecture: Focus on Domain ‘Names,’ Not the Entire URL

Being FQDN-based is both an advantage and limitation.

Advantage: Quickly and simply enforce policies like “this domain/category is unnecessary for work.”
Limitation: Precisely controlling at the path level (e.g., allowing example.com/safe but blocking example.com/risky) is currently difficult — the model centers on FQDNs and categories, not full URL paths.

Ultimately, the “heart” of this SWG is the flow of consolidating traffic via client forwarding, identifying FQDNs based on DNS, and deciding web access via ID/context-based policies. Understanding this structure naturally clarifies why DoH policies, client deployment, and Conditional Access design must be carefully considered together during implementation.

The Complete Flow to Build Web Policies at Once: From Portal Settings to Conditional Access

How are customized web filtering policies actually structured and applied for each user? The key is to connect “Filtering Policy (Web content filtering) → Security Profile → Conditional Access Session Control” in a single line. Once you grasp this connection, what once seemed like complex web access control becomes surprisingly simple.

Start with Web Traffic Forwarding: Create the ‘Path’ Where Policies Will Apply

No matter how sophisticated your filtering policies are, they won’t work unless user traffic reaches the policy engine (Global Secure Access). Therefore, the first step is always to enable the Internet Access Traffic Forwarding Profile.

Navigate in the management portal to Global Secure Access → Secure → Internet Access Traffic Forwarding Profile
Enable internet traffic forwarding and assign the target users/groups
On Windows, deploy the Global Secure Access client and ensure users are included in the forwarding profile
You can verify rule application in the client’s Advanced Diagnostics → Forwarding profile

Technically, this step ensures that the user’s web traffic does not go directly out to the internet locally but is tunneled through the cloud SWG. All subsequent policies are evaluated on this route.

Create a Web Content Filtering Policy: Define Rules by Category or Domain (FQDN)

Next is the step to define actual block/allow criteria.

Path: Global Secure Access → Secure → Web Content Filtering Policy
Create a new policy using Create policy, then add rules with Add rule
- Control based on Web category (e.g., Adult, Ads, etc.)
- Or specify allow/block by FQDN (e.g., *.example.com)

The crucial point here is that the focus is currently on domain-level (FQDN) and category-based controls, not URL path granularity. In other words, rather than blocking specific pages, it’s about creating a fast “first line of defense” model like “block/allow this domain” or “block this category.”

Bundle Web Policies into Reusable Security Profiles: Why It Simplifies Operation

Instead of attaching policies directly to Conditional Access, there’s an intermediate layer called Security Profile, which greatly reduces operational complexity.

Path: Global Secure Access → Secure → Security Profiles
Create a profile, then
Use Link a policy → Existing policy to connect the previously created Web content filtering policy

Think of the Security profile as a “package” that defines which web filtering set applies to which users. As organizations grow and policies multiply, this structure means Conditional Access only selects “profiles” rather than detailed rules.

Enforce Web Policies via Conditional Access: The Key Link for User and Context Awareness

Only at this final step is web filtering enforced based on user ID.

Path: Entra ID → Conditional Access
Create a new policy with settings:
- Target specific users/groups
- Under Target resources: choose All internet resources with Global Secure Access
- In the Session settings, select Use Global Secure Access security profile
- Specify the Security profile created earlier
Turn the policy On to activate it

This setup is the “secret to integration” because web filtering becomes more than just a network equipment rule—it is embedded in Conditional Access session control, enabling:

Different web policies for different users/groups (e.g., executives, developers, interns)
Policy application based on login state and context (context awareness)
Centralized control over “who (user) can access what web resources under which conditions (session/context)”

Why Disable DoH When Web Filtering Relies on FQDN?

A common pitfall during operations is DNS over HTTPS (DoH). Since this SWG filtering relies heavily on identifying domains (FQDN), the documentation advises disabling DoH to ensure traffic is properly tunneled and policies are applied.

In summary:

Web access control requires visibility into “which domain the traffic is going to” to evaluate properly
If DoH obscures this (visibility drops), domain-based policy accuracy suffers
Organizations need to design DoH controls via browser or OS policies accordingly

Master these 4 steps (Forwarding → Web Policy → Security Profile → Conditional Access), and customized web filtering flows seamlessly from policy design to actual enforcement. Rather than creating countless complex rules, laying a solid foundation with the “policy application path and linkage structure” is the fastest path to success.

How Does It Differ from Traditional Web-Based Solutions? The Powerful Differentiators of Microsoft Entra

Conventional Web filtering solutions like Fortinet or Cisco have long established themselves as standards through robust category classification, URL rules, and proxy/firewall-centric policy enforcement. However, Microsoft Entra Internet Access (Global Secure Access) approaches the same "block/allow" actions from a completely different starting point. The key lies in being a cloud-native SWG where policies begin not at the network boundary but from the ‘ID (user) and session context’.

Web Perspective Difference 1: Policies Start from “ID and Session” Instead of “Device/Boundary”

Traditional methods generally follow this flow:

Collect and inspect Web traffic at corporate/branch boundaries (firewalls, proxies)
Apply rules based on IP, subnet, device policies (or limited user mapping)
Remote users connect via VPN to be “brought inside” the boundary before applying the same policies

In contrast, Entra Internet Access ties policies directly to user/group/risk/session conditions through Entra ID + Conditional Access.

“Who (user/group)”
“In what state (device/session context)”
“When accessing what internet resource (Internet resources with Global Secure Access)”
“Which Web content policy (Security profile) to apply”

All these elements are unified into a seamless flow. Consequently, the policy focal point shifts from network topology to ID. This fundamentally transforms the operating model in an environment where hybrid and remote work are the norms.

Web Perspective Difference 2: Cloud-Native “Traffic Forwarding” Enables Uniform Enforcement Anywhere

While Fortinet/Cisco offer highly mature capabilities, consistent Web control typically requires at least one of the following:

Backhauling traffic to branch or corporate sites
Always-on VPN connections
Synchronizing equipment/policies at each location
Separate proxy/client strategies for remote users

Entra Internet Access enforces policies by directly forwarding user traffic to the cloud service via the Global Secure Access client + Internet traffic forwarding profile. Whether at home or on a public Wi-Fi, the “policy enforcement point” is fixed not at the organizational boundary but within Microsoft’s secure service layer.

The practical advantages of this architecture are clear:

Policy scope is less sensitive to changes in network locations
Remote users experience the same Web categories/domains enforced identically
Centralized policy management with fine-tuned targeting of users/groups through Conditional Access

Web Perspective Difference 3: Focused Design on “FQDN & Category + Context” Instead of “Deep URL Inspection”

Traditional solutions often shine in depth of functionality, such as URL path-level control, extensive content inspection, and granular exception handling. Currently, Entra Internet Access’ Web filtering emphasizes FQDN (domain) and Web category-based controls.

Allow/block based on Web categories
Filtering using FQDN wildcards like *.example.com
Policy models combined with user/group/device context

This difference should not be simply seen as “lacking features.” Microsoft’s primary goal is to create an architecture that directly connects ID and security policies to internet traffic enforcement. Whereas legacy SWGs focus more on “deeper inspection,” Entra strongly prioritizes the policy context: who, when, and under what conditions.

Web Perspective Difference 4: Policy Built on DNS Visibility—What the DoH Requirement Implies

Because Entra Internet Access’ Web filtering relies on FQDN identification, the documentation requires disabling DNS over HTTPS (DoH). This is both a critical differentiator and an operational consideration.

Benefit: Reliably identifying FQDNs based on DNS to consistently enforce category/FQDN policies
Challenge: Conflicts with browser/OS trends toward enabling DoH by default, necessitating organizational DNS policy and control

In other words, Entra’s method reveals an architectural choice that simplifies Web control based on ID but presupposes obtaining DNS visibility as a prerequisite.

In summary, while Fortinet and Cisco have evolved deep and robust Web control centered on network boundaries, Microsoft Entra Internet Access positions itself as a cloud-native SWG experience integrated with ID and Conditional Access. Even though it’s still Web filtering at heart, the biggest transformation is that the conversation shifts from “where to place equipment and how to route traffic” to “whose session to apply which policies to.”

Web Limitations and the Future: Entra Internet Access Evolving Beyond Current Constraints

The requirement to disable DNS over HTTPS (DoH) and the focus on handling URLs only at the "domain (FQDN)" level clearly represent limitations of the current version. However, these constraints also serve as a roadmap illustrating “where current controls are feasible and where the next stage of innovation begins.” Understanding this boundary precisely clarifies the direction Entra Internet Access will take to expand Web security architecture.

Current Web Limitations: Structural Constraints of FQDN-Centric SWG

Web 1) DoH Disablement Requirement: Visibility (Security) vs. Privacy (Encryption) Conflict

Entra Internet Access’s Web Content Filtering is designed to apply policies based on identifying FQDNs through DNS queries. Thus, if DoH is enabled in browsers/OS, DNS queries get encrypted over HTTPS, making it difficult for the service to maintain domain visibility and potentially lowering filtering accuracy, leading to the requirement to disable DoH.

Technically, this implies:

Policy enforcement depends on DNS visibility
The core axis is discovering “which web destination is being accessed” through DNS.
Operational fragmentation risk
Users changing DoH settings per browser or OS updates altering defaults could cause policy bypasses or false positives.
Security philosophy trade-off
Organizations must balance “privacy/integrity gained via DNS encryption” against “visibility for the security gateway.”

Web 2) Limited URL-Level Inspection: Blocking ‘Domain’ but Difficult to Distinguish ‘Paths’

Currently, filtering is heavily concentrated on category and FQDN-based controls, resulting in practical limitations like:

Difficulty distinguishing service paths within the same domain
For example, allowing example.com/login but blocking example.com/upload is challenging.
Inability to reach content-based inspections (files, body, threat indicators)
This is far from the deep inspection (e.g., HTTPS traffic analysis, content policies) offered by traditional “full SWG.”
Increase in exception handling (whitelisting)
Handling only domain-level controls may force organizations to wholly allow domains to enable specific functions, weakening security posture.

Web 3) Client/Forwarding Dependency: ‘Policies’ Require ‘Correct Traffic Routing’ to Apply

This model mandates users’ web traffic be forwarded to Global Secure Access for policies to function, highlighting crucial factors:

Client deployment and state management (especially Windows-centric)
Verifying correct user assignment to forwarding profiles
Establishing diagnostic and operational processes based on forwarding profiles

Future Web Expansion: The Potential Evolution to “ID-Centric SWG”

The current limitations reflect “what was prioritized in the initial SWG functionality.” Microsoft has likely aimed first to build the backbone of ID/context-based web control integrated with Entra ID + Conditional Access and plans to expand functionality from there.

Web 1) Expansion toward Deeper URL and Application-Level Control

Expected future advancements include:

Granular policies based on URL paths and queries (e.g., blocking specific upload endpoints)
Application/behavior-based controls (e.g., restricting “attachment uploads” rather than just a broad “webmail category”)
Elevating precision while maintaining the benefits of category and FQDN filtering

Web 2) Enhanced TLS (HTTPS) Visibility Options and ‘Inspection Level Choice’ Models

Since most enterprise web traffic is HTTPS, realistic security enhancement requires:

Selectable inspection levels for organizations
For example, default domain-level filtering, with stronger inspection applied selectively to certain groups or high-risk sessions
Risk-based adaptive policies
Utilizing Conditional Access signals (user risk/device state/location) to naturally enforce “lenient under normal conditions, tighten under risk” policy models

Web 3) Mitigating DoH/Visibility Issues: Coexistence of ‘Encryption’ and ‘Policy Enforcement’

The mandate to disable DoH is likely to ease over time. Possible directions include:

More sophisticated integration with endpoint/browser controls
Instead of an outright “DoH OFF” rule, controlled DNS routing via policy compliance on managed devices
Diversifying visibility mechanisms
Combining DNS with other signals (session/connection metadata) to improve accuracy of web destination identification

Web 4) Platform Expansion and SSE Ecosystem Integration

Real-world security operations must accommodate diverse OSes/devices, prompting expansion such as:

Broader client support including macOS and mobile
Tighter integration with Defender, Purview, etc. (data protection, threat detection, unified policy)
Ultimately evolving “web access control” from a standalone feature to an integrated policy uniting ID, endpoint, and data governance

Web Summary: ‘Current Limits’ Foretell ‘Next-Gen Expansion’

Entra Internet Access’s Web Content Filtering today centers on FQDN/categories and faces practical constraints like DoH disablement. Yet it already offers a powerful foundation with ID-centric control integrated with Conditional Access. As URL granularity, HTTPS visibility options, and platform breadth expand, the approach of “controlling the internet by identity, not network” is poised to become the new standard in web security.

The Trend Blender