Zero Trust vs Zero Trust-Washing

Zero Trust is having a moment. Every vendor in cybersecurity is claiming they do it. ZTNA is on every product roadmap. Executives are asking for it by name. And that's created a problem: the term has been diluted to the point of meaninglessness.

At PulseHA, we build genuine Zero Trust Network Access solutions. We've also watched competitors slap "Zero Trust" labels on products that are fundamentally unchanged VPNs, firewalls, or network access controllers. It's frustrating—not just because it's misleading, but because it leaves organizations thinking they're protected when they're not.

This is Zero Trust-washing. And if you're evaluating solutions, you need to know how to spot it.

What Zero Trust Actually Means

Before we can identify the fakes, let's establish what real Zero Trust actually is. The term was coined by Forrester Research analyst John Kindervag in 2010, and the core principle is deceptively simple:

Never trust, always verify.

But that's not just a slogan. It translates into specific architectural requirements:

1. Identity-centric access control — Authentication is based on user and device identity, not network location
2. Least-privilege access — Users get access only to specific resources they need, not entire networks
3. Continuous verification — Trust is re-evaluated constantly throughout the session, not just at login
4. Micro-segmentation — Applications and resources are isolated from each other
5. Assume breach — The architecture assumes attackers are already inside and limits their ability to move laterally

If a solution doesn't deliver on these five pillars, it's not Zero Trust. It might be better than nothing. It might even be good. But it's not Zero Trust.

The Red Flags of Zero Trust-Washing

Here's how to tell if you're looking at a rebranded legacy tool instead of genuine ZTNA:

Red Flag #1: "Zero Trust VPN"

This is the most common offender. A vendor takes their existing VPN product, adds MFA and maybe some basic device checks, and calls it "Zero Trust."

Why it's not Zero Trust: Traditional VPNs grant network-level access. Once you authenticate, you're on the network and can see everything your permissions allow—and often probe things they don't. Real ZTNA never puts users "on the network." It brokers application-specific connections. You can't see what you're not explicitly granted access to.

What to ask: "If a user authenticates successfully, can they discover and attempt to access resources they're not authorized for?" If the answer is yes—or if there's any hemming and hawing—it's not Zero Trust.

Red Flag #2: Authentication Happens Once

Zero Trust-washed products often check identity and device posture at connection time, then trust you for the duration of the session.

Why it's not Zero Trust: Continuous verification is non-negotiable. A device that's healthy at 9 AM might be compromised by 11 AM. A user in London at login might suddenly appear in Lagos mid-session. Real ZTNA constantly re-evaluates trust based on real-time signals.

What to ask: "How often is device health and user context re-evaluated during an active session? What happens if a risk signal is detected mid-session?" If access isn't continuously monitored and can't be revoked in real-time, it's not Zero Trust.

Red Flag #3: "Zero Trust Firewall" or "Zero Trust Network Segmentation"

Some vendors rebrand their next-gen firewalls or network segmentation tools as Zero Trust. Yes, segmentation is part of Zero Trust architecture. But a firewall that segments based on IP ranges or VLANs is not the same as identity-based micro-segmentation.

Why it's not Zero Trust: Real Zero Trust doesn't care about network topology. Access decisions are based on who you are, what device you're using, and what you're trying to access—not which subnet you're coming from.

What to ask: "Are access policies enforced based on IP addresses or network location, or purely based on identity and context?" If network location plays any role in the access decision, it's not Zero Trust.

Red Flag #4: It Requires Complex Network Changes

One of the selling points of real ZTNA is that it works over existing networks. You don't need to rearchitect your infrastructure, reconfigure switches, or deploy agents on every server.

Why it's a red flag: If a vendor is telling you that implementing "Zero Trust" requires significant network re-engineering, new hardware, or changes to your routing tables, they're likely selling you a traditional network security product with a fresh coat of paint.

What to ask: "What changes to our existing network infrastructure are required to deploy this?" Real ZTNA should overlay on your current setup with minimal disruption.

Red Flag #5: Users Still "Connect to the Network"

