The vendor ecosystem around "zero trust" has successfully conflated an architectural principle with a product category, and the confusion is costing enterprises real money. In the red team engagements I ran across financial services before joining Stroom, the phrase "we've deployed zero trust" was a reliable early indicator that the engagement would find significant gaps — not because the tools purchased were bad, but because organisations treat tool deployment as the goal rather than the architectural outcome the tools are supposed to support. Zero trust is not a network segmentation appliance. It is not an identity proxy. It is not a CASB. It is a design philosophy, derived from the "never trust, always verify" principle articulated in the 2010 Forrester research and formalised in NIST SP 800-207, that applies to every network transaction regardless of origin.
The core of the zero trust model in NIST 800-207 is the policy decision point (PDP) and policy enforcement point (PEP) architecture. Every access request — whether from an authenticated user accessing a corporate application, a service account querying a database, or a microservice calling an API endpoint — passes through an enforcement layer that evaluates a policy decision based on the requester's identity, device posture, requested resource, context (time, location, behavioural baseline), and then grants or denies access at the minimum necessary scope. The architecture is continuous, not perimeter-bounded: the fact that a request originates from inside the corporate network is irrelevant to the access decision. This matters because the most damaging breaches in financial services and critical infrastructure over the past decade have involved attackers who achieved initial access through legitimate credentials — phishing, credential stuffing, supply chain compromise — and then operated undetected for weeks because east-west traffic within the network received no scrutiny after the perimeter crossing.
The implementation gap that red team assessments consistently surface is in machine-to-machine authentication. Human identity — employees, contractors, partners — has received the most investment attention because it is the most legible risk: MFA adoption, identity governance, privileged access management. The service account estate is typically an order of magnitude larger, less frequently audited, and often privileged at levels that would never be granted to a human user. In a 2022 red team exercise against a mid-size Belgian financial institution — not a named client, but representative of the sector pattern — we found service accounts with domain administrator privileges that had not had their passwords rotated in four years, were accessible via Kerberoastable SPNs, and whose access logs had not been reviewed because no one had configured alerting for their activity patterns. This is not a pathological case; it is the median state of service account governance in enterprises that have not explicitly prioritised it.
We should be explicit about what zero trust architecture does not solve. It does not prevent an attacker who has stolen valid credentials from the correct device from accessing the resources those credentials are authorised to reach. Continuous authentication and behavioural analytics can raise the detection probability, but a sophisticated actor who understands the target's normal behaviour patterns can operate within them. Zero trust reduces the blast radius of a credential compromise by enforcing least-privilege access at every decision point, making lateral movement harder and more detectable — but it does not eliminate the category of risk. Pairing zero trust enforcement with a detection engineering program that monitors for behavioural deviation within authorised sessions is the only architecture that addresses both the access control problem and the attacker-operating-within-legitimate-access problem.
For founders building in this space, the lesson from watching zero trust implementations succeed and fail is that the architectural outcomes that matter — continuous verification, least-privilege enforcement, device posture integration, microsegmentation — require organisational commitment to change how access is provisioned and revoked, not just a deployment of enforcement infrastructure. The products that support this best are those that make the operational change tractable: automated policy lifecycle management, adaptive policy responses to anomaly signals, and integration with the enterprise's existing identity governance workflows rather than requiring a parallel system. Building for the security engineer who has to operate this architecture daily is not the same as building for the CISO who has to justify the procurement.