Network-centric controls can accidentally treat network location as trust, which weakens zero trust assumptions. If services on the same segment can communicate directly, a compromised container or adjacent workload may move laterally and reach another service without passing through policy checks. That is why access control needs to be enforced on the request itself, not only on the network path.
Why the network boundary becomes a liability
Zero trust assumes that adjacency is not a trust signal. Network-centric controls, by contrast, often inherit an older model where being on the “right” subnet, VLAN, or cluster is treated as a proxy for legitimacy. That creates a dangerous gap: the control may still be technically present, but it is anchored to location rather than to the request, the caller, or the action being attempted.
When that model is used between internal services, the blast radius can expand quickly. A single compromised pod, container, or adjacent workload may inherit the same lateral reach as a healthy service if policy is only enforced at the perimeter or at coarse network chokepoints.
- Segmentation can reduce exposure, but it does not validate intent.
- Allow lists based on source IP or subnet often fail once an attacker lands inside the trusted zone.
- Internal traffic can look “normal” to the network while still being unauthorized at the application layer.
That is why NIST SP 800-207 Zero Trust Architecture is a better fit for this problem than traditional trust-by-location thinking, because it emphasizes explicit policy enforcement and continuous verification rather than implicit network trust. The same principle is reinforced in OWASP Non-Human Identity Top 10, which treats excessive privilege and weak credential governance as direct drivers of internal compromise paths.
What changes when access is decided at the request layer
Request-level enforcement changes the security model in a material way. Instead of asking whether a workload is “inside” the network, the control plane evaluates who or what is calling, what it is asking for, and whether that specific action should be allowed. That makes authorization portable across networks, clusters, and service meshes, which is essential when internal services are dynamic and short-lived.
This also improves failure containment. If a service is compromised, the attacker should not automatically inherit access to every peer in the same environment. A request-aware policy can constrain method, path, audience, scope, or service-to-service entitlement so that compromise of one workload does not become universal internal access.
In practice, this is where workload identity becomes more important than address-based trust. A service mesh or proxy can enforce policy, but the underlying decision still has to be bound to an identity and an allowed transaction, not merely to a packet entering a trusted segment.
For a practical reference point on workload identity and cryptographic service identity, Guide to SPIFFE and SPIRE is useful because it shows how service identity, attestation, and trust bundles support request-level trust. For a broader identity and Zero Trust lens, Ultimate Guide to NHIs ties that mechanism to lifecycle, visibility, and least privilege controls.
What practitioners should verify before they trust east-west traffic
Practitioners should verify that the enforcement point sits on the transaction path, not just on the network path. If the policy only controls ingress, VLAN membership, or security group membership, then internal service-to-service abuse may still bypass meaningful authorization. The control should be able to inspect the caller, the destination, and the permitted action.
They should also verify that every service has a distinct identity and that privilege is scoped narrowly enough to survive compromise. Shared credentials, broad service accounts, and unmanaged tokens undermine the very idea of zero trust because they let a single compromise propagate across multiple services with little friction.
What to measure: Track how many internal service calls are authenticated and authorized at the request layer, not just permitted by network policy. Also measure the count of services that can reach production peers without an explicit policy decision, because that is the clearest sign that network trust is still functioning as hidden authorization.
Practitioner takeaway: Zero trust between internal services fails when the network is treated as the policy boundary, so the control objective is to make every meaningful service call prove identity and permission before the request is accepted.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | Network-centric trust failures are access control failures across internal service paths. |
| Recommendation — Enforce access decisions on each service request rather than relying on network location. | ||
| NIST Zero Trust (SP 800-207) | 3.b — Access to Resources is Determined by Policy | Zero Trust requires policy-based decisions instead of implicit subnet trust. |
| Recommendation — Bind east-west service access to explicit policy decisions and continuous verification. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Excessive Privilege | Overbroad service privileges amplify lateral movement after a network foothold. |
| NHI-06 — Secrets and Credential Hygiene | Internal service trust often fails when credentials or tokens are reused too broadly. | |
| Recommendation — Reduce service entitlements so a single compromised workload cannot reach unrelated peers. Rotate and scope service credentials so they cannot be reused as blanket internal access. | ||
| CIS Controls v8 | 6.3 — Access Control Management | Access control management is needed to prevent network adjacency from acting as authorization. |
| Recommendation — Require explicit authorization for internal service connections instead of trusting network position. | ||
| MITRE ATT&CK | T1021 — Remote Services | Attackers abuse internal reach to move laterally through trusted service paths. |
| Recommendation — Detect and restrict lateral movement paths that let one internal foothold reach other services. | ||
Related resources from NHI Mgmt Group
- How should security teams build a zero trust architecture that covers both internal traffic and user access from outside the network?
- What is the difference between JIT access and Zero Trust for NHIs?
- What is the difference between device trust checks and network-level zero trust network access controls?
- Why does network-based SSH access create risk in Zero Trust environments?
