The Original Perimeter, Reimagined: What Internet Access Gateways Actually Do

Part 2 of "The Gateway Sprawl" series

In Part 1, we mapped out four planes of gateway control and made the case that most organizations only have a clear picture of one of them. For a lot of security teams, that one plane is the internet access gateway — and it's worth starting here, because it's genuinely the most mature, most widely deployed layer in this series. If your org has done any zero trust work in the last five years, this is almost certainly where it started.

From perimeter firewall to SSE

The internet access gateway's job hasn't fundamentally changed since the VPN-and-firewall era — it still sits between users/devices and the internet or internal applications, deciding what traffic gets through and under what conditions. What's changed is where it sits and how much context it has when it makes that decision.

That evolution is what the industry now calls SSE (Secure Service Edge) — often bundled with SD-WAN under the broader SASE umbrella. Instead of backhauling traffic to a data center for inspection, SSE platforms move that inspection to the cloud edge, closer to wherever the user actually is. Zscaler is the name most people reach for here, largely because it was early and aggressive in this space, but the pattern — ZIA for internet-bound traffic, ZPA for private app access, ZDX for experience monitoring — is representative of the category as a whole, not unique to one vendor.

What this plane is good at

It's worth being fair to this layer before we poke at its edges, because the capability here is real:

• Zero trust network access (ZTNA) — replacing the flat-network assumptions of legacy VPNs with per-application, identity-aware access
• Full traffic inspection — SSL/TLS decryption, DLP, malware inspection, and policy enforcement applied consistently regardless of whether the user is on-network, remote, or on an unmanaged device
• User and device context — modern SSE platforms don't just see an IP address; they can factor in device posture, user risk score, and location into the access decision in real time
• Consistent policy at scale — one policy engine enforced globally, instead of a patchwork of site firewalls with drifting rulesets

For the specific problem it was built to solve — governing how users and devices reach the internet and internal applications — this is a mature, well-understood, and genuinely effective category. None of what follows is an argument that this layer is weak. It's an argument that it's narrow, in a specific and important way.

Where the visibility runs out

Here's the boundary worth sitting with: an internet access gateway sees traffic that flows through it. That sounds obvious, but it has a quieter implication — a huge and growing share of access in a modern environment simply never crosses that path at all.

A few concrete examples:

• Service-to-service API calls. When one internal system calls another's API directly — or when a SaaS platform calls another SaaS platform's API via a server-side integration — that traffic frequently doesn't route through the same inspection path as a user's browser session. It's a different plane entirely (we'll get to it in Part 3).
• Machine and workload identities. Service accounts, automation scripts, and CI/CD pipelines authenticate and act constantly, often with credentials that were provisioned once and never revisited. The gateway can see that traffic is moving; it has no native concept of whether the entitlement behind that traffic is still appropriate.
• Increasingly, agent traffic. As AI agents start making tool calls and chaining actions autonomously, that activity often looks nothing like a human browsing session — and existing SSE policy models weren't built with that pattern in mind. We'll spend all of Part 5 on this.

None of this is a flaw in the gateway. It's doing exactly the job it was designed for. The problem shows up when an organization treats "our internet access gateway is deployed and healthy" as a proxy for "we have visibility and control over all access in our environment." Those are not the same claim, and the gap between them tends to stay invisible right up until an audit, an incident, or a stalled compliance review forces someone to ask the question directly.

The tell: "can it get through" vs. "should it exist"

If there's one distinction worth carrying forward into the rest of this series, it's this: an internet access gateway is fundamentally answering "can this traffic get through, right now, given current policy?" It is not designed to answer "should this identity — human, service account, or agent — have this access at all, and does it still need it?"

That second question is an identity governance question, not a traffic inspection question. It's easy to conflate the two, because both get labeled "zero trust" and both show up in the same steering committee slides. But conflating them is exactly how organizations end up in the position from Part 1's opening story: a fully deployed, well-run SSE rollout, and still no answer when someone asks who — or what — can reach the systems that actually matter.

Where this goes next

In Part 3, we'll move one plane over and look at API gateways — the layer that does see a lot of the service-to-service traffic an internet access gateway misses, and where a different, equally important gap opens up: validating that a token is well-formed is not the same as validating that the identity behind it should hold that scope in the first place.