How should security teams base infrastructure access on identity rather than network location?

Identity as the trust boundary for infrastructure access

Identity-based access works because it binds permission to the actor making the request, rather than to where the request happens to originate. In cloud and hybrid estates, that distinction matters: IP ranges, subnets, and office networks are mutable infrastructure details, while identity gives you a stable authorization anchor for people, services, workloads, and automation.

The practical shift is from “is this traffic on a trusted network?” to “is this a trusted and properly authorized identity, doing the right thing, with the right scope?” That change supports least privilege, reduces broad network allowlists, and makes access decisions easier to reason about when systems move, scale, or span multiple environments.

This is also why identity-based access fits modern control planes better than location-based rules. Network location can still support segmentation, but it should not be the primary trust signal for access decisions that are meant to survive cloud elasticity, remote work, and multi-environment deployment.

What changes when identity becomes the control point

Once identity is the primary gate, access policy can be expressed in terms of who or what the requester is, what it is allowed to do, and under which conditions it should be admitted. That makes authorization decisions more precise than subnet membership, which often groups too many systems together and forces compensating exceptions.

Identity-based access also improves lifecycle control. When an identity is deprovisioned, rotated, or reduced in privilege, the access decision changes with it. By contrast, network-based trust tends to linger after the original operational reason for access has disappeared, which is one reason overexposure accumulates in mature environments.

For infrastructure, the most useful pattern is to combine identity with contextual checks rather than replace one brittle trust model with another. Teams usually still want device posture, device trust, or session conditions, but those should refine an identity decision, not substitute for it.

Why network location fails as a durable trust signal

Network location is a weak proxy for intent or legitimacy. In elastic cloud environments, the same service may move across hosts, subnets, and accounts; in hybrid estates, remote users and distributed workloads frequently originate from outside any stable “trusted” network. If access policy depends on fixed address assumptions, teams end up creating exceptions that become the real control surface.

That operational burden is not just administrative noise. It leads to stale rules, sprawling allowlists, and confusion about which paths are actually approved. The more the environment changes, the more a location-based model pushes teams toward blanket access and manual cleanup, both of which weaken security posture over time.

Identity-based access is more resilient because the access decision survives network churn. It aligns the authorization model with the actual security question, whether the requester is a human operator, a service account, or an automated workload acting within its intended scope.

Risk and Threat Considerations

Location-based trust can be abused when attackers obtain network adjacency, tunnel through approved paths, or inherit trust from overly broad internal segments. Once access is tied to the network rather than the actor, a single compromised host, VPN session, or misplaced rule can expose systems that were never meant to be broadly reachable.

Failure mechanism: A network-origin rule grants access because traffic appears to come from a trusted subnet, even though the requester is unauthorized, compromised, or operating outside its intended purpose. That creates a trust shortcut that bypasses identity proof, privilege scoping, and accountability.

Impact: Compromise can spread laterally, overprivileged paths become easier to exploit, and incident response becomes harder because the network no longer tells you whether the actor itself was legitimate.

Practitioner Guidance

What to prioritise: Start by moving high-value infrastructure access to identity-backed policy, especially admin paths, build systems, and service-to-service access where broad network trust usually hides. Keep network controls as segmentation and containment, not as the primary admission rule.

What to verify: Confirm that every allowed path can answer three questions cleanly: which identity is being authorized, what action is permitted, and what condition caused the grant. If a rule can only be explained as “it comes from that subnet,” it is usually too coarse to trust.

Common mistake: Teams often preserve legacy allowlists “just in case” after introducing identity controls. That leaves two overlapping trust models in place and makes it hard to know which one is actually enforcing access, especially during incidents or audits.

Practitioner takeaway: The goal is not to eliminate network controls, but to stop treating network location as proof of trust. Stable access decisions should follow identity and privilege, while the network remains a containment layer.

Related resources from NHI Mgmt Group

• How should security teams implement SSH access so that identity and policy matter more than network location?
• How should security teams decide whether JIT access is safe for non-human identities?
• How can security teams combine network access, identity, and authorization without creating overlapping controls?
• How should security teams prioritise identity governance when cloud, infrastructure, and application access are all changing at once?