Zero-trust - trust model

Zero-trust is a security model, not a product. The premise is simple: nothing is trustworthy by network position. It does not matter whether the request comes from inside the data center, from the CTO's laptop or from a pod in another account: every call is authenticated, authorized and logged before touching any resource.

The model stems from the realization that the classic perimeter no longer works. A VPN puts the user on the internal network, and the internal network no longer has a wall - VPCs connect, workloads run on ephemeral Kubernetes, partners have federation, and an attacker who gets in once strolls all the way to the payments bucket. Zero-trust responds by changing the unit of trust from the network to identity, and requires explicit verification at every boundary.

NIST SP 800-207 defines seven principles that appear in every serious zero-trust implementation. They are not exclusive, in practice they are combined, but they serve as a yardstick to tell whether the architecture under study is zero-trust or merely 'VPN with MFA'.

Zero-trust materializes on four technical fronts, almost always combined. The path usually starts on one front (user access, for example) and expands over time until it covers the entire service mesh.

The most common limit is confusing zero-trust with 'putting MFA on the VPN'. MFA is a layer; zero-trust is an architecture that presupposes MFA on every call, identity on every workload and policy per service. A team that calls anything 'zero-trust' because it turned on MFA ends up with a marketing project, not a security one.

The second limit is operational. Replacing VPN with BeyondCorp for a thousand employees is a months-long project with vendor lock-in and difficult rollback. The pragmatic version starts small (one sensitive application, or one cluster) and expands in waves, with versioned policy and testing before promotion.