The “Trust Me, Bro” Security Architecture Hiding Behind Your Zero Trust VPN Solution
April 30, 2025
Written by KJ Stillabower, Executive Advisor
Every CISO and CIO today knows they cannot rely exclusively on outdated perimeter-based defense strategies and need to get to Defense-in-Depth, if not all the way to Zero Trust. They will tell you, “The firewall-as-a-boundary mindset is outdated. We’ve moved to the cloud. We’ve got VPN. We’ve got MFA. We’re doing Zero Trust now.” But peel back the marketing and the acronyms, and you’ll often find the same old perimeter model, just with a few new logos stamped on top. Unfortunately, the lingo has evolved, but the operating model remains the same.
Somewhere in a leadership update, the phrase “Zero Trust” has been prominently featured on a roadmap. A project was approved to allocate resources to the execution of a project that will deploy “Zero Trust.” They’ve engaged different security vendors. They’re going to deploy an updated remote access solution; they are changing the enterprise identity store; they may even still be working on some level of multi-factor authentication (MFA) for enrollment.
If they can just execute on the project, the organization will be secure… right? Not necessarily.
Despite a growing chorus of vendors, frameworks, and leadership teams waving the Zero Trust banner, far too many organizations are still operating on the same foundational assumption that’s been quietly undermining enterprise security for decades: implicit trust. Trust in the user. Trust in the device. Trust in the network. Trust in the idea that once someone has made it past the perimeter or checked the right boxes, they are good to go wherever their commands will take them.
We like to call this the “Trust Me, Bro” Security Architecture. It doesn’t show up on your whiteboard or your SOC dashboard, but it’s lurking behind the scenes in the way access is granted, reviewed, and monitored. It’s in the unsegmented network zones, the stale user accounts, the over-scoped VPN access, and the tribal knowledge about “who usually needs what.” And perhaps most dangerously, it’s hiding behind the comforting but incomplete belief that deploying a VPN with a few Zero Trust labels slapped on top equals a modern, resilient security posture.
As an IT security industry, this may be one of the most dangerous assumptions prevalent across large, enterprise organizations. Zero Trust isn’t a widget or a service. It’s a mindset. A shift that treats all access as potentially hostile, verifies everything, and grants nothing by default. It’s the antithesis of “Trust Me, Bro.” And it demands a level of architectural discipline and organizational self-awareness that many teams haven’t yet reckoned with. Think of it this way: if one’s cloud has 0.0.0.0/0 any-any allow rules or has disabled host-based firewalls, that’s your green M&M in the Van Halen dressing room. It may seem innocuous absent the broader context. But it’s a clear signal that Zero Trust principles haven’t taken root, and more foundational issues are potentially present. They serve as a warning that there are deeper, more dangerous lapses in process hiding elsewhere in the system that could collectively result in disaster.
We need to dissect how traditional perimeter tools like VPNs can lull organizations into a false sense of defense-in-depth, why Zero Trust is often more wishful than real, and how insider threats thrive when implicit trust rules the network. Most importantly, we’ll look at principles to build toward real Zero Trust. Security that doesn’t rely on vibes, good intentions, or the mindset that “She works here, she must be cool.”
Modern Stack, Legacy Thinking: Security Theater with Better Acronyms
Vendors have done a great job of selling the modern enterprise stack. Cloud-native workloads. Enterprise identity providers with anti-replay challenges. ZTNA solutions with dynamic encryption tunnels for individual application services. Somewhere along the way, the organization was told this all added up to Zero Trust.
But look closer at how it is deployed, and much of it amounts to security theater with better acronyms and higher cost support subscription renewals. The tooling has modernized, but unfortunately the enterprise architecture and trust models are stuck in the past. The legacy perimeter didn’t go away; it just moved. In many organizations, the VPN has become the new boundary, the line between “outside” and “inside.” And once a user passes that line, implicit trust quietly resumes.
Large enterprises struggle to update their thinking and operating models due to institutional inertia. Like elsewhere in technology, we have re-invented the same thing with different words. Instead of removing the perimeter, we’ve just redrawn it and call it a VPN, a ZTNA broker, or some other tunnel or endpoint concentrator. Once someone has authenticated, access decisions are often blunt instruments: group membership, role inheritance, maybe an initial posture check. From that point forward, the assumption is: they’re good to go.
But what happens inside the VPN tunnel? In far too many cases, the answer is “everything.” Lateral movement is unmonitored. Internal segmentation is weak or nonexistent. Access is scoped broadly for convenience. Logging is partial if it exists at all. The enterprise has changed its clothes, but it’s still running the same old playbook.
If the VPN is granting access to the same flat networks, to the same legacy systems, with the same ungoverned entitlements, what has really changed? If the “Zero Trust” solution is just a new door into the old house, it’s comfort masquerading as modernization. This misplaced confidence is dangerous because it disguises fragility as strength. The presence of security tooling becomes a proxy for security maturity. But Zero Trust is not a product to deploy, it’s a mindset to operationalize. One that doesn’t end at the authentication point. One that doesn’t assume access is safe just because it came through a “secure” channel. One that questions every interaction, every connection, every permission, every time.
Modern tools are valuable. But when layered on top of an architecture still driven by implicit trust, they’re not enabling Zero Trust: they’re enabling denial.
Too Big to Trust Everyone
All this tooling supports the enterprise’s users, who, until AI improves, are still human. This presents a challenge to the common assumption in enterprise environments, particularly for organizations with tens or even hundreds of thousands of employees. The assumption is that people are basically good, and systems basically work. There is a general assumption that users wouldn’t try to harm the company. It is assumed that authenticated users can be trusted by default. All of these can break down at scale.
In many cases, this is true. Most people aren’t malicious. They’re trying to get their jobs done. But Zero Trust doesn’t hinge on the assumption of bad intent. It hinges on the inevitability of risk at scale. Because at a certain size, intent doesn’t matter. Statistically, something will go wrong. Credentials will be phished. Endpoints will be compromised. Someone will click the wrong link. Someone else will exfiltrate sensitive data through a sanctioned channel because “they didn’t know better.” At enterprise scale, you're not securing a team, you're securing a small city. And like any city, there will be accidents, bad actors, and internal issues that no one saw coming.
This is where traditional insider threat models break down. They tend to focus on motive and intent. They’re concerned with someone having malice, someone going rogue, or someone with a grudge. But more often, the biggest insider risk is not the person themselves. It’s the access they’ve been granted, the permissions they inherited, and the systems that assume they’re safe because they’re authenticated. At scale, users inherit the same reciprocal sense of safety, “if this wasn’t allowed, they would prevent me from doing it.”
Zero Trust reframes the issue. It doesn’t start by asking “Do we trust this person?” It asks, “What can this identity do, and should it still be allowed?” That subtle shift changes everything.
Something as basic as creating a user can undermine Zero Trust. User onboarding requests often include requests like “Please make sure they can do everything I can do” as an attempt to cut down on the friction of insufficient access. With poor entitlement management and documentation, this can lead to the new hire being able to access sensitive systems that the manager didn’t consider were also enabled by the request. Foundational documentation and granular requests are time consuming but fundamental to effective privilege control. Every access grant is a trust decision, and that trust should be earned, justified, and revisited regularly.
The real danger isn’t that users are bad. It’s that the environment has no meaningful checks once they’re in. A compromised device doesn’t announce itself. A user with elevated entitlements who changes roles quietly keeps those permissions. A script with an API key from five years ago keeps running long after its owner left the company. None of this requires an attacker to break in. They just have to walk the paths that have been left open. The bigger the organization, the more paths there are. At some point it’s no longer a risk of failure, it's a statistical guarantee. The only question is when it will happen, and how big the blast radius will be.
Real Zero Trust Demands Continuous Verification
All of this is why Zero Trust isn’t about paranoia. It’s about pragmatism. It’s about acknowledging that trust should never be a default setting. Not for users, not for devices, not for systems, and not just because they’ve been around for a while. It’s about building guardrails for good people in bad situations, and about containment for the rare but inevitable moments when intent does turn malicious.
This is where many Zero Trust implementations fail in practice. They stop at the front door, the firewall, the VPN, wherever defines the edge and then the user is free to roam through the network. But real Zero Trust doesn’t end at edge authentication. It begins there. Zero Trust asks, “What should you be able to do right now, on this device, in this context and how do we know it?”
Continuous verification means revalidating access throughout the session, not just at the moment of login. It means watching for drift in posture, changes in user behavior, signs of device compromise, or unexpected movement across systems. And it means revoking access as soon as something looks off, not hours or days later during an audit.
It also means being brutally honest about what you’re not tracking. Are access entitlements reviewed in real time? Are you monitoring lateral movement inside your environment? Do you know what sensitive systems your non-human accounts are touching today? If not, you’re still operating in a trust-by-default world, even if you’ve put a shiny ZTNA wrapper around it.
This is the core difference between a security product and a security posture. A Zero Trust product can help you get there, but only if the organization is willing to do the hard work:
Tightening access scopes
Implementing segmentation and least privilege
Documenting privilege requirements
Automating identity lifecycle management – both for users and services
Watching for anomalous activity in real time
Making verification a continuous process, not a one-time checkpoint
Zero Trust is not a switch you flip. It’s a system of constant vigilance and adjustment. It requires visibility, automation, and cultural alignment around the idea that no access is inherently safe. Because at the end of the day, Zero Trust isn’t about technology. It’s about discipline. And discipline, at scale, is the only real antidote to implicit trust.
Zero Trust is a Process, not a Widget or Service
Despite what the OEM is telling you, Zero Trust is not a widget you install or a checkbox you complete. It’s not a toggle in your identity provider. It’s not a SKU. And it’s certainly not something that gets delivered automatically when you sign a contract with a vendor. Zero Trust is an operational philosophy rooted in constant evaluation, ongoing verification, and organizational discipline. It requires not just tooling, but intentional design and operational follow-through. It’s more akin to digital transformation than upgrading the VPN.
There are organizations that can help you throughout this transformation. Vendors have an important role to play, but their products are only as effective as the strategy they support. A Zero Trust solution might help reduce blast radius or enable just-in-time access; but without clearly defined policies, segmented architectures, and identity lifecycle governance, the advanced tools become hammers or worse, shelfware. Too often, organizations expect a vendor-branded control plane to solve for deeply human and structural issues: over-provisioned access, stale entitlements, tribal knowledge, and architectural sprawl.
Real Zero Trust demands good friction. Not endless pop-ups or excessive MFA prompts, but thoughtful scrutiny applied to the right moments. It’s the process of continually asking, “Does this identity need this access right now?” and being prepared to take action when the answer is no. It means holding even trusted systems accountable, validating assumptions, and accepting that conditions will change over time.
This mindset is especially difficult in large enterprises, where the pressure to simplify, centralize, and accelerate is constant. But discipline at scale isn’t optional, it’s foundational. When deployed as an objective versus a philosophy, Zero Trust becomes a crash diet that is destined for failure. Motivation fades, decisions become informal, and inconsistencies creep in. Teams make allowances that become permanent habits. Exceptions pile up. And before long, a well-intended security architecture quietly drifts back to where you started with the added frustration and guilt of failure.
If your organization is beginning a Zero Trust journey or is realizing that the current Zero Trust posture isn’t as robust as previously assumed, the next step isn’t technology, it’s honesty. Take a clear-eyed look at how trust is granted today, and ask: where is it earned, and where is it assumed? Do you need help in refining these decisions? How can I remove the trust dependencies in my tool chain?
The decision of zero trust is a responsibility you carry. A posture you maintain. Zero Trust is not the presence of controls or tools, but it is the absence of assumptions. And the organizations that succeed with it are the ones willing to treat Zero Trust not as a destination, but as a living process that never stops being tested.