Egress Control in ZTNA: Designing Against Data Exfiltration

In “Zero Trust” conversations the focus usually lands on access: Who can reach which device and which application? ZTNA projects most often solve that and call it done. But the bulk of incidents (and real leaks) doesn’t come from “getting in”; it comes from getting out:

• bulk data pulls from APIs
• service accounts that are authorized but with “more than needed” reach
• direct-to-internet egress to C2/Dropbox/personal storage
• uncontrolled data flow from the internal network to SaaS

This post focuses on the second half of ZTNA, the egress control side, designed to be operational and actionable.

What does egress control mean?

Egress control means deciding which destinations, with which protocols, under which conditions users and services may reach, and enforcing that in a measurable way.

Within ZTNA, egress is more than “internet egress.” For example:

• production VPC -> SaaS API
• application pod -> external webhook
• CI runner -> package repository
• jump host -> management interfaces

For this reason, think of egress control not as “a single firewall ruleset” but as the combination of identity + context + destination.

The three layers of egress: Identity, destination, behaviour

In the field I treat egress in three layers:

1. Identity: user, device, service account, workload identity
2. Destination: domain/IP/ASN, SaaS, API endpoint, repo, registry
3. Behaviour: rate, volume, time, geography, anomaly, data class

If you don’t combine these three layers, you’ll either be too open or you’ll break everyone’s workflow.

Design starting point: Inventory + a “normal flow” map

The first deliverable for good egress control isn’t a “ruleset”; it’s a flow map.

Starting questions:

• Which services must reach the internet?
• Which services should only reach specific SaaS/APIs?
• Which domains/registries does CI/CD touch?
• How does DNS resolution work in production (is there split-horizon)?

In practice I assemble the map from these sources:

• Proxy/NGFW logs (dest domain, byte, user/workload)
• VPC flow logs (IP/port)
• DNS query log (domain)
• Application config / IaC (endpoint lists)

Policy model: “Service-centric allowlist”

For ZTNA egress, the model that pays off the most:

• Default deny (at least for prod)
• Per-service allowlist (domain/IP/port)
• Time-bounded “break-glass” exceptions

The service-centric approach scales as the organization grows. A “let the network team write a rule for everything” model doesn’t scale.

Sample policy statements:

• payments-api only bank-gateway.example.com:443 and kms.<cloud>:443
• ci-runner only npmjs.org, registry.npmjs.org, github.com, objects.githubusercontent.com
• support-jump only to idp, pam, monitoring, ticketing systems

ZTNA agent + egress proxy: The most practical combination

Many ZTNA solutions provide application access “via a tunnel.” For egress there are two practical paths:

1. Explicit proxy (PAC/WPAD or via agent)
2. Transparent egress (a gateway enforcing at L3/L4)

The approach I prefer:

• For users, explicit proxy: better domain control + the option for TLS inspection
• For workloads, a gateway: centralized enforcement instead of eBPF/sidecar (varies by cluster)

What matters here isn’t a “single product”; it’s the combination of signals: ZTNA identity + proxy destination + gateway flow.

Data exfiltration scenarios and control points

Scenario 1: An authorized user pulling data in bulk

Controls:

• API rate-limit (identity-based)
• Query audit log + anomaly (out-of-norm volume)
• Step-up auth at “high risk” hours/locations

Scenario 2: A service account sending data to a new SaaS

Controls:

• Egress allowlist (block new domains)
• “New destination” alarm (per service)
• Change-management integration (approved destination list)

Scenario 3: Malware C2 communication

Controls:

• DNS filtering + threat intel
• ASN/geo-based blocking (baseline)
• Categorical block + reputation at the proxy

Operations: Without exception management, the project dies

The most common breakage in egress control is the “exception.” Minimum design for exception management:

• The exception’s owner (service owner), reason and duration
• Approval mechanism (change management)
• Automatic rollback (must close when the TTL ends)
• Telemetry: an “exception usage” metric

The ruleset will grow over time. For sustainability your goals should be:

• Fewer “global rules,” more “service rules”
• IaC that exposes drift (policy as code)
• A single answer to “who has what open” during audit

Closing: Tie ZTNA to data security

ZTNA starts with “access control” but it’s completed by “data control.” A ZTNA without egress control becomes, in many organizations, “a system that regulates entry but watches the exits.”

Start small:

• First inventory the egress of your prod workloads
• Apply allowlists for your top 5 critical services
• Put exception management (TTL + approval) in from the start
• Turn on “new destination” and “anomalous volume” alarms