Deploying Entra Internet Access, end to end

Entra Internet Access is Microsoft's identity-aware Secure Web Gateway, delivered as part of Global Secure Access (GSA) — Microsoft's Security Service Edge (SSE) platform. A lightweight client on each endpoint forwards internet traffic to Microsoft's edge, where web content filtering decides what's allowed, and Conditional Access decides who the filtering applies to. No appliance to haul traffic through, no VPN hairpin — the protection follows the user's identity, not their network location.

Why enforcement lives in Conditional Access

This is the mental model that makes the whole thing click: filtering policies are grouped into security profiles, and a security profile does nothing to a user until a Conditional Access session control hands it to them. Identity and network security run from the same policy engine. That's also why a user is protected identically at home, on a plane, or in the office — enforcement rides the Conditional Access session, not the corporate perimeter.

01Prerequisites & client-side gotchas

The filtering silently fails if the client environment isn't prepared. Do these first.

Licensing is Entra Internet Access (standalone or in the Entra Suite) plus an Entra ID P1/P2 base; you'll need the Global Secure Access Administrator and Conditional Access Administrator roles. Devices must be Entra joined or hybrid joined (not "registered" only). But the part that actually bites people is the client environment — get these wrong and traffic quietly evades filtering:

Setting	Why it matters
Disable QUIC in browsers	QUIC (UDP/443) sidesteps the standard HTTP/S ports the platform inspects — leave it on and traffic bypasses filtering
Prefer IPv4 (registry DisabledComponents)	The platform assumes IPv4 on ports 80/443; IPv6 paths can escape acquisition
Disable Secure DNS (DoH/DoT)	Encrypted DNS in the browser hides the name resolution the filter relies on

# prefer IPv4 (per Microsoft guidance for the GSA client)
# HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
# DWORD (32-bit): DisabledComponents = 0xffffffff

# disable QUIC in Chrome/Edge:
#   chrome://flags  → "Experimental QUIC protocol" → Disabled
#   edge://flags    → "Experimental QUIC protocol" → Disabled

These are the "it's not blocking anything" causes

When a category that should be blocked still loads, the culprit is almost always one of the three above — usually QUIC. Bake them into the device build (or push via Intune) before you expect enforcement, or you'll chase policy problems that are really client problems.

02Deploy the GSA client & enable traffic forwarding

Lay the pipe: get traffic flowing to Microsoft's edge.

The client is downloaded from Global Secure Access → Connect → Client download and pushed to endpoints (silently via Intune for a fleet). Once installed and signed in, it shows as connected to Entra — and to Microsoft 365 if that profile is on. Then enable the forwarding profile:

# enable the Internet Access traffic forwarding profile
Global Secure Access > Connect > Traffic forwarding
  → enable "Internet access profile"
  → (recommended) also enable "Microsoft traffic" for optimal M365 path

Bypass precedence, and the "all users" default

A destination bypassed in the Microsoft profile won't be acquired by Internet Access either — Microsoft-profile bypasses supersede it. True exceptions go in Internet Access → View policies → Custom Bypass (FQDN / IP / port). Also note: a forwarding profile enabled for the first time starts with zero users; a profile that was already on applies to all users by default — scope it with group assignment before you flip it if you don't want tenant-wide.

03Create a web content filtering policy

The block/allow rules — by web category or by FQDN.

Under Global Secure Access → Secure → Web content filtering policies → Create policy, you build rules whose destination is either a Web Category (e.g. the liability and high-bandwidth categories you want blocked) or a specific FQDN (to block or allow an individual site). Filtering enforces on the URL for HTTP and the SNI (Server Name Indication) for HTTPS — so it works on encrypted traffic without full decryption.

# a filtering policy is a named set of rules
Policy: "Baseline-Block"   Action: Block
  Rule 1  Destination type: Web Category
          → Adult, Gambling, Hacking, Illegal Drugs, Weapons,
            Violence, Nudity, Crypto Mining, ... (liability set)
          → Image Sharing, Download Sites          (high-bandwidth set)
  Rule 2  Destination type: FQDN
          → block a specific site by name, if needed

Split the blocked set mentally into liability/risk categories (adult, gambling, hacking, drugs, weapons, violence, hate) and high-bandwidth categories (image sharing, download sites). Keeping them separate makes the policy trivial to justify to leadership and easy to reason about later. Everything not blocked is allowed by default, so productivity sites are never touched.

