Zero trust, Security Operations, SOC, Application security, Endpoint/Device Security

In defense of zero trust network architecture

3D illustration of a blue network with icons and the text zero trust written on the front. Black background. Concept of secured network.

COMMENTARY: Zero trust network architecture (ZTNA) has recently caught a bit of heat.

Critics argue that ZTNA devices and platforms introduce new risks and fail to deliver on their promise of “zero trust.” Those critiques aren’t without merit; the research was sharp, and some ZTNA implementations deserve the scrutiny.

However, dismissing ZTNA wholesale is a mistake. When done right, ZTNA is one of the most effective evolutions in network access control we’ve seen and solves problems that legacy solutions never could.

VPNs: Yesterday’s security perimeter

Let’s start with the elephant in the room: traditional virtual private networks (VPNs).

VPN appliances are inexpensive and simple to administer. They gained even more popularity during the pandemic, thanks to the surge in remote work. And while a security perimeter is certainly preferable to exposing corporate infrastructure to the public internet, VPNs, and SSL VPNs in particular, have proven to be a significant source of risk.

[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]

Many VPN solutions are built on outdated codebases, run on outdated embedded operating systems that lack modern memory protections, are riddled with basic programming errors in an unsafe programming language, and are patched together with exposed scripting languages that create fresh attack surfaces. These are not theoretical problems.

At Coalition, we routinely see compromises where attackers exploit an unpatched VPN vulnerability or a stolen or leaked credential, leading to a full network breach. A single buffer overflow can turn into remote code execution, which turns into ransomware spreading across the entire environment. This is not advanced nation-state tradecraft; it's the kind of exploitation that feels straight out of the mid-90s and would make for a really fun Capture the Flag competition if it weren’t supposed to be securing our businesses. 

Related reading:


A VPN is essentially a castle-and-moat model. Once attackers are “in” the network, they’re automatically trusted. This works until it doesn’t — and it often doesn’t.

Done properly, network segmentation can help with this problem; however, more often than not, small to midsize businesses have a completely flat network, and when network segmentation is considered, it is often a neglected afterthought. Without segmenting your network and creating additional protections for your ‘crown jewels’, or most critical data and assets, the moat is actually not all that effective. 

Why ZTNA is a better model

Instead of granting broad network access, ZTNA enforces the principle of least privilege at the network layer.

Users and devices get access only to the specific applications or resources they’re authorized for, nothing more. By integrating identity and access into the network controls, the attack surface is dramatically reduced. That means that even if an attacker steals or brute-forces a credential or bypasses multi-factor authentication (MFA), the impact of that compromise is sharply constrained.

ZTNA also removes the need for exposing large swaths of your network to an attacker. Instead of one big perimeter that attackers can hammer on, ZTNA uses microsegmentation and identity-driven policies to minimize exposure. This is a huge step forward in reducing a business’s attack surface.

Now, does ZTNA eliminate all risks? Of course not. But no control does.

The value of ZTNA lies in how it forces organizations to move away from implicit trust models and toward explicit, continuous verification. In practice, businesses that have adopted ZTNA are far less likely to suffer catastrophic breaches originating from compromised remote access.

Critiques of ZTNA are fair but not fatal

Security researchers are correct to highlight concerning weaknesses in some ZTNA implementations, particularly around SSL inspection.

SSL Inspection is a technique to internally decrypt your corporate network traffic before it reaches its destination in order to inspect it for security anomalies. This has historically been done within the corporate network.

If your ZTNA vendor requires you to hand over all your decrypted network traffic to them, while they may provide some novel and impressive network detections and protections, it’s fair to ask if it is really zero trust at that point. You’re placing enormous trust in the vendor’s security posture. And if that vendor is compromised, your data could become collateral damage.

That critique is valid and presents a tradeoff decision for buyers to consider, weighing the benefits of the added detection and protections offered against the corresponding potential exposure. But by no means is this a death sentence for ZTNA as a concept.

In fact, not all ZTNA vendors implement SSL inspection at all. Twingate and Cloudflare Access, for example, operate without an SSL Inspection feature, while still delivering the core promise of ZTNA: incorporating not only authentication but also authorization into the network access layer. It’s important to evaluate vendors carefully and understand their architectural choices. The underlying principles of ZTNA remain sound, and educated security consumers are best positioned to consider the tradeoffs at hand.

Zero trust is a philosophy, not a cure-all

One of the biggest misconceptions about ZTNA is that it’s a product you can buy off the shelf and call it done.

In reality, zero trust is a philosophy, a strategy for continuously reducing implicit trust in your environment. ZTNA is just one (important) piece of a broader defense-in-depth strategy.

If organizations treat ZTNA as a box to check, they may end up with poorly configured systems that create more problems than they solve. But when implemented thoughtfully — with a clear understanding of risks, vendor choices, and architectural fit — ZTNA outperforms VPNs by a wide margin.

ZTNA is not a panacea, nor is any other security product or control. If a vendor ever tells you otherwise, you should always treat that as a red flag in your evaluation. And it’s also true that security vendors will have bugs and may introduce new risks when adding new features. But sticking with brittle VPNs and perimeter-based trust models is far worse. ZTNA represents progress. It enables us to limit exposure, apply least privilege, and reduce reliance on outdated trust assumptions.

The answer isn’t to abandon ZTNA altogether; it’s to educate yourself on the way your security products affect your overall risk posture, demand rapid response from vendors when vulnerabilities are reported, implement security wisely, and continue evolving toward true zero trust. Because if we’re still relying on 1995-era, perimeter-based security thinking in 2025, we’ve made the job of our adversaries 30 years easier.

Joe Toomey

Joe Toomey is vice president of underwriting Security at Coalition.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms of Use and Privacy Policy.

You can skip this ad in 5 seconds