How should security teams build a zero trust architecture that covers both internal traffic and user access from outside the network?

Designing Zero Trust for two different trust problems

The core design mistake is treating internal traffic and remote user access as the same control problem. They are related, but the enforcement logic is different. East west traffic needs path restriction and segmentation inside the environment, while external access needs strong session, device, and user verification before any connection is allowed.

That separation matters because a successful internal foothold should not automatically become broad lateral reach, and a valid remote login should not imply trust in the destination network. Zero Trust Architecture works best when policy follows the request, not the network location, and when the policy engine can apply the same intent across both paths.

For the architectural baseline, NIST SP 800-207 Zero Trust Architecture describes the model as an explicit policy decision and enforcement approach rather than a perimeter shortcut, and NIST SP 800-207 Zero Trust Architecture is the clearest reference for that design pattern. For workload-to-workload enforcement, pairing the model with SPIFFE workload identity specification helps teams make service trust explicit instead of inferred from IP ranges or subnet placement.

How the internal and external controls complement each other

Microsegmentation is the internal control layer. It constrains east west movement by limiting which systems, workloads, or services can talk to one another, ideally by identity or workload context rather than broad network segments. ZTNA is the external access layer. It brokers user access on demand, after checking the user, device posture, and contextual conditions before exposing only the specific application or service needed.

Used together, they close different gaps. Microsegmentation reduces the blast radius of a compromised host or workload inside the estate, while ZTNA reduces the chance that a remote user session becomes a general network foothold. The practical goal is consistency of policy intent, not identical mechanics. A user accessing an app from outside and a service calling another service inside should both be subject to explicit authorization, but the identity signals and enforcement points will differ.

For teams standardising the workload side, Ultimate Guide to NHIs is useful because it ties zero trust to the lifecycle and governance of service accounts, API keys, and workload identities. On the standards side, OWASP Non-Human Identity Top 10 is directly relevant when the “internal traffic” problem is really about controlling non-human access paths that can otherwise bypass segmentation assumptions.

External access can also be grounded in policy-driven identity controls through NIST SP 800-207 Zero Trust Architecture, which is especially useful when defining policy enforcement points, continuous verification, and application-specific access paths.

Operational design choices that keep the model from drifting

The hardest part is not choosing the tools, it is keeping trust policy current as the environment changes. New workloads, new services, and new integrations can quietly reopen broad paths if policy is still tied to static network assumptions. Automation is therefore part of the architecture, not an optional convenience.

What to verify: confirm that every privileged internal path is explicitly allowed, that ZTNA exposes only the intended application, and that policy updates are triggered by workload, identity, or environment change rather than manual review alone.

What practitioners underestimate: microsegmentation and ZTNA fail differently. If segmentation is too coarse, lateral movement remains possible. If ZTNA is too broad, remote access becomes a surrogate perimeter. The real test is whether a compromised account, host, or workload can move beyond the narrow scope it was granted.

Practitioner takeaway: Treat Zero Trust as two coordinated enforcement planes, one for east west movement and one for inbound user access, with automation keeping both aligned to current identity and workload reality.

Practitioner takeaway: The design is only strong when trust is continuously re-evaluated at the point of access, not inherited from the network the request happens to come from.

Related resources from NHI Mgmt Group

• How should security teams implement zero trust access across network and non-network resources without creating operational drift?
• How should security teams limit token reuse across internal services in a zero-trust architecture?
• How should security teams reduce unauthorized access when credentials, privileges, and internal network trust all fail at once?
• How should security teams choose between network-level access tools and application-layer zero trust controls?