Zero Trust architecture becomes useful only when it stops being a slogan and turns into a new trust model inside the system.
The chapter shows how explicit identity checks, policy enforcement, segmentation, and phased migration move security away from blind trust in the network and into verifiable architecture choices.
For design reviews, it frames Zero Trust as a sequence of steps with user-experience friction, latency overhead, and operational cost rather than as a future-state slide.
Practical value of this chapter
Design in practice
Design access around identity, request context, policy decision and enforcement points, not around network trust.
Decision quality
Validate where the trust boundary sits, how access decisions are made, and how quickly rights can be revoked after compromise.
Interview articulation
Frame the answer around the route: subject, resource, context, policy, enforcement, and audit trail.
Trade-off framing
Make the cost of segmentation, mutual TLS, short-lived credentials, check latency, and operating complexity explicit.
NIST
SP 800-207
The baseline NIST reference for Zero Trust Architecture.
The perimeter model rests on one assumption: if you are inside the network, you can be trusted. Break that assumption once, and an attacker moves through the system freely. Zero Trust removes the assumption: security is built not around inside-versus-outside, but around identity, request context, and continuous access verification.
Zero Trust Architecture assumes that network location alone does not prove trust. Every request is evaluated again: who is calling, which resource they want, what context surrounds the request, and where the policy is enforced — and any one of those answers can deny access.
Zero Trust principles
Never trust by default
Trust is not inherited from the previous request. Every time it is checked again: subject, context, resource, action, and the authorization policy that applies.
Least privilege
Access is granted for a specific task and a limited time. The wider and longer-lived the grant, the more an attacker gains from a single stolen credential — hence the lean on least privilege.
Assume breach
The question is not whether an attacker gets in, but what they can do once inside. Hence segmentation, observability, rapid revocation, and blast-radius control.
Base
Identification -> AuthN -> AuthZ
Identity and authorization models are the foundation — without them, phased Zero Trust adoption falls apart.
Reference architecture
Identity
- One model for users, services, devices, and workload identity.
- Identity provider, account lifecycle, MFA, and passkeys.
- Short-lived credentials instead of long-lived secrets.
Access policies
- Policy decision point: RBAC/ABAC/ReBAC or policy as code.
- The decision considers subject, action, resource, and request context.
- Deny by default as the baseline for new resources.
Policy enforcement
- Policy enforcement points in API gateways, service mesh, and applications.
- mTLS and service identity for east-west traffic.
- Audit trail for access decisions.
Telemetry and response
- Continuous verification through logs, metrics, and security signals.
- Risk-based access and dynamic restrictions.
- Fast incident response and automated access revocation.
Context signals for access decisions
Identity assurance
Question: Who is requesting access, and how strong is the proof?
Implementation: MFA, passkeys, phishing-resistant login, and device-bound credentials.
Device posture
Question: Does the device meet baseline security requirements?
Implementation: Device management state, patch level, disk encryption, and compromise indicators.
Workload identity
Question: How does a service prove itself when calling another service?
Implementation: Workload certificates, SPIFFE/SPIRE, and short-lived credentials.
Data sensitivity
Question: How critical is the resource, and should access be temporary?
Implementation: Data classification, purpose binding, and read-only defaults for risky paths.
Behavioral context
Question: Is geography, time, device, or request behavior unusual?
Implementation: Risk scoring, adaptive authentication, step-up checks, and temporary action limits.
Policy enforcement matrix
| Surface | Policy enforcement point | Checks | Action on deny |
|---|---|---|---|
| External API (north-south) | API gateway + WAF | AuthN/AuthZ, token claims, schema validation, rate limits. | Block the request, log the policy decision, and send a signal to the SOC. |
| Service-to-service (east-west) | Service mesh | mTLS, service identity, service policy, namespace segmentation. | Terminate the connection and log the decision with the trace ID. |
| Data plane | DB proxy / data access layer | ABAC/ReBAC, row and column rules, time-bounded credentials. | Reject the request and trigger an access review for the risky scenario. |
| Administrative operations | Privileged access gateway | JIT access, approval flow, session recording. | Do not issue the temporary elevation token; notify service owners. |
| CI/CD and deployment | Policy as code + admission control | Signed artifacts, workload identity, environment policy. | Stop the deployment and open a security ticket automatically. |
Operational metrics
Strong-authentication coverage for privileged users
Goal: 100%
Without strong authentication, Zero Trust quickly becomes a paper exercise.
mTLS coverage for east-west traffic
Goal: >= 95%
Shows whether inter-service calls are protected inside the system, not only at the external edge.
Share of administrative operations through JIT access
Goal: >= 90%
Reduces exposure from permanent privileged access and lateral movement.
Mean revocation time for a compromised identity
Goal: < 15 minutes
Faster revocation shrinks the compromise window and blast radius.
Policy-decision logging coverage
Goal: 100%
Without decision logs, investigation and compliance evidence become unreliable.
Implementation plan
1. Inventory
Map identities, services, secrets, critical paths, and the trust assumptions the current architecture makes.
2. Strong authentication baseline
Enable MFA and passkeys for users, workload identity for services, and remove shared credentials so a compromised secret does not belong to everyone at once.
3. Policy centralization
Move access rules into a shared policy layer and enable deny by default for new resources.
4. Segmentation and enforcement
Separate the contours — production from non-production, data tiers, administrative paths, and key traffic enforcement points — so compromising one segment does not open the door to its neighbors.
5. Continuous verification
Monitor access anomalies, run regular access reviews, and rotate credentials automatically.
Typical antipatterns
- Treating Zero Trust as a product instead of an architectural approach and operating model.
- Replacing the VPN while leaving identity and authorization models unchanged — newer at the edge, same default trust inside.
- Allowing everything inside the cluster and still calling it Zero Trust.
- Skipping revocation and deprovisioning processes even when authentication is strong.
- Keeping permanent administrative access without JIT access, just-enough administration, and explicit approvals.
Quick practical check: if compromising one service gives an attacker “almost everything,” Zero Trust is only nominally implemented.
References
Related chapters
- Identification, Authentication and Authorization (AuthN/AuthZ) - The foundation of Zero Trust: reliable subject identity and a verifiable access model.
- Access Control Models: ACL, RBAC, ABAC, ReBAC - Shows which authorization models can power a policy decision point.
- Secrets Management Patterns - Complements Zero Trust with short-lived credentials, rotation, and secret-control discipline.
- Service Mesh Architecture - Shows practical mTLS, service identity, and policy enforcement for east-west traffic.
- API Security Patterns - Carries Zero Trust out to the external API edge: token validation and abuse protection where requests arrive from outside.