Let's Be Honest About What You Actually Deployed
I've sat through more "Zero Trust transformation" presentations in the last three years than I care to admit. And here's the pattern I keep seeing: an org rips out their legacy Cisco AnyConnect deployment, drops in Zscaler Private Access or Palo Alto Prisma Access, slaps on Okta for SSO, and then declares victory. "We're Zero Trust now." Slides get made. The CISO presents to the board. Everyone claps.
You're not Zero Trust. You built a shinier VPN with an identity provider in front of it.
And look, I'm not trying to be a jerk about it. The pressure to "go Zero Trust" has been relentless since the 2021 executive order, and vendors have been more than happy to sell you a product that checks a compliance box. But if your implementation starts and ends with "we replaced our VPN concentrator with a cloud-based access broker," you've fundamentally missed the point. You've changed the plumbing while keeping the same architecture — implicit trust zones, flat-ish networks, and access decisions made once at the front door.
What NIST Actually Said (That Nobody Bothered to Read)
NIST SP 800-207 is not a long document. It's 50-something pages. And yet the number of security architects I've met who haven't actually read it is genuinely alarming. They've read the vendor whitepapers about it. They've seen the Forrester graphics. But the source material? Nah.
So here's what 800-207 actually defines. Zero Trust is not a product. It's not even a single architecture. It's a set of principles centered on one idea: never grant implicit trust based on network location, asset ownership, or physical position. Every access request must be evaluated dynamically based on identity, device health, behavioral context, the sensitivity of the resource, and the current threat environment. Every. Single. Time.
The document lays out seven tenets. The ones that matter most for this conversation:
- All communication is secured regardless of network location — your internal network is treated as hostile.
- Access is granted on a per-session basis and must be re-evaluated continuously.
- Access policies are dynamic and consider multiple data sources: identity, device state, behavioral patterns, threat intelligence.
Read that second one again. Per-session. Continuously. Not "authenticate once and here's your eight-hour token." Not "you passed MFA so here's access to everything your role allows." Per session. With continuous evaluation. That's the bar. And most of you aren't even close.
The Identity-Only Trap
Here's where it usually falls apart. Most organizations start their Zero Trust journey with identity — and that's correct. Identity is the new perimeter. Setting up Azure AD Conditional Access policies, rolling out Okta with adaptive MFA, integrating device compliance checks from Intune. That's all good foundational work. Genuinely.
But then they stop.
I worked with a mid-size financial services firm last year that had spent eighteen months on their "Zero Trust initiative." They'd done real work: phishing-resistant MFA everywhere, conditional access policies that checked device compliance and user risk scores, just-in-time privileged access through Azure PIM. Solid identity posture. And they were proud of it — rightfully so.
Then I asked about their east-west traffic. Blank stares. Their application tier could talk to their database tier on any port. Their dev environment shared a flat /16 with production workloads. A compromised application server could freely enumerate and reach every other server in the data center. But hey, the front door had three locks on it.
This is what I call the "bouncer model" of Zero Trust. You've got a very thorough bouncer checking IDs at the entrance. But once you're inside the club, you can go anywhere — the VIP section, behind the bar, into the back office. That's not zero trust. That's perimeter security with better authentication. And perimeter security is exactly what Zero Trust was supposed to replace.
Microsegmentation: Where the Real Pain Lives
Nobody wants to talk about microsegmentation honestly because it's hard. Not conceptually hard — the concept is straightforward. Every workload gets its own security boundary, communication between workloads is explicitly authorized, everything else is denied. Simple on a whiteboard. Absolutely brutal in practice.
I've watched organizations attempt microsegmentation with Illumio and Guardicore (now Akamai Guardicore Segmentation), and the ones who succeed share a common trait: they spent months — sometimes a full year — in observation mode before enforcing a single policy. They mapped application dependencies exhaustively. They discovered shadow IT and undocumented integrations that nobody knew existed. They found that one legacy batch job from 2014 that talks to seven different services over non-standard ports and would absolutely break if you segmented it.
The ones who failed? They bought the tool, deployed agents everywhere, and started writing enforcement policies in week three. You can guess how that went. Production outages. Emergency rollbacks. The security team losing credibility with engineering. And then the tool gets blamed, shelved, and "microsegmentation" becomes a dirty word internally for the next three years.
But here's what kills me: microsegmentation is one of the most impactful things you can do. It's the difference between a compromised web server being an incident and a compromised web server being a breach. When SolarWinds happened, the organizations that had meaningful network segmentation — not just VLANs with ACLs, but actual workload-level segmentation — contained the blast radius dramatically faster. That's not theoretical. That's operational reality.
Google Did It Right. You're Not Google. But You Can Learn.
BeyondCorp gets cited in every Zero Trust conversation, and it should. Google started building it in 2011 — before "Zero Trust" was even a marketing term. And the key insight wasn't technological, it was philosophical: the network you're on tells us nothing about whether we should trust you.
What made BeyondCorp work wasn't any single product. It was the integration of multiple signals into every access decision. Device certificate plus device inventory database plus user authentication plus user risk score plus resource sensitivity level, all evaluated by an access proxy for every request. Not at login. At every request.
And that access proxy — the thing that sits between users and resources, evaluating context in real-time — is what most vendors are selling you as their "Zero Trust solution." Zscaler, Cloudflare Access, Palo Alto Prisma Access, they're all essentially selling you a cloud-hosted access proxy with varying degrees of sophistication in the policy engine behind it.
That's one component. An important one, sure. But Google didn't build BeyondCorp by buying one product. They rebuilt how they think about access from the ground up. They instrumented their entire device fleet. They built a trust inference pipeline that continuously scores devices. They redesigned applications to work without network-level trust.
So when a vendor tells you their ZTNA product "delivers Zero Trust," ask them which of the five pillars it covers. If the answer is "identity and network access," congratulations — you've addressed maybe 40% of the architecture. What about workload security? Data classification and protection? Device trust that goes beyond "is MDM enrolled"?
The Five Pillars and Your Uncomfortable Audit
Let's do a quick gut check. The CISA Zero Trust Maturity Model defines five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. For each one, honestly assess where you are.
Identity. This is where most orgs are furthest along. If you've got conditional access policies, risk-based authentication, and privileged access management, you're in reasonable shape. But are you doing continuous session evaluation? Are you revoking access mid-session when a user's risk score changes? Most aren't. They evaluate at authentication time and then trust the session for its lifetime. That's a gap.
Devices. You check compliance at access time — great. But what's your device trust posture actually evaluating? Intune compliance (is the OS patched, is the firewall on) is table stakes. Are you checking for EDR agent health? Are you evaluating device risk signals from CrowdStrike or Defender in real-time and feeding that into access decisions? Do you have a hardware root of trust, or can someone enroll a VM and pass all your compliance checks? That last one should keep you up at night.
Networks. You replaced your VPN. Cool. But is your internal network segmented at the workload level? Can your HR application talk directly to your engineering CI/CD pipeline? If you did a nmap scan from a compromised workstation, how many services would respond? If that number makes you uncomfortable, your network pillar is failing.
Applications and Workloads. Are your applications making their own authorization decisions based on verified identity tokens, or are they trusting "if you can reach me on the network, you're authorized"? Are your containers and serverless functions running with least privilege? Is your CI/CD pipeline secured, or could a compromised build system push malicious code to production? Most orgs haven't even started thinking about this pillar.
Data. The thing you're actually trying to protect. Are you classifying data? Are access controls applied at the data layer, not just the application layer? Can a database admin exfiltrate your entire customer dataset? Do you have DLP that actually works, or did you turn it off after the first week because of false positives? Yeah.
Stop Buying Zero Trust. Start Building It.
I had a conversation with a CISO last quarter that perfectly captured the problem. He told me, "We evaluated three Zero Trust vendors and selected one." I asked him what his Zero Trust strategy was. Long pause. "...We selected a vendor."
That's not a strategy. That's a purchase order.
A real Zero Trust strategy starts with understanding your data flows. Where does sensitive data live? Who accesses it? Through what applications? On what devices? Over what network paths? You can't protect what you can't see, and you definitely can't apply least-privilege access to resources you haven't inventoried.
Then you make architectural decisions. Do you need a ZTNA solution to replace remote access? Probably. Do you need microsegmentation? If you have any east-west traffic worth protecting — and you do — yes. Do you need to rearchitect applications to validate identity tokens at each service boundary? Ideally, yes, and you should be pushing for this on every new application. Do you need data classification and data-layer access controls? Absolutely, and this is the one everyone avoids because it's politically and technically exhausting.
And here's the uncomfortable truth: this takes years. Not months. Years. Google started BeyondCorp in 2011 and was still iterating on it in 2017. If a vendor tells you they can get you to Zero Trust in a quarter, they're selling you a product, not an architecture. If a consulting firm hands you a "Zero Trust roadmap" that's 12 months long, they either scoped it to one pillar or they're lying.
The organizations doing this well treat Zero Trust as an operating principle, not a project with an end date. They're making incremental progress across all five pillars simultaneously, prioritized by risk. They're instrumenting everything so they can feed richer signals into their policy decision points. They're accepting that this is a multi-year transformation of how they think about trust in their environment.
And they're definitely not calling it done because they bought Zscaler.
So What Should You Actually Do Monday Morning?
Map your east-west traffic. Seriously. Deploy Illumio or Guardicore in observation mode, or even just turn on VPC Flow Logs and actually look at them. I guarantee you'll find communication paths that nobody authorized and nobody documented. That's your real attack surface, and right now you're completely blind to it.
Audit your conditional access policies. Are they evaluating device trust signals beyond basic compliance? Are sessions being re-evaluated when risk signals change, or do they ride out their token lifetime? Push for continuous access evaluation — Microsoft's CAE protocol is a start if you're in the Azure ecosystem.
Pick one application — ideally an internal one with moderate sensitivity — and implement true per-request authorization. Not network-based access. Not "you authenticated to the proxy so you can reach this app." Actual identity-aware authorization at the application layer using OAuth tokens or SPIFFE identities. Feel how painful it is. Then figure out how to make it less painful for the next one.
And stop letting vendors define your architecture. Read SP 800-207 yourself — the actual document, not the infographic. Read the CISA Zero Trust Maturity Model. Understand where you are honestly, not where your last vendor assessment said you are. Then build a roadmap that addresses your highest-risk gaps first, regardless of which product category they fall into.
Zero Trust isn't a product you buy. It's a way of thinking about access that assumes breach, verifies continuously, and limits blast radius at every layer. If your implementation doesn't do all three of those things, you don't have Zero Trust. You have a VPN with extra steps and a nicer dashboard.