A network-based access control that allows sign-ins only from approved IP addresses or ranges. It helps reduce exposure from unfamiliar locations, especially when paired with MFA and strong monitoring. This control is useful when organizations can predict where legitimate Salesforce access should originate.
How Trusted Login IP Ranges Work
Trusted login IP ranges add a location-based gate to the sign-in path. Instead of treating every login attempt the same, the control checks whether the source address falls within approved corporate or partner ranges before allowing access to the application or identity provider.
This makes the control most useful where legitimate access originates from a stable set of office egress points, VPN exits, or managed network boundaries. It is less effective when users roam widely, rely on consumer networks, or work from environments where IP addresses change frequently.
In practice, trusted IP ranges are a coarse-grained access filter, not a substitute for authentication or session security. They narrow the reachable attack surface, but they do not prove that the person at the keyboard is the rightful user, and they do not stop abuse from inside an approved network.
Why Organisations Use Them
Trusted IP ranges are usually adopted to reduce exposure from unfamiliar locations and to make sign-ins easier to interpret. When a business knows where its workforce, administrators, or integrations should normally originate, the IP boundary becomes an additional signal for access policy and monitoring.
They are often paired with MFA, conditional access rules, and alerting, because the value comes from layering controls. A login from an approved range can still be suspicious if the device, time, account behaviour, or authentication pattern looks unusual.
For environments with predictable network perimeters, the control can also support policy enforcement for regulated systems or partner access. For example, if a platform is intended to be used only from a fixed office, trusted ranges help convert that expectation into an explicit technical rule.
Common Limitations and Failure Modes
IP-based trust is easy to misunderstand because a known address does not equal a trusted user, device, or session. Attackers who already hold valid credentials, a stolen session, or access through an approved network path may bypass the intended protection.
The control also depends on the accuracy of network inventory and egress design. If VPN endpoints, cloud NAT ranges, or remote access paths change without being updated, legitimate users can be locked out. If the approved ranges are too broad, the control can become little more than a weak perimeter marker.
Trusted ranges are especially fragile when organisations have distributed workforces or dynamic cloud networking. In those cases, the policy can drift from a practical control into an exception-heavy rule set that users, administrators, and security teams stop trusting.
How to Apply the Control Well
The strongest implementations treat trusted IP ranges as one input in a broader access decision, not the decision itself. That means pairing them with MFA, device posture checks, session monitoring, and clear change control for approved ranges. Salesforce documentation and broader identity guidance both reflect this layered approach, and the same principle appears in NIST SP 800-63 Digital Identity Guidelines and NIST Cybersecurity Framework 2.0.
Because the control depends on network provenance, it should be maintained with the same discipline as any other boundary control. Approved ranges need ownership, review, and rapid revocation when office locations, VPN design, or third-party connections change. Where the policy protects sensitive account activity, least-privilege thinking from PCI DSS v4.0 is a useful reference point for keeping access narrower than business convenience alone would suggest.
When sign-in traffic is tightly tied to known network paths, monitoring becomes more useful too. Unexpected source geographies, login failures from outside the approved set, and sudden spikes from a trusted range can all indicate a policy gap, a stolen credential, or an insider-path abuse attempt.
Risk and Threat Considerations
Trusted IP ranges reduce exposure, but they also create a boundary assumption that attackers can target. If credentials, sessions, or a remote access path are compromised, the attacker may no longer need to look unusual from the network point of view.
Failure mechanism: The control fails when IP location is treated as evidence of trust rather than one weak signal in a layered decision. A compromised account, a rogue VPN hop, or an abused internal network path can present as an approved source and defeat the intended restriction.
Impact: Successful abuse can expand the blast radius of stolen credentials, hide suspicious logins inside normal corporate traffic, and delay detection because the source address appears legitimate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Authenticator Assurance and Federation Guidance — Digital Identity Assurance and Authenticator Guidance | Trusted IP ranges affect sign-in assurance, but must sit beside stronger authentication decisions. |
| Recommendation — Combine trusted IP ranges with phishing-resistant authentication and session controls. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication and Access Control | The control is an access restriction that supports identity and access governance at sign-in. |
| Recommendation — Use PR.AA to bind approved-network rules to broader access control decisions. | ||
| CIS Controls v8 | 6 — Access Control Management | Approved login ranges are a form of access restriction that should be governed as part of account access. |
| Recommendation — Document and review approved source ranges alongside account and access permissions. | ||
| PCI DSS v4.0 | 7 — Restrict Access by Business Need to Know | Trusted login IP ranges narrow who can reach a system and from where, supporting least-privilege access. |
| 8 — Identify Users and Authenticate Access to System Components | The range check strengthens sign-in controls but does not replace strong user authentication. | |
| Recommendation — Restrict access to approved network paths that match business need and role. Require strong authentication in addition to network-based sign-in restrictions. | ||
Practitioner Guidance
Governance implication: Treat approved IP ranges as controlled policy assets, not as a one-time configuration task. They need ownership, review cadence, and a clear process for adding or removing ranges when network topology changes.
What to watch for: Overly broad ranges, stale exceptions, and repeated login attempts from outside the approved set are signals that the control is either being bypassed or no longer matches how people actually access the environment.
Practitioner takeaway: The control works best as a narrowing layer for predictable access patterns, but it should never be the only thing standing between an attacker and a sensitive account.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