04Bundle policies into a security profile

Profiles are containers — and priority ordering matters.

A security profile (Secure → Security profiles) groups one or more filtering policies and is the object Conditional Access actually links to. Policies within a profile are evaluated by priority number — 100 is highest, 65000 lowest — and evaluation stops at the first matching rule, exactly like firewall rules.

# security profile = ordered container of filtering policies
Profile: "Baseline"
  priority 100    Allow-Exceptions   (allow specific business FQDNs first)
  priority 200    Baseline-Block     (the category blocks)
  # leave ~100 spacing between priorities for future inserts

The Baseline profile always applies

There's a special baseline security profile that enforces at the lowest priority as a catch-all for all Internet Access traffic — and it runs even if no Conditional Access policy links to it, and even when another CA policy links a different profile. Put your organisation-wide "block the clearly-unwanted" rules here so they apply to everyone by default, and use linked profiles for group-specific additions.

05Link the profile via Conditional Access the crux

Conditional Access is the delivery mechanism that makes filtering user-aware.

This is the step that surprises people: a (non-baseline) security profile reaches specific users through a Conditional Access session control. The CA policy targets your user/group scope, points its target resource at Global Secure Access, and under Session applies the security profile.

# the CA policy that delivers the profile
Entra ID > Conditional Access > New policy
  Assignments  Users:  <pilot group>   → later, All users
  Target       Target resources: "All internet resources
                                   with Global Secure Access"
  Session      ✔ Use Global Secure Access security profile
               → select your "Baseline" profile
  Enable       On  → Create

Under the hood: the client authenticates to Entra (seamless if a valid PRT exists), Conditional Access evaluates and attaches the security profile to the access token, a tunnel is established to the SSE, and the edge enforces the profile's rules in priority order — stopping at the first match. Block returns an error (HTTP) or a connection reset (HTTPS); allow forwards to the destination.

Scope with a group on day one

Because enforcement is a CA session control, the blast radius is whatever you target. Start the CA policy against a small pilot group — going straight to "All users" means one mis-scoped category can block the whole company at once. And group assignments require security-enabled groups; nested groups are not supported — members must be direct.

06Verify enforcement

Confirm the client is tunneling and the policy actually blocks.

All verification is in the portal and on the client — no scripting needed:

# on the endpoint
- GSA client tray → Advanced Diagnostics
  → confirm the Internet Access forwarding profile is active
  → confirm traffic flows are being captured

# test
- browse to a site in a BLOCKED category
  → HTTP  = plain-text error
  → HTTPS = connection reset
- browse to an allowed site → loads normally

# in the portal
- Global Secure Access → Monitor → Traffic logs
  → see allowed vs blocked decisions per request

Mind the propagation timing

Web content filtering changes usually apply within ~5 minutes, but changes made through Conditional Access can take up to an hour. If a test doesn't reflect a change immediately, confirm which layer you changed before assuming it's broken — and if nothing blocks at all, re-check the client gotchas from step 1 (QUIC is the usual suspect).

07Phased rollout & exceptions

Widen the assignment, not the policy.

Because enforcement is a CA session control (and the baseline profile covers everyone), rollout is mostly widening the CA policy's user assignment in stages — the filtering rules never change:

Phase 1  pilot: a couple of named users     → validate, watch for over-blocks
Phase 2  one user per department            → surface dept-specific site needs
Phase 3  All users, firm-wide               → baseline enforced everywhere
Phase 4  per-department custom profiles      → e.g. streaming/social limits
                                               for specific groups (optional)

For exceptions, don't weaken the baseline — layer a separate filtering policy (allow a business-critical FQDN, or add extra blocks) into a profile scoped to just that group via its own CA policy. A business-critical site caught by a category block gets an allow rule at a higher priority in a targeted profile; a team that shouldn't have streaming gets an extra block in theirs.

The end-to-end shape

Prepare the client (QUIC off, IPv4, no secure DNS) → deploy the GSA client via Intune → enable the Internet Access forwarding profile → build web content filtering policies (category or FQDN) → bundle them into a security profile with sane priorities → deliver it to users with a Conditional Access session control, while the baseline profile covers everyone by default. Verify with Advanced Diagnostics + Traffic logs, roll out by widening the CA assignment, and handle exceptions with layered profiles rather than weakening the baseline. Enforcement follows identity, so protection travels with the user.