Salesforce environments rarely stay simple for long. Teams expand, vendors join projects, remote work becomes the default, and integrations multiply across cloud services. That flexibility helps the business move faster, but it also expands the number of places an attacker can try to log in from.
IP allowlisting (often called IP whitelisting) is a network control that limits access to approved IP ranges. When implemented thoughtfully, it reduces the risk of credential theft turning into a full compromise, particularly for admin access and integration accounts. When implemented hastily, it turns into a wave of lockouts and broken integrations.
This article explains how to apply IP allowlisting to Salesforce in a way that supports real-world work patterns, including remote access and API-based integrations.
IP allowlisting can stop many opportunistic attacks because stolen credentials are far less useful if they’re used from an unapproved network. It also makes security monitoring clearer, since “blocked due to network policy” is a strong signal that something may be wrong.
At the same time, IP allowlisting is not a replacement for multi-factor authentication, least-privilege permissions, or good endpoint security. If a device is compromised on an allowed network, or if a privileged account has excessive permissions, IP controls alone won’t save you. The goal is to add a practical layer of defense, not to pretend IP is a perfect identity signal.
Salesforce access usually falls into two buckets: people signing in interactively (browser/mobile) and systems authenticating via APIs. IP-based controls can apply to both, but in Salesforce they’re implemented through a few different mechanisms that behave differently.
At the strictest level, profile “Login IP Ranges” function as a true allowlist. When you set allowed ranges on a profile, Salesforce denies login attempts that originate outside those ranges. This works well for stable environments such as corporate offices, call centers, and VPN egress networks.
Salesforce also supports Trusted IP Ranges (Network Access) at the org level. These are often confused with an allowlist, but they’re primarily about reducing or skipping login challenges for known networks; they don’t replace profile login IP restrictions when your goal is to deny access from unknown IPs.
One more nuance matters for real-world mobility: by default, profile login IP restrictions are often discussed as a login-time control. If you want IP restrictions to be checked continuously as the user makes requests, Salesforce provides a session setting commonly labeled “Enforce login IP ranges on every request.” This setting becomes especially relevant when users move between networks after authenticating, or when a session established in a compliant context later starts making requests from a non-compliant IP.
Many allowlisting projects fail because they start with a single question - “What IPs should we trust?”, instead of starting with “Which access patterns do we need to support?” A more stable approach is to treat Salesforce access as a small set of categories.
Office networks are straightforward, since they tend to have stable IP ranges. Remote employees are trickier, because home IPs change, users roam between networks, and mobile carriers often route traffic unpredictably. Contractors and vendors vary widely. Integrations, in contrast, should ideally be engineered to behave predictably.
Once you recognize that not all access has the same IP stability, you can scope the policy accordingly. IP allowlisting is most effective when you begin with the highest-risk targets: administrators, privileged roles, and integration users. Those accounts represent a disproportionate amount of “blast radius,” and they’re also the accounts you can usually support with more controlled network paths.
Remote work introduces a few recurring issues that can make allowlisting look “broken” even when it’s doing what it was configured to do.
Residential ISPs frequently rotate IPs. A user might appear to have a stable home IP for weeks and then suddenly get a new one. Mobile access adds another layer of unpredictability, since carrier-grade NAT and network switching can change the apparent source IP often.
The most common mitigation is to route Salesforce access through a corporate VPN or another controlled egress. That gives you stable IP ranges to allowlist without forcing users to manually report changes. If a VPN requirement isn’t feasible for all roles, a practical compromise is to keep allowlisting strict for privileged accounts and use stronger identity controls, like MFA and conditional access at the identity provider, for the broader user base.
A second pitfall is assuming that “office IP” automatically means “trusted.” Split tunnels, local internet breakout, and guest Wi-Fi can all cause traffic to originate from networks you didn’t intend. If allowlisting is part of the plan, routing and network policy need to be aligned so users are actually taking the expected path.
Integrations are where IP restrictions can deliver outsized value, because unlike end-users, systems can often be engineered to originate from predictable networks. The cleanest design pattern is fixed egress: route outbound traffic through a controlled NAT gateway, firewall, or proxy so the integration consistently comes from a stable set of IPs. Those IPs then map cleanly to Salesforce’s enforcement points.
In practice, IP enforcement for API access often intersects with OAuth and Connected Apps, not just user profiles. Salesforce allows Connected Apps to define OAuth policies that determine how IP restrictions are applied for that app, including settings commonly referred to as IP relaxation (so legitimate mobile or distributed access doesn’t break) and continuous IP enforcement behavior that interacts with org session settings. This is why integration troubleshooting frequently includes both sides: the profile’s Login IP Ranges and the Connected App’s OAuth IP policy.
If your org enables “Enforce login IP ranges on every request,” it’s also important to understand how that interacts with OAuth-enabled Connected Apps, especially when an app is configured to relax IP restrictions. Salesforce explicitly notes that this combination can prevent access in some circumstances, which is a common source of “it works for some clients but not others” behavior during rollout.
Finally, the “one integration user for everything” pattern remains a major risk. When multiple systems share a single high-privilege integration identity, one leaked credential or misconfigured token becomes a master key. Splitting integration identities by function reduces blast radius and makes anomalies easier to triage, especially when you’re correlating authentication failures or “IP restricted” errors with a specific app and flow.
Even when you can’t strictly enforce allowlisting across all users, IP data still improves detection and response. A login attempt blocked due to IP policy is often an early warning sign of credential stuffing or account takeover attempts. For allowed sessions, IP and network details can highlight unusual changes in geography, ISP/ASN, or access patterns. These signals work best when paired with a clear response plan, such as forcing step-up authentication, revoking sessions, or investigating user activity when the pattern is inconsistent.
If you’re building custom API layers or exposing services that interact with Salesforce, it’s also worth aligning with established API security guidance. The OWASP API Security Top 10 is a widely used reference for common API risks and controls, and it complements network-level restrictions like allowlisting.
A safer rollout starts with observation. Before enforcing policies, collect enough information to understand where people and integrations actually originate, and identify which accounts represent the highest risk.
From there, enforce allowlisting on privileged human accounts and on integration users that can be routed through stable egress. Engineering integrations for fixed egress is often the turning point between “constant breakage” and “reliable security control,” because it eliminates the most chaotic source of IP variability.
Only after privileged access and integrations are stable should you consider expanding allowlisting to broader user populations, and even then, it’s best done in environments where VPN routing or identity-layer conditional access can handle edge cases without creating a flood of exceptions.
In complex Salesforce environments with multiple integrations and mixed access patterns, organizations sometimes work with a Salesforce development company to align integration architecture, identity flows, and network controls so security measures strengthen the system without disrupting core workflows.
IP allowlisting can be a highly effective control for Salesforce when it’s applied where IP stability exists - corporate networks, VPN egress, and well-designed integration paths. The strongest results come from starting with the accounts that matter most: admins, privileged users, and integration identities, then building reliable egress and monitoring around them.
In modern environments where users work from anywhere and integrations connect from cloud services, the “right” approach is rarely a blanket rule. It’s a layered design: network restrictions where they’re feasible, strong identity controls where IP is dynamic, and monitoring that treats IP data as a helpful signal rather than a perfect truth.