Listen to the language vendors use. If they talk about "connecting to the corporate network" or "tunneling into the environment," that's VPN thinking—not Zero Trust thinking.

Why it's not Zero Trust: Real ZTNA doesn't create a tunnel to a network. It creates direct, encrypted connections to specific applications. Users never "join" anything. They simply access what they're authorized to use.

What to ask: "When a user accesses an application, are they placed on a corporate network, or do they connect directly to the application itself?" The answer will tell you everything.

Red Flag #6: No Identity Provider Integration Required

If a solution claims to be Zero Trust but doesn't require integration with your identity provider (Azure AD, Okta, Google Workspace, etc.), that's a massive red flag.

Why it's not Zero Trust: Identity is the foundation of Zero Trust. Real ZTNA solutions authenticate users through your existing IdP, leverage SSO, enforce MFA, and make access decisions based on identity attributes. If it's using its own authentication system or storing credentials locally, it's not Zero Trust.

What to ask: "How does this integrate with our existing identity provider? Can access policies be based on group membership, roles, or other identity attributes?" If the answer is vague or suggests manual user management, walk away.

Red Flag #7: It's Cheap and Easy

Zero Trust done right requires investment—not necessarily in the product itself, but in planning, integration, and thoughtful policy design. If a vendor is promising "Zero Trust in a box" with minimal setup and rock-bottom pricing, be skeptical.

Why it's a red flag: Real Zero Trust requires defining policies, integrating with identity systems, onboarding applications, and continuous tuning. It's not plug-and-play. Vendors selling instant Zero Trust are likely oversimplifying to the point where the solution isn't actually delivering on the architecture.

What to ask: "What does the implementation process look like? How long does it typically take? What prerequisites do we need?" If the answer is "install and go," it's probably not Zero Trust.

The Litmus Test: Five Questions to Ask Any Vendor

If you're evaluating a solution claiming to be Zero Trust, here's a quick five-question litmus test:

1. "Can an authenticated user discover or access any resource they're not explicitly authorized for?"
   • Zero Trust answer: No. Users only see what they're granted.
   • Zero Trust-washed answer: "Well, they can see the network, but access is controlled..."
2. "Is device health and user context continuously monitored throughout the session?"
   • Zero Trust answer: Yes, and access is revoked immediately if risk signals are detected.
   • Zero Trust-washed answer: "We check at login time" or "We can do periodic checks."
3. "Are access policies based on network location or IP address in any way?"
   • Zero Trust answer: No. Only identity, device posture, and context matter.
   • Zero Trust-washed answer: "We use network segmentation to enhance security..."
