How should security teams design access control when users connect from constantly changing IP addresses?

Security teams should avoid treating IP address as identity and instead bind access to a stable user and device identity, backed by strong authentication and policy. That approach lets controls follow the person or workload across remote access, cloud, and internal networks. It also reduces the chance that a changing address or reused address will create overbroad trust or broken enforcement.

Why IP Address Should Not Be the Trust Anchor

When user locations change constantly, IP address becomes a weak and unstable signal for access control. It is useful as context for risk scoring, anomaly detection, or geo-based policy, but it should not be the thing that defines who the user is or what they can do. Access decisions need a stable identity layer that survives network churn.

That is especially important because IPs can be shared, reassigned, NATed, proxied, or changed by roaming clients. If you bind authorization too closely to source address, you create brittle controls that either block legitimate users or expand trust too widely when addresses overlap.

A better model is to treat IP as one attribute among many, not as a substitute for identity. Stable identity plus policy gives you continuity across home networks, mobile connections, VPNs, cloud environments, and internal segments without turning address changes into an access problem.

What the Access Decision Should Be Bound To Instead

The access control decision should follow the authenticated user, device, workload, or session, depending on the use case. In practice that means strong authentication, device posture where needed, and policy that can evaluate context without assuming the network location is reliable.

For human access, the main control plane should be identity, role, entitlement, and assurance level. For service or workload access, the same principle applies, but the binding is to the workload identity and its credential or token rather than to an IP range. This is why controls that focus on authentication and authorization are more durable than network allowlists alone. NHIMG’s IAM and IGA Basics is a useful foundation for separating authentication from authorization and for understanding how entitlements should be governed independently of location.

Where users are remote, adaptive policy often works better than static network trust. That can include device checks, step-up authentication, and short-lived access decisions that are re-evaluated at session start or during sensitive actions. For teams standardising the model across cloud and remote access, Remote Access Identity Guide and Authorisation Models Guide both support the idea that access should be determined by identity and policy, not by network origin alone.

How to Make the Model Practical Without Creating Breakage

Design the policy so that IP address contributes to risk scoring or step-up logic, but does not act as the sole gate. That means an unknown or changing address should trigger stronger verification in some cases, not a hard assumption that the user is untrusted or trusted by default.

Teams should also make sure the policy engine can distinguish between interactive user access and machine access. A developer on LTE, a contractor on a home ISP, and a cloud workload behind dynamic egress addresses are all different cases, and they need different identity bindings. For workload and service connections, use stable workload identity patterns rather than address-based exceptions. NHIMG’s Cloud Workload Identity Guide is relevant when the access problem is really about non-human or service-to-service trust rather than human login.

Operationally, the control should be easy to explain: the user proves identity, the device or workload proves its trust signals, and the policy decides whether the action is allowed. That is more resilient than maintaining ever-growing IP ranges, and it scales better when staff travel, endpoints roam, or cloud providers change egress. When teams need to review whether those entitlements still make sense, Access Reviews and Certification Guide helps connect access decisions back to ownership and entitlement hygiene.

Risk and Threat Considerations

Over-relying on IP address creates two common failure modes: legitimate access is blocked when addresses change, or insecure access is allowed when an address is assumed to be trusted. In both cases, the organisation can end up with workarounds that weaken the control further, such as permanent allowlists, shared VPN exits, or excessive exceptions.

Failure mechanism: Attackers and ordinary users alike can exploit the fact that IPs are mutable, shared, and often outside the control of the organisation. When policy keys off network location more than identity, it becomes easier to overtrust a reused address, misattribute a session, or leave a broad exception in place after the original condition has changed.

Impact: The result can be unintended access, broken least privilege, fragile remote access, and weaker incident triage because the network signal is no longer a dependable indicator of who is acting. The larger the estate, the more these mistakes compound across users, devices, vendors, and cloud workloads.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, 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 SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Users changing IPs still need stable user authentication.
	IA-5 — Authenticator Management	Changing networks increases reliance on durable credentials and session trust.
	AC-6 — Least Privilege	Location-aware access should still enforce minimal entitlement.
Recommendation — Use IA-2 to anchor access on authenticated user identity, not source address. Use IA-5 to manage credential lifecycle and avoid brittle IP-bound trust. Apply AC-6 to keep permissions narrow regardless of client IP.
NIST Zero Trust (SP 800-207)	Policy Decision Point — Policy Decision Point	Zero Trust evaluates each request with context instead of trusting network location.
Recommendation — Centralize request evaluation in the policy engine and treat IP as one input only.
CIS Controls v8	CIS-6 — Access Control Management	Access control should follow identity and entitlement management, not address lists.
Recommendation — Use CIS-6 to review and enforce access based on identity and business need.

Practitioner Guidance

What to prioritise: Make identity the primary control and use IP only as a supporting signal. If a control cannot survive an address change without widening trust, it is too dependent on location.

What to verify: Confirm that authentication, session handling, and authorisation all still work when the user moves between networks, because that is the real test of a location-independent design. Also verify that exceptions are time-bound and tied to a named business need rather than to a static address range.

Practitioner takeaway: The goal is not to eliminate IP-based context, but to ensure that changing IPs never become a hidden identity mechanism or a shortcut around proper access control.