Alright, let's talk about Trusted Network Detection, or TND for short. If you've been living in the Cisco Secure Access world for any amount of time and have deployed the Zero Trust Access (ZTA) client, you've probably stumbled across this setting and asked yourself one of two questions: "what on earth does this do?" or the more dangerous "I don't know what this does, so I'll leave it alone." Let's fix both of those.

First, A Little Context (Bear With Me)

Before we can appreciate what TND does, we need to appreciate what the ZTA client does — and more importantly, what it does to your traffic.

When a user has the Cisco Secure Access ZTA client installed and active, it intercepts traffic on the local machine and sends it through a QUIC/MASQUE tunnel to the Cisco SSE ZTA Ingress Proxy living somewhere out there on the Internet. This is the magic behind Zero Trust Network Access — your applications don't need to be exposed to the Internet, your users don't need a traditional VPN, and access decisions are made on a per-application, per-user, per-posture basis. Beautiful stuff.

Now — where does this beauty start to get complicated? On your trusted network, that's where.

What Is Trusted Network Detection?

At its core, TND is a mechanism that allows the ZTA client to determine whether or not it is connected to a trusted network — your corporate LAN, campus Wi-Fi, and so on. When TND detects that the client is on a trusted network, it can be configured to take action; specifically, to disengage the ZTA client tunnel and allow traffic to flow natively on the network as it would have before the ZTA client ever entered the picture.

How does TND determine it's on a trusted network? It does so by running up to three different types of checks against the network the client is currently connected to. Before we get into each check type, there is an important piece of logic to understand that governs how these checks work together, because it will inform how you design your TND configuration.

With that in mind, here are the three check types available to you.

Once all configured check types are satisfied simultaneously, TND concludes the client is on a trusted network and the client can be configured to disengage tunnel operation for private traffic, Internet traffic, or both — depending on how aggressive you want to be.

Okay, But Why Would I Want This?

Great question. And the answer, as is tradition in networking, is it depends. But let me give you the scenarios where TND stops being optional and starts being the right call.

Scenario 1 — Performance to Private Applications

Let's think about what happens to traffic destined for a private application when the ZTA client is active and the user is sitting on the corporate LAN — figuratively two feet away from the data center the application lives in. Without TND, that traffic leaves the machine, gets tunneled out to the SSE cloud ingress proxy somewhere on the Internet, the access policy gets evaluated, and the traffic is proxied back to the private application. Round-trip through the Internet. For an application that might be 2ms away on the local network, this arrangement is...not ideal.

Now, here is the critical qualifier. If your trusted network is already enforcing your company's Zero Trust access principles — meaning you've got strong identity-aware network access control, proper segmentation, and the right policy enforcement baked into the network fabric itself — then you have a legitimate argument that proxying private application traffic through the SSE cloud is redundant overhead. TND to the rescue. Disengage the ZTA client for private traffic on the trusted network, let the traffic flow natively, and enjoy the performance improvement that comes with not hairpinning your data center traffic through the Internet and back.

If, on the other hand, the trusted network is just a network — no meaningful access control, no segmentation, nothing that would stand in for what ZTA is doing on behalf of that user — then disengaging the ZTA client on that trusted network is giving up your only enforcement point. In that case, keep TND out of the picture for private traffic.

Scenario 2 — Performance to Internet Destinations

The same performance argument applies here, though the gradient is generally less pronounced for Internet-bound traffic than it is for private applications. On the trusted network, your Internet traffic is likely already traversing a local breakout before it hits the public Internet, so the overhead introduced by the ZTA client tunnel is measured against the raw latency of the Internet itself — a somewhat forgiving baseline. That said, if you're running latency-sensitive SaaS applications or real-time media over the trusted network, every millisecond counts, and TND is still worth considering for Internet traffic as well.

The Part Nobody Warned You About — Read This Carefully

Alright. Pull up a chair, because this is where the plot thickens.

Remember how we established that the ZTA ingress proxy lives on the Internet? Here is why that matters more than you might think, and it creates a scenario that I would describe as an unintentional double-dip through your security stack.

Many organizations deploying ZTA are also using Cisco Secure Access for Secure Internet Access (SIA). In those deployments, the trusted network is already established with a tunnel — typically an IPsec or GRE tunnel from the perimeter firewall or router — going up to the SSE cloud to ensure all Internet-bound traffic gets scrubbed by the full security service chain: DNS security, web filtering, CASB, IPS, the works. This is great! This is the design working as intended for Internet traffic.

Now here is the problem. The ZTA client on the user's machine is configured to send traffic to the SSE ZTA ingress proxy — which, let's say it together, is an Internet destination. So what happens to traffic destined for that ingress proxy when the user is sitting on the trusted network? That's right — it gets swept up by the SIA tunnel and sent to the SSE cloud for inspection. The SSE cloud scrubs it on the way through (pass one), delivers it to the ZTA ingress proxy, and then the ingress proxy processes that same traffic through the security service chain again on behalf of the ZTA session (pass two).

So what do you do about it? You've got two clean paths forward.

Which option belongs in your environment? Come back to that earlier question: is your trusted network itself enforcing your company's Zero Trust access principles? If yes, Option B is your friend. If the honest answer is no, Option A is the safer bet — it eliminates the double-inspection problem without surrendering ZTA enforcement on the trusted network.