Zero Trust vs Network Hiding: What Comes After ZTNA
ZTNA verifies identity at the application layer but infrastructure remains visible. Network hiding eliminates visibility at the network layer. Here's why the next evolution matters.
Zero Trust Network Access has been the gold standard for secure access since Forrester coined the term and Gartner validated the category. ZTNA solutions like Zscaler Private Access and Cloudflare Access have replaced VPNs at thousands of enterprises by enforcing "never trust, always verify" at the application layer.
But ZTNA has a blind spot. And it's the same blind spot that VPNs had.
The ZTNA Blind Spot
ZTNA operates at Layer 7 — the application layer. It verifies user identity, checks device posture, and grants access to specific applications. This is a massive improvement over VPNs, which grant broad network access after a single authentication.
But here's the gap: ZTNA still publishes a front door.
To be fair to the architectures: with Zscaler Private Access, App Connectors dial out from your network, so private apps have no inbound exposure. With Cloudflare Access, Cloudflare Tunnel does the same — the origin needs no public IP. (Origin-IP discovery via certificate transparency, DNS history, or IP scanning applies to proxied-DNS setups without Tunnel.)
What both models keep public is the front door and the grant. An Access-protected hostname resolves in public DNS, appears in certificate transparency logs, and answers every visitor with a login page — the app's existence is discoverable and its front door probeable. And access is a standing entitlement or session for enrolled users, not something you can mint for one task and let expire.
What Network Hiding Adds
Network hiding operates at Layer 3/4 — the network layer. It makes infrastructure invisible before any application-layer check happens.
| Aspect | ZTNA | Network Hiding | | --------------------- | -------------------------------------------- | --------------------------------------- | | Layer | Application (L7) | Network (L3/4) | | Visibility | Infrastructure discoverable at network layer | Zero network presence | | Port scan result | Connection refused or timeout | No response (host appears non-existent) | | DNS | Entries exist for broker/proxy | No DNS entries for protected resources | | Authentication timing | After network connection established | Before any network visibility | | Discovery resistance | Partial — broker fingerprinting possible | Complete — nothing to fingerprint |
The key insight: ZTNA controls access to visible infrastructure. Network hiding eliminates visibility of the infrastructure itself. These are different operations at different layers of the stack.
ZTNA + Network Hiding: The Complete Model
The strongest security posture combines both:
-
Network hiding eliminates the attack surface. Protected resources have zero network presence. Scanners, bots, and attackers find nothing.
-
ZTNA principles govern access policies. When a user authenticates, they get access based on identity, device posture, location, and time — the zero trust principles that ZTNA pioneered.
This is what NIST 800-207 actually describes when it talks about zero trust architecture — but most implementations stop at the application layer. Network hiding completes the model by extending zero trust to the network layer.
Why This Matters Now
Three trends are making network-layer hiding urgent:
1. AI-powered reconnaissance. Automated scanning tools are faster and smarter than ever. LLM-powered agents can enumerate infrastructure, identify vulnerabilities, and chain exploits with minimal human intervention. Application-layer controls can't prevent discovery.
2. Supply chain attacks. Attackers increasingly target infrastructure components (VPN concentrators, SSO gateways, ZTNA connectors) rather than applications. If the infrastructure is invisible, there's nothing to target.
3. Regulatory pressure. The White House national cyber strategy explicitly calls for denying initial access — not just controlling access, but preventing discovery. ZTNA alone doesn't meet this bar.
The Practical Difference
Consider an EKS API server on AWS:
ZTNA-only: The API server is behind a ZTNA broker. Users authenticate before accessing it. But the server has a public endpoint, the broker has fingerprints, and a determined attacker can discover it exists.
ZTNA + Network hiding: The API server has zero network presence. It doesn't respond to anything until a user presents a valid qURL after authenticating through Okta. Port scans return nothing. DNS returns nothing. The server doesn't exist to the internet.
The difference is between "access controlled" and "undiscoverable." In a world where reconnaissance is automated and fast, undiscoverable wins.
What This Means for Your Architecture
If you're already running ZTNA, you don't need to rip it out. Network hiding adds a layer beneath it — making the infrastructure invisible before ZTNA's application-layer controls kick in.
The question for security teams: for how much of your infrastructure is "access controlled" sufficient, and how much should be "undiscoverable"?
For internal applications, admin panels, APIs, and cloud infrastructure — the answer is increasingly "undiscoverable."
LayerV implements network hiding at the network layer, complementing your existing ZTNA investment. Try it with the CLI — free, no credit card.