4. "When a user accesses an application, are they placed on a corporate network?"
   • Zero Trust answer: No. Direct, encrypted connection to the application only.
   • Zero Trust-washed answer: "They connect through a secure tunnel..." (that's a VPN).
5. "How does this integrate with our identity provider and enforce attribute-based access control?"
   • Zero Trust answer: Direct integration with your IdP, policies based on identity attributes.
   • Zero Trust-washed answer: "We have our own user management system" or vague integration claims.

If a vendor struggles with any of these questions, you're not looking at real Zero Trust.

Why Zero Trust-Washing Matters

You might be thinking, "Okay, so it's not technically Zero Trust. But if it's still more secure than what I have now, does it really matter?"

Yes. It matters. Here's why:

False sense of security. If you think you've implemented Zero Trust but you've actually just deployed a slightly better VPN, you're making decisions based on a flawed understanding of your security posture. You might relax other controls, assume lateral movement isn't possible, or fail to monitor for insider threats—because you believe Zero Trust has you covered.

Missed opportunities. Real Zero Trust delivers tangible benefits: better user experience, improved visibility, reduced attack surface, and the ability to support modern work patterns. If you settle for Zero Trust-washing, you're not getting those benefits. You're stuck with the limitations of legacy architecture wrapped in new terminology.

Compliance risk. Many regulatory frameworks and cybersecurity standards are starting to reference Zero Trust explicitly. If auditors dig into your implementation and find it's not actually Zero Trust, you could face compliance issues—even if the vendor promised it was.

Wasted investment. You're spending time, money, and political capital on a "Zero Trust" project. If it's not real, you'll eventually need to do it again properly. That's wasted budget, wasted opportunity cost, and wasted credibility with leadership.

What Real Zero Trust Looks Like in Practice

Let's make this concrete. Here's what a legitimate Zero Trust implementation actually involves:

Phase 1: Identity Foundation You integrate your ZTNA solution with your existing identity provider. Users authenticate via SSO. MFA is enforced. Access policies are defined based on user attributes, group membership, and roles.

Phase 2: Application Onboarding You identify the applications and resources users need access to. Each one is onboarded into the ZTNA platform. Policies are defined: who can access what, under what conditions. This isn't a one-time setup—it's an ongoing process as applications change.

Phase 3: Device Trust You deploy lightweight agents or connectors that continuously assess device health. Is the OS up to date? Is antivirus running? Are there signs of compromise? Devices that don't meet your standards are denied access or restricted to lower-risk resources.

Phase 4: Continuous Monitoring Once deployed, the system constantly evaluates every access request. Context matters: location, time of day, behavior patterns. If something looks off, access is challenged or revoked. Every action is logged with full context for visibility and compliance.

Phase 5: Iteration and Refinement You tune policies based on real-world usage. You onboard new applications. You adjust risk signals. Zero Trust isn't a product you deploy—it's an architecture you live in.

If a vendor isn't talking about these phases—if they're promising instant deployment with no identity integration, no application onboarding, and no ongoing tuning—they're not selling you Zero Trust.

The PulseHA Approach: Precision and Resilience

At PulseHA, we're building Zero Trust solutions designed for high availability and real-world use. That means:

True identity-centric access. Every request is authenticated and authorized based on who you are, not where you're connecting from.

Application-level segmentation. You get access to the apps you need, nothing more. No network visibility. No lateral movement.

Continuous verification. Device health, user behavior, and context are monitored in real-time. Trust is never assumed.

Resilience by design. Our customers depend on access. When your ZTNA goes down, your business stops. We build for high availability because uptime isn't optional.

We're not here to rebrand old technology and call it Zero Trust. We're here to build the infrastructure that actually delivers on the promise: secure access from anywhere, for anyone, without compromising on resilience or user experience.

And we're not interested in Zero Trust-washing. The architecture is too important, and the risks are too real.

How to Protect Yourself from Zero Trust-Washing

If you're evaluating solutions, here's how to protect yourself:

Demand proof of concept. Don't take marketing claims at face value. Insist on a hands-on POC where you can test the five litmus test questions yourself.

Talk to references. Ask the vendor for customers who've deployed their "Zero Trust" solution. Then ask those customers the hard questions: Is it really identity-based? Can you revoke access mid-session? Did it require network changes?

Involve your identity team. If your IAM or identity team looks at the solution and says "this doesn't integrate with our IdP" or "this doesn't use our existing policies," that's a red flag.

Read the architecture docs. Marketing materials lie. Architecture diagrams don't. Ask for detailed technical documentation and look for the telltale signs: VPN gateways, network tunnels, IP-based policies.

Trust your instincts. If something feels like a VPN with extra steps, it probably is.

The Bottom Line

Zero Trust is a powerful architecture. When implemented correctly, it dramatically reduces risk, improves visibility, and enables modern work patterns. But it's not magic, and it's not easy.

If a vendor is promising Zero Trust without identity integration, continuous monitoring, application-level segmentation, and thoughtful policy design, they're not selling Zero Trust. They're selling you a rebrand.

And in cybersecurity, the gap between what you think you have and what you actually have is where breaches happen.

At PulseHA, we believe in doing this right. Zero Trust technology, high-availability architecture, and a commitment to precision. Because when your business depends on secure access, "good enough" isn't good enough.

Don't settle for Zero Trust-washing. Demand the real thing.

Want to see what real Zero Trust looks like in action? Get in touch with the PulseHA team for a no-BS technical walkthrough.