Salesforce holds some of your most sensitive customer and business data, so controlling which networks can reach your org is a basic part of keeping it secure. IP whitelisting in Salesforce means allowing logins and connections only from a defined list of trusted IP addresses or ranges, so that access from unrecognized networks is either challenged for extra verification or blocked. It is a useful layer of access control, not a complete security strategy on its own.

This guide covers what IP whitelisting is, how to configure it using the current Salesforce Setup steps, the important difference between Trusted IP Ranges and Login IP Ranges, best practices, and where static IP allowlisting falls short so you know when to reach for stronger controls.

What Is IP Whitelisting?

IP whitelisting in Salesforce is the practice of allowing access only from a pre-approved list of IP addresses, so that logins from any other network are either challenged for extra verification or denied outright. Instead of trusting every connection, you tell Salesforce which networks are known and expected, such as your corporate offices, a VPN egress point, or a specific integration server.

Used well, IP whitelisting reduces the attack surface and makes it harder for a stolen credential to be used from an unfamiliar location. It is most effective as one layer among several, paired with multi-factor authentication (MFA) and modern authentication, rather than treated as a standalone control. On its own, an IP allowlist verifies where a request comes from, not who is behind it, which is why it belongs alongside identity controls rather than in place of them.

Configuring IP Whitelisting in Salesforce

The older navigation many guides still reference (a Security and Network tab, or options for internet, VPN, and corporate network) no longer matches the current Setup interface. Here is the accurate path for configuring org-wide Trusted IP Ranges today.

1. From Setup, type "Network Access" in the Quick Find box and select Network Access under Security.
2. Click New.
3. Enter the Start IP Address and the End IP Address for the range you want to trust. To allow a single address, enter the same value in both fields.
4. Optionally add a description that names the network or VPN the range belongs to, which makes future maintenance far easier.
5. Save. Users who log in from this range will no longer be challenged for a device-verification code.

This configures Trusted IP Ranges, which apply to your entire org. It is one of two IP mechanisms Salesforce offers, and the two behave very differently, which is the single most common source of confusion.

Trusted IP Ranges vs. Login IP Ranges: What's the Difference?

Salesforce gives you two distinct IP controls, and mixing them up leads to either a false sense of security or accidental lockouts. Label them clearly whenever you work with either one.

Trusted IP Ranges (org-wide). Set under Setup, Network Access, these apply to every user in the org. A login from outside a trusted range is not blocked; the user is challenged for identity verification (an activation code sent to their email or mobile device). Inside a trusted range, users skip the device-verification prompt, even when MFA is enabled. Think of this as a trust signal, not a barrier.

Login IP Ranges (profile-level). Set under Setup, Profiles, then the profile's Login IP Ranges, these apply only to users assigned to that profile. A login from outside the allowed range is denied outright with an error, and profile ranges are evaluated before trusted ranges. This is the hard boundary.

One practical note on IP versions: profile Login IP Ranges accept both IPv4 and IPv6, and any single range must use one family (you cannot mix IPv4 and IPv6 in the same entry). Trusted IP Ranges accept IPv4, and Salesforce's current limits also account for IPv4-mapped IPv6 addresses, so confirm the exact behavior for your release before standardizing on IPv6.

How to Whitelist an IP Address in Salesforce (Step by Step)

Whether you want a softer trust signal or a hard access boundary determines which path you take. Here are both.

Option A: Org-wide Trusted IP Range (verification, not a block)

1. From Setup, enter "Network Access" in the Quick Find box and select it.
2. Click New, enter the Start and End IP addresses (same value in both for a single IP), add a description, and save.
3. Test by logging in from an address inside the range: you should not be prompted for a verification code.

Option B: Profile Login IP Range (a hard block)

