Zero Trust Architecture Is Not a Product You Buy
The security vendor community has done something impressive with the Zero Trust concept: it has taken a principled architectural framework that requires organizational discipline, policy definition, and sustained implementation effort, and repackaged it as a product category that can be purchased and deployed. The repackaging is commercially effective. It is also misleading in a way that causes organizations to believe they have implemented Zero Trust when they have purchased a tool.
Zero Trust is an architectural philosophy, not a product. Its core principle — that no user, device, or network location should be implicitly trusted, and that every access request should be verified and authorized based on identity, context, and the least privilege required for the requested action — cannot be satisfied by deploying a single vendor’s platform. It requires rethinking the entire access control model of the organization’s infrastructure, applications, and data.
What Zero Trust Actually Requires
The foundational requirement of Zero Trust is a robust identity infrastructure. Every user and every device must have a verifiable identity. The identity system must be the authoritative source for access decisions. Multi-factor authentication must be enforced universally, not selectively. Conditional access policies must evaluate device health, user behavior, location, and other contextual signals at the time of each access request, not just at authentication time.
This is a governance challenge as much as a technical one. An organization that has Active Directory groups that have not been reviewed in three years, service accounts with broad permissions that were created for a project that concluded in 2019, and applications that authenticate with shared credentials stored in a configuration file is not in a position to implement Zero Trust by deploying a new network security product. The identity hygiene work is the prerequisite, and it is slow, unglamorous, and politically complicated because it requires revoking access that people have become accustomed to having.
The Network Perimeter Problem
Zero Trust emerged as a response to the obsolescence of the network perimeter security model. The corporate network perimeter — a trusted internal network separated from the untrusted internet by firewalls — was never a strong security model. It was a workable model when applications ran on-premises, when employees worked from offices, and when the boundary between inside and outside was relatively clear.
Remote work, cloud applications, and mobile devices eliminated all three of those conditions simultaneously. The VPN that extends the trusted perimeter to remote employees is not a substitute for the perimeter’s original function — it moves the trust boundary without enforcing access controls within the extended perimeter. An employee whose laptop is compromised while on VPN has a compromised device with full network access, which is the attack scenario that the perimeter model was supposed to prevent.
Zero Trust’s response is to eliminate the trusted internal network concept entirely. If there is no trusted network, there is no value in compromising a device to gain trusted network access. Access decisions are made at the application level based on verified identity and device posture, not at the network level based on whether the request came from an IP address that is considered internal.
The Implementation Reality
Implementing Zero Trust in a large organization with decades of accumulated infrastructure is a multi-year project. The applications that authenticate based on network location rather than user identity must be modified or replaced. The network segmentation that previously provided implicit access control must be replaced with explicit application-level authorization. The monitoring infrastructure must evolve to detect anomalous access patterns that the old model would never have seen because they would have been blocked at the network boundary.
Organizations that treat Zero Trust as a product purchase rather than an architectural transformation make a specific kind of progress: they improve one layer of the security stack while leaving the underlying trust model unchanged. A cloud-delivered security service that provides Zero Trust Network Access for remote employees is a genuine improvement over split-tunnel VPN. It does not implement Zero Trust for the on-premises applications that still authenticate by IP address, the service accounts that still use shared credentials, or the network shares that grant access to anyone on the internal network segment.
The gap between marketing and reality in Zero Trust is navigable. The navigation requires starting with the identity work, not with the product purchase, and treating the architectural transformation as an ongoing program rather than a project with a completion date.