Why the perimeter fails

Flat interiors, no clean edge, ephemeral workloads.

To commit to zero trust you have to understand precisely why the perimeter model breaks down in modern architectures — not as history, but because each failure mode maps to a control you will add.

The flat-interior problem

The castle-and-moat model puts strong controls at the edge and trusts everything inside. Its fatal flaw is the flat interior: once an attacker is in — a phished laptop, a vulnerable app, a compromised dependency — they move laterally with little resistance because internal traffic is trusted by default. Cloud and microservice architectures make this worse: there is no clean edge to defend, workloads are ephemeral and numerous, traffic is overwhelmingly east-west between services, and the "inside" spans multiple clouds and clusters. The perimeter still matters, but it can no longer be the primary security boundary.

# Perimeter model, after ONE foothold:
#
#   phished laptop / vulnerable app  (inside the moat)
#     → scans flat internal network         (nothing blocks east-west)
#       → reaches databases, other services  (internal = trusted)
#         → pivots across clusters/clouds     (shared "inside")
#
# Zero trust breaks this: default-deny east-west + identity authz at each hop.

From edge to everywhere

Zero trust does not discard the perimeter; it stops relying on it alone by pushing verification everywhere. Every service-to-service call is authenticated by identity and authorized by least-privilege policy, east-west traffic is default-deny, and outbound (egress) is controlled — so a foothold is boxed into the few flows it was explicitly granted. Each perimeter failure has a direct zero-trust answer: flat interior → default-deny network policy; trusted internal traffic → mTLS and identity authz; no clean edge → identity that works across clusters and clouds via federation. The rest of the course is the implementation of those answers.