4. From Setup, enter "Profiles" in the Quick Find box and open the profile you want to restrict.
5. Find Login IP Ranges (click it in the enhanced profile view, or scroll to the related list and click New in the original view).
6. Enter the Start and End IP addresses and a description, then save. Logins from outside this range are now denied for users on that profile.
7. To verify a user's assigned range, open their profile and review its Login IP Ranges. For the strictest posture, enable "Enforce login IP ranges on every request" under Setup, Session Settings, which re-checks the IP on every request and logs a user out if their address moves outside the range mid-session.

Whichever path you choose, test from an included address before you rely on it, and never apply a profile restriction to your own System Administrator profile without a confirmed in-range connection or a backup admin account, or you can lock yourself out.

Best Practices for IP Whitelisting

A few disciplines keep IP whitelisting effective instead of fragile.

• Keep whitelisted IPs current. Office, VPN, and integration IPs change, and a stale allowlist causes login failures and outages. Set a review cadence tied to your IT security policy so ranges are updated before they break access, not after.
• Pair whitelisting with encryption and MFA. IP controls do nothing against a stolen session or a man-in-the-middle attack. Enforce SSL/TLS for traffic and require MFA so that even a login from an approved network still proves identity.
• Map which apps, users, and integrations need access. Inventory the Salesforce access points that require whitelisting, including web apps, extranets, and third-party services whose IPs sit outside your perimeter. Missing one of these is the usual cause of a broken integration after a change.
• Separate ranges by purpose. Maintain distinct entries for different networks and use cases, for example office egress versus integration servers, with clear descriptions. Granular, well-labeled ranges give you tighter control and make audits and troubleshooting far simpler.
• Test after every change. Every edit to a trusted or login range can lock someone out. Verify access from an included IP immediately after saving, and keep a backup administrator account that is not bound by a restrictive profile so a mistake never leaves you without access.

Limitations: Why IP Whitelisting Isn't Enough on Its Own

IP whitelisting is worth doing, but it is not a security strategy by itself, and Salesforce says so directly. Salesforce's own current guidance discourages relying on static IP allowlists and recommends mutual TLS (mTLS) and MFA instead, especially on Hyperforce, where the cloud infrastructure's IP addresses change dynamically. When those IPs shift, allowlists that are not updated cause connection interruptions, so the maintenance burden grows over time.

There are structural limits too. An IP allowlist confirms where a request originates, but it does not verify identity, encrypt the connection, or govern what someone is allowed to change once they are in. Certain API and OAuth flows are not governed the same way interactive logins are, so a control that looks airtight for browser access can leave gaps elsewhere. The durable approach layers IP controls with strong authentication, mTLS where appropriate, and governance over who can modify security settings and push changes to production.

Securing API and Integration Access

Integration and API access is where static IP allowlisting is most fragile. Consider a middleware or ETL connection, or a Data Loader job running from a fixed server that syncs records into Salesforce on a schedule. Adding that server's IP to your Trusted IP Ranges removes the security-token requirement for its API logins, which is convenient, but if the server's address changes, or the workload moves to dynamic cloud infrastructure, the integration breaks until someone updates the list.

For connected apps, integration users, and automated jobs, treat IP allowlisting as one input and lean on stronger controls: scoped OAuth, mTLS where Salesforce supports it, and tight management of the credentials each integration uses. Just as important is governing the pipeline that changes your security configuration, so that whitelist edits, profile changes, and permission updates are reviewed, tracked, and reversible. Flosum's zero-trust security and risk and governance tooling adds that audit trail and deployment-level control on top of Salesforce's native settings.

Conclusion

IP whitelisting is a solid first layer for Salesforce access control, but it is not the whole picture. Use the right mechanism for the job (Trusted IP Ranges for smoother verification, Login IP Ranges for a hard block), pair it with MFA and mTLS, and test every change so you never lock yourself out. When you are ready to move from a single setting to enforced, auditable governance across your org, Flosum's zero-trust security and audit tooling give you access control, change tracking, and the evidence your compliance team needs. Request a demo to see it in action.

Frequently Asked Questions