Zero Trust, Minus the Marketing
What "zero trust" actually means under the vendor noise, and the three things that make it real in practice.
The most overloaded two words in enterprise security right now are "zero trust." I've watched VPN vendors rebrand their products as zero trust platforms, firewall companies slap the label on features that haven't changed since 2015, and startups use it to describe things that are simply fine security practices with a new name. When a term fits every product, it describes none of them.
So here's what zero trust actually means, and what implementing it looks like for a team that isn't running a federal agency or a Fortune 500 security operation.
Where the idea comes from
John Kindervag, then an analyst at Forrester, articulated the concept around 2010. The problem he was pointing at was real: corporate security was built around a perimeter. Inside the firewall, you were trusted. Outside, you were not. That model made sense when users sat in offices, applications ran on servers you owned, and the network edge was a meaningful boundary.
None of those things are still true. Users are everywhere. Applications live in AWS, Google Workspace, and dozens of SaaS tools. Contractors and partners access systems containing sensitive data. The perimeter isn't a perimeter anymore — it's a rough approximation that mostly exists on paper.
Once someone is inside that boundary — through a compromised VPN credential, a phished employee, a misconfigured cloud resource — they often find the interior surprisingly open. Lateral movement from one compromised account or workload to others is one of the most consistent patterns in real breaches.
Zero trust's answer: stop using network location as a proxy for trust. Every access request, regardless of where it comes from, should be verified on its own merits. NIST formalized this in SP 800-207, published in August 2020. The central tenet is easy to state even if it's operationally demanding: grant access based on verified identity, device health, and minimum necessary privilege — not based on which network the request is coming from.
The three things that actually make it real
Vendors pitch zero trust as a product you can buy and deploy. It isn't. It's a posture built from several practices working together.
Identity you actually verify. Every access request needs to be tied to a confirmed identity — not just a username and password, but a properly authenticated one. That means single sign-on so there's one authoritative directory, and MFA on every account that reaches anything sensitive. Multi-factor authentication is the most consistently effective control against credential attacks, and in any zero trust architecture it's the starting point, not an optional hardening measure.
Device health checks. Identity alone isn't sufficient. If the device making the request is unmanaged, unpatched, or compromised, approving the login is still a bad outcome. Device posture checks — is this machine enrolled in MDM, is the OS current, does it have disk encryption enabled — are what turn "the right person logged in" into "the right person logged in from a clean machine." ZTNA products like Cloudflare Access, Tailscale, and Zscaler sit at this layer, intercepting requests and enforcing those checks before granting access.
Least-privilege access to specific resources. Once identity and device are verified, access should go to the specific thing the user needs — not the whole internal network. Least privilege is the underlying principle: minimum access by default, with any elevation explicitly requested and logged. In practice, this means replacing "connect to the VPN and reach everything" with "authenticate and reach this application." Network microsegmentation and application-layer access controls implement this at the infrastructure and software levels respectively.
Those three — SSO with MFA, device health enforcement, segmented least-privilege access — are what zero trust looks like operationally.
What zero trust is not
Because the term has been applied so broadly, it helps to clear some things out.
It's not a product. Buying a ZTNA platform doesn't mean you've implemented zero trust any more than buying a gym membership makes you fit. The platform is a tool. It has to be configured correctly, integrated with your identity provider, and enforced consistently. The operational work is the hard part, and no vendor does it for you.
It's not binary. No organization has achieved complete zero trust — it's a direction, not a state you arrive at. Most security teams are somewhere on a spectrum between fully perimeter-based (everything inside the network is trusted) and tightly verified per-request access. Movement along that spectrum has real security value even when you're nowhere near the far end.
It's not just for large organizations. The sales motion around zero trust products skews enterprise, which makes the whole concept feel like a problem for organizations with dedicated security teams and seven-figure budgets. The underlying controls apply at any size. A 20-person company can enforce MFA across the board, move off a shared VPN, and segment their cloud environment in a focused week of work.
It doesn't mean trusting nothing. "Never trust, always verify" is a memorable phrase but slightly misleading. Zero trust doesn't assume malice everywhere. It means access is earned through explicit verification rather than assumed based on network position. Once you've confirmed identity, device health, and appropriate authorization, you grant access — the trust is just narrower, more specific, and shorter-lived than what a traditional perimeter provides.
What a practical starting point looks like
If you're not a federal agency with a mandate, the entry points are tractable.
Start with identity consolidation and MFA. Get everyone onto a single SSO provider and enforce MFA with no exceptions for accounts that reach production systems, source code, or customer data. This removes a significant portion of credential-based attack surface and is the prerequisite for nearly everything else.
Then look at your remote access story. If users are on a traditional VPN that drops them onto the internal network once connected, that's a reasonable next place to focus. Identity-aware proxies route users to specific applications rather than the broader network, which limits the damage if a credential is compromised. Tailscale and Cloudflare Access both have free tiers that work for small teams.
After that, audit your IAM. Who has access to what, and does any of it exceed what the person or service actually needs for their work? Security-101 fundamentals apply directly here — overprivileged accounts and service credentials are consistently where attackers establish their foothold before moving laterally.
How this shows up in audits and frameworks
Auditors don't typically ask "do you have zero trust?" They ask about specific controls: MFA coverage, access provisioning and review, network segmentation, logging and monitoring. Zero trust is the conceptual frame; those controls are the evidence they're looking for.
The NIST CSF 2.0 integrates zero trust thinking throughout its Protect and Detect functions. US federal agencies were directed to meet specific zero trust architecture goals through OMB Memorandum M-22-09, issued in 2022. ISO 27001's access control and network security controls and SOC 2's common criteria both require practices that are, operationally, zero trust implementation — they just don't use the term.
The practical takeaway: if you're working toward SOC 2, ISO 27001, or another framework, you're almost certainly already building these controls. Zero trust is mostly a way of thinking about why you're building them and how they should fit together.
The useful thing the zero trust frame gives you is a reliable default answer to "should X have access to Y?" That answer starts as no, and becomes yes only when you can point to verified identity, a clean device, and a legitimate need. Apply that consistently and you end up with better security than most of what's being marketed under the label.