Security teams should pair microsegmentation with zero trust network access so internal east west movement and external access are governed separately but consistently. Microsegmentation limits lateral movement inside the environment, while ZTNA verifies users, devices, and conditions before granting access. The strongest designs also automate policy updates so new workloads and changing environments do not create stale trust assumptions.
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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | Directly supports least-privilege and access enforcement across internal and external paths. |
| Recommendation — Apply PR.AC to enforce explicit access decisions for both user sessions and east west traffic. | ||
| NIST Zero Trust (SP 800-207) | SC-4 — Information Flow Enforcement | Matches microsegmentation and policy-based traffic restriction inside the environment. |
| IA-2 — Device and User Authentication | Supports ZTNA verification of users and devices before external access is granted. | |
| Recommendation — Use SC-4 to constrain internal flows to approved application and workload relationships. Require strong authentication and device verification before brokering remote access. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Relevant because zero trust for internal traffic depends on controlling workload credentials and secrets. |
| NHI-03 — Overprivileged Non-Human Identities | Maps to limiting lateral movement by reducing excessive internal workload privilege. | |
| Recommendation — Rotate and scope workload secrets so internal trust cannot persist through stolen credentials. Reduce non-human privileges to the minimum required for each service-to-service path. | ||
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?
