The assumption it replaces
Older network security models drew a hard line between 'inside' and 'outside': traffic that made it past the firewall was largely trusted, and most of the serious authorization happened at the boundary. That model matched a world of on-premises networks and managed devices. It matches poorly a world of remote workers, cloud services, and automated agents that may run anywhere and call any number of other services.
Zero-trust architecture starts from the opposite assumption: no request is trusted because of where it came from. Every request is verified on its own merits, every time, regardless of network location.
What has to be true for this to work
In practice, zero trust rests on a small number of supporting capabilities. Every principal — human, service, or agent — needs a verifiable identity, not just network reachability. Every request needs to carry enough context (identity, intended action, target) for a policy decision to be made about it specifically. And enforcement needs to happen close to the resource being protected, not only at a perimeter that a compromised internal system can already sit behind.
None of these capabilities is exotic on its own. What makes zero trust a genuine architectural shift is applying them consistently, to internal traffic and automated processes as rigorously as to external users — rather than treating them as extra hardening applied only at the edges people think about first.
A frequent implementation gap
The most common gap between a stated zero-trust policy and its actual implementation is service-to-service traffic. Organizations that verify every human login carefully often let internal services call each other with long-lived shared credentials or implicit network trust, because it is expedient. That gap is exactly where a zero-trust model is supposed to close the door.