Briefly: Trusted IP Ranges only decide whether a user is asked for an identity verification code. Profile Login IP Ranges decide whether the user gets in at all. The profile restriction is checked first and a trusted range cannot rescue you from it. If someone is locked out of your org this morning, it is the profile setting, every time.
The two settings, and where they live
Trusted IP Ranges sit in Setup under Security, Network Access. They are org-wide. A login from inside one of these ranges skips identity verification: no emailed code, no challenge on a new browser. Nothing is blocked by this setting. It relaxes friction and nothing else.
Login IP Ranges sit on the profile. They are a hard allowlist. If a profile has any login IP range defined, a user on that profile can only log in from inside one of those ranges. Everything else is refused with a restricted IP error.
Login IP Ranges are a profile-only setting. A permission set cannot express them, which is one of the reasons a “one profile for everyone” plan stalls in orgs with network restrictions.
The order they apply
- Does the user’s profile have login IP ranges? If yes, and the request address is outside them, the login is refused. Nothing further is evaluated.
- If the profile has no ranges, is the address inside an org Trusted IP Range? If yes, the user logs in without verification.
- If neither applies, Salesforce challenges the user when it does not recognise the browser or device.
So Trusted IP Ranges are useless as a security control, and profile Login IP Ranges are useless as a convenience control. People routinely configure one expecting the other’s behaviour.
The lockout, and how to not have it
The classic incident: an admin adds the office range to the System Administrator profile on a Friday, the office renumbers its addresses, and on Monday nobody with admin rights can log in from anywhere. The restriction applies to API logins too, so your integration user and your deployment pipeline go down with it.
Keep one break-glass administrator account on a profile with no login IP ranges at all. Give it multi-factor authentication, a long random password in a vault, and a real audit trail. That account is the whole recovery plan, and it costs one user licence.
Recovering without it means finding a machine inside an allowed range, or a user on an unrestricted profile with enough rights to edit the profile. Salesforce support can help in some circumstances, and an outage is the wrong time to learn which.
The switch that turns a login control into a session control
Session Settings has a checkbox called “Enforce login IP ranges on every request”. With it off, the profile ranges are checked when the user logs in. With it on, they are checked on every page request, so a user who moves from the office network to a mobile hotspot mid-session is thrown out immediately rather than at next login.
That is the correct setting for a genuine network control, and the one most likely to generate tickets you did not anticipate. Turn it on deliberately, after checking what your VPN does to egress addresses.
Where each one actually belongs
Use Trusted IP Ranges for your offices, so staff on the corporate network are not challenged every week. Describe it in your documentation as friction reduction, not as an access control.
Use profile Login IP Ranges for integration and service accounts, where the source address is genuinely fixed. That is where the restriction earns its keep: a leaked integration credential is worth much less if it only works from one address. Cloud providers rotate egress addresses, so pair it with a documented owner.
For human users, multi-factor authentication is the stronger and less brittle control. Login IP ranges on a sales team’s profile produce lockouts on every business trip and stop nobody who has stolen a session.
Frequently asked
Does a trusted IP remove the need for a security token? For username-password API logins, yes. Logging in from inside a trusted range means the security token is not required, which is why so many legacy integrations depend on this setting without documenting it.
Do login IP ranges apply to OAuth? An OAuth authorisation is a login, so it is subject to the same restriction. This is where a connected integration breaks after its host changes address pool.
Can I set login IP ranges with a permission set? No. Session settings can be raised through a permission set, login IP ranges cannot. Plan your profile count around that.
Does either setting affect the mobile app? Both do. Mobile clients log in like anything else, and a strict profile range makes the app unusable off the corporate network.
