Every security vendor now sells a "zero trust solution." Buy the product, flip it on, tick the box. That framing is convenient for sales cycles and almost useless for actually reducing risk — because it treats a set of ongoing organizational habits as if they were a single feature you could enable in a settings menu.
Zero trust was never a product category. It's a working assumption: nothing inside your network gets trusted by default just because it's inside your network. That assumption has to be re-earned constantly, by people and processes, not switched on once by a piece of software and left alone.
Where the product framing breaks down
A tool can enforce identity checks, segment a network, or flag anomalous access. What it can't do is decide what "least privilege" means for your finance team's quarterly close process, or notice that an engineer still has admin access from a project that ended eight months ago. Those are habits — reviewing access regularly, questioning default permissions, treating every request as something to verify rather than assume — not settings, and no vendor's console ships with your organization's actual judgment calls pre-configured.
What the habit actually looks like
- Access reviews on a calendar, not a trigger. Waiting for an audit to check who has access to what means you're always finding problems after they've been sitting there for months, sometimes years — the review only happens when something external forces it, rather than as routine maintenance.
- Verifying explicitly, even internally. "They're on the VPN" is not the same as "they should have access to this system." Zero trust's core insight is precisely that network location was never a meaningful proxy for whether access is actually appropriate.
- Assuming breach, not just preventing it. The useful question isn't only "how do we stop this," it's "if this account is compromised right now, how much damage can it actually do?" An organization that's only ever asked the first question tends to discover the answer to the second one during an actual incident, which is the worst possible time to learn it.
- Treating access removal as routine, not exceptional. Offboarding — from a role, a project, or the company — should be as practiced and unremarkable as onboarding. Most organizations have a polished onboarding checklist and no equivalent discipline for removing access when it's no longer needed.
Why this is a training problem, not just a tooling one
We get called in most often after the tooling is already in place — a client has bought the platform, configured the policies, and adoption still hasn't happened, because the people operating it were never trained on the judgment calls it requires. A zero trust policy engine is only as good as the person deciding what "least privilege" means for a specific role, and that decision genuinely does depend on understanding the role, not just the software.
That's a different skill than reading a vendor's admin console documentation. It's closer to a security mindset than a software feature, and it has to be built deliberately across a team, not assumed to arrive with a new license.
The organizational tell that it's not working
If access reviews only happen right before an audit deadline, if nobody can quickly answer "what could this specific account actually do if compromised today," or if offboarding an employee's access takes noticeably longer than onboarding it did — those are the practical signs that the product got bought and the habit never got built. None of them show up as a technical alert. They show up as a slow accumulation of exactly the risk zero trust was supposed to close off.
Buying the product is the easy part. The habit is what actually reduces risk — and habits don't come installed. They get built, deliberately, by people who were shown what the judgment calls actually look like in practice, not just handed a login to a new console.
Where to actually start
For a team that's bought the tooling but hasn't yet built the habit, the lowest-friction starting point is usually the calendar item, not a policy rewrite: pick a fixed date, quarterly, where someone specifically reviews who has access to what in one genuinely sensitive system, and treats "why does this person still have this" as the default question rather than the exception. That single recurring habit, done consistently, tends to surface most of the stale-access problems a much larger security overhaul would otherwise be commissioned to find.