# 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. *Ben Chen, Co-Founder & CTO, LayerV — 2026-02-05* Tags: Zero Trust, ZTNA, Network Hiding, Zscaler, Cloudflare Access Source: https://layerv.ai/blog/zero-trust-vs-network-hiding/ --- 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 doesn't hide infrastructure at the network layer.** With [Zscaler Private Access](/compare/layerv-vs-zscaler-private-access), applications register with the Zscaler cloud and run connectors. The broker hides applications from direct internet access. But the connectors have network presence. DNS entries exist. Port scans can reveal that services exist behind Zscaler. With [Cloudflare Access](/compare/layerv-vs-cloudflare-access), a reverse proxy authenticates users at the edge. But the origin server has a public IP. Certificate transparency logs, historical DNS records, and IP scanning can reveal the origin. In both cases, a determined attacker can discover that infrastructure exists — even if they can't immediately access it. And discovery is the prerequisite to attack. ## 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: 1. **Network hiding** eliminates the attack surface. Protected resources have zero network presence. Scanners, bots, and attackers find nothing. 2. **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](/glossary/zero-trust-architecture) 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](/blog/white-house-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](/glossary/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 in the playground](/qurl/playground) — no signup required. --- *This markdown version is auto-generated from [https://layerv.ai/blog/zero-trust-vs-network-hiding/](https://layerv.ai/blog/zero-trust-vs-network-hiding/). For the full interactive experience, visit the HTML version.*