"Zero Trust" Isn't a Product, It's a Mood
A plain-English explainer for a term every vendor has ruined
Type "zero trust" into any security vendor's homepage and you'll get a firewall, a VPN replacement, an identity platform, a network segmentation tool, and at least one company that seems to think it's a kind of cloud storage. Everyone sells zero trust. Nobody agrees on what it is. At some point the phrase stopped meaning anything, which is a shame, because the actual idea underneath it is one of the more useful things to happen to security in the last decade.
So let's back up and talk about what it actually means — no product pitch, no logo, just the concept.
The "castle and moat" problem
Traditional network security worked like a castle. Build a strong wall (the firewall), guard the gate (the login), and once someone's inside, trust them to wander around. Employees on the corporate network could generally reach the file server, the database, the internal tools — because they were inside, and inside meant trusted.
This worked reasonably well when "inside" was a physical office with a physical network. It stopped working the moment that stopped being true — remote work, cloud apps, personal devices, contractors logging in from coffee shops. The moat drained out. The wall doesn't mean much when half your castle's occupants were never inside it to begin with, and an attacker who breaches any single point can move sideways through the whole property because nothing past the gate was ever actually checked.
What NIST actually says
Zero Trust isn't a product category — it's an architectural philosophy, formally defined by NIST in Special Publication 800-207. The core idea: stop defending a static network perimeter and start defending the actual users, devices, and resources instead, because location on a network — physical or otherwise — was never proof that something deserved to be trusted.
The often-quoted tagline is "never trust, always verify." Every access request has to be authenticated, authorized, and continuously validated, whether it's coming from inside the network or from a laptop three time zones away. There's no VIP list. Being on the corporate Wi-Fi buys you nothing.
NIST's framework describes this less as a single tool and more as a set of tenets: verify explicitly, grant only the minimum access necessary, and — this is the part almost every vendor conveniently skips — don't let a login at 9:00 AM quietly grant standing access to something else at 2:00 PM without ever checking again. Access decisions are supposed to come from policy that keeps evaluating identity, device health, behavior, and context for as long as the session lasts, not a static list that gets checked once and forgotten.
That word — continuously — is the whole point, and it's the part that gets lost every time "zero trust" gets slapped on a login screen with an MFA prompt and called a day's work.
Why the term became a punchline
Here's the uncomfortable part: a huge share of what gets marketed as "zero trust" is really just "we added a firewall rule" or "we made you log in twice." Genuine zero trust requires continuous verification — checking identity, device health, and context on an ongoing basis, not once at 9am and then never again until the token expires eight hours later.
Most identity tools weren't built for that. They were built for the castle-and-moat era, just with a fancier gate. A single login event, however well-guarded, is still a single moment in time. Everything after it runs on inherited trust — which is precisely the gap that session hijacking and stolen-but-valid credentials live in, and precisely the thing "zero trust" was supposed to eliminate in the first place.
What "never trust, always verify" actually looks like in practice
If you strip away the marketing, real zero trust means access isn't a one-time decision — it's a constantly re-asked question. Is this still the right person? Is this still the right device? Are the conditions that justified access ten minutes ago still true right now?
That's a genuinely hard problem for most identity infrastructure, because most of it was designed to answer "who are you?" once, cleanly, at login — not to keep asking throughout the session without becoming exhausting for the person on the other end. It's also exactly the design principle NearAuth.ai builds around: presence, not a one-time password, confirmed continuously through the session rather than assumed for the next eight hours because someone typed a code correctly once.
"Zero trust" doesn't need to be a mood or a marketing slogan. It's a genuinely useful standard to hold identity tools to — the question worth asking of any vendor claiming to sell it isn't "do you have MFA," but "do you ever stop trusting me, and start checking again?"
chris@nearauth.ai