ZTNA: Almost, But Not Quite - Why Access Is Not Protection

This article does not attempt to define Zero Trust. Instead, it examines why network-access frameworks fail to stop data leaks—and why true security requires a move toward Data-Centric Zero Trust.

A recent critical bug in Fluent Bit—a logging tool used by nearly every major cloud provider—revealed a systemic flaw in modern security: cross-tenant data leaks occurred even in environments with "robust" Zero Trust Network Access (ZTNA). This incident confirms a harsh reality: ZTNA secures the handshake, but it does not secure the handoff. If your security strategy stops at access, you aren't protecting data; you’re just vetting its kidnappers.

The Common Assumption: Validating Identity is Enough to Prevent Data Exfiltration

Most organizations believe that implementing ZTNA means they have achieved "Zero Trust." The prevailing logic is that replacing broad VPNs with identity-based, per-session verification makes the data behind those sessions inherently safe.

Why Point-of-Entry Verification Fails Against Infrastructure Vulnerabilities

The problem is that ZTNA is fundamentally a "point-in-time" or "point-of-entry" gatekeeper. It treats trust as a binary switch: once the switch is "on," the data is exposed.

• Trust is abused after verification: 94% of ZTNA solutions fail to provide continuous adaptive trust. Once a user is "in," the network assumes their subsequent actions are benign.

• The "Authorized" Leak: ZTNA cannot distinguish between an employee viewing a file and an employee exfiltrating that same file to a personal drive.

• Infrastructure is fallible: As seen with the Fluent Bit vulnerability, if the underlying cloud logging or transit layer is compromised, your network-level "access controls" are bypassed entirely.

• The "Absolute Zero" Paradox: Total Zero Trust would mean zero access and zero business. Because business requires access, ZTNA must eventually grant trust—and that is exactly where the risk begins.

What Actually Happens: How "Authorized" Entities Abuse Implicit Network Trust

In a standard ZTNA environment, an "authorized" insider can access a sensitive report, encrypt it with their own key, and send it to an external network. The IDP (Identity Provider) sees a valid credential; the ZTNA controller sees an authorized session; the firewall sees encrypted traffic.

Every layer of the network says "Yes," while the data is being stolen. Because the security was not embedded in the data, the protection evaporated the moment the access was granted. This underscores why protecting sensitive unstructured data must be the focus of the next phase of security evolution.

Why This Matters Now: The Shift from "Reasonable Effort" to "Technical Enforcement"

We are entering an era of "Third-Party Everything." Your data lives in SaaS apps, is processed by third-party AI models, and is logged by external cloud tools.

You no longer own the network, so you cannot rely on network-access controls as your primary defense. This aligns with the NIST Zero Trust Architecture (SP 800-207), which emphasizes that data should be protected independently of its network location. Regulatory frameworks are shifting focus from how you secured the perimeter to how you protected the record. Without data-centricity, you are liable for what happens to data after the ZTNA tunnel ends.

The Missing Control Layer: Selective Encryption as the Final Line of Defense

The gap isn’t better identity verification; it’s Granular Data-Layer Enforcement. We must "Shift-Up" zero-trust principles from the network to the individual data fields within a document.

This means implementing selective encryption to reinforce ZTNA. If an unauthorized entity gains access to a document, they should see only encrypted noise, whereas an authorized user sees only the fields necessary for their role.

Key Takeaways

• Access is not Protection: ZTNA gates the entrance; it does not guard the assets inside.

• Continuous Trust is a Myth in Networking: Most ZTNA is point-in-time. Protection must be persistent and follow the data.

• The Data is the New Perimeter: Since you cannot trust the network or the components, the data must be self-protecting.

• Shift-Up for Resilience: Extending least-privilege to the data-field level prevents "authorized" entities from abusing the trust they are granted.