Zero trust is the most over-marketed idea in security, and one of the least actually implemented. Buying a product with "zero trust" on the box does not give you zero trust any more than buying running shoes makes you a runner. The principle is simple; the follow-through is where organisations stall.
What zero trust actually means
Strip away the vendor language and zero trust is one sentence: never trust a request because of where it came from. Being inside the corporate network, on a company laptop, or behind the VPN grants nothing. Every request authenticates, every request is authorised against policy, and every request is logged.
Where implementations stall
The technology is rarely the blocker. The hard part is inventory and identity.
- You cannot protect resources you have not enumerated, and most companies cannot list every service that holds their data.
- Machine-to-machine identity is usually a mess of long-lived keys that nobody wants to rotate.
- Legacy applications assume a trusted network and resist being put behind a policy enforcement point.
Zero trust is a migration, not a purchase. The teams that succeed pick one high-value application and prove the whole pattern end to end before touching the next.
A pragmatic starting point
We tell clients to begin with identity-aware access to a single sensitive application: put it behind a proxy that checks user identity and device posture on every request, remove its network-level exceptions, and watch the logs for a month. That one migration teaches the organisation more about its own dependencies than any architecture diagram, and it turns zero trust from a slogan into a repeatable playbook.