Ga naar inhoud
SteveTechArcSteveTechArc Courses

IP Ranges, Login Hours and Sessions

Deze inhoud is nog niet vertaald.

Module 3 of 5 in the shared chapter The Front Door: Logging In to Salesforce, chapter 2 of Securing Salesforce: Sharing and Visibility and part of the Identity and Access course. Each module stands on its own.

The question this module answers: Beyond who you are, how does Salesforce control where you log in from, when, and for how long?

Module 2 was about the first question at the door: who are you? But a good guard asks more than that. Where are you coming from? What time is it? And once you’re in, how long should your wristband last?

Salesforce lets you answer all three. Each answer is another layer at the front door, and each one has a catch you need to know before you turn it on.

From where: login IP ranges

Section titled “From where: login IP ranges”

Every device on the internet reaches Salesforce from an IP address. On a profile, you can list the ranges of addresses its users are allowed to log in from. Salesforce is blunt about what that does: “When you define IP address restrictions for a profile, a login from any other IP address is denied” (Restrict Login IP Addresses in Profiles (opens in a new tab), Salesforce Help, checked 2026-11-01). There’s no challenge, no second chance. Outside the range, the door stays shut.

That’s powerful. Used well, it keeps people logging in only from your physical offices, where you know the addresses, and a stolen password is useless from anywhere else. It’s even better for an integration user. If you know the address the integration’s process comes from, lock that user to it, and the credentials only work from that one place. Salesforce’s Well-Architected guidance names exactly these two groups: enforce IP restrictions “for administrative profiles and integration users” (Well-Architected: Trust (opens in a new tab), Salesforce Architects, checked 2026-11-01).

Remember where this lives: login IP ranges are set on the profile, and every user has exactly one profile. So the real design question is granularity. The ranges have to be wide enough and narrow enough at the same time. Think about a company with a lot of offices. If one profile is shared by people in twelve offices, its ranges have to cover all twelve, plus anyone who travels between them. Make the ranges too narrow and you lock out the people in the office you forgot. Make them too wide, a huge block of addresses so nobody ever complains, and the rule stops protecting anything. Sometimes the right answer is more than one profile, so each group’s ranges can be tight; sometimes it’s an IP rule only for the profiles that truly never leave the building.

But here’s what I always show in a demo. I add a dummy range to a profile, log out, and log back in as one of its users with the right username and the right password. It fails, and the message doesn’t say anything about an IP address. It’s the same generic error you’d get for a wrong password. The user doesn’t get a clear message, so the first thing they do is reset a password that was never the problem. And Setup will warn you if the range you’re saving doesn’t include your own address, so read that warning before you lock yourself out.

Login IP ranges: outside the range, the door stays shut You, at the office, inside the profile's IP range, log in and reach your org's pages. You, at home, outside the range, log in with the right password and are denied, marked with an X; the error is generic and says nothing about the IP address. Footnote: outside the range, the right password still fails, and the error doesn't say why. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.52.0", "built": "2026-10-28", "id": "DGM-SHR-FD-08", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.4.0", "theme": "stevetecharc 1.4.0"} YOU YOUR ORG You, at the office inside the profile's IP range You, at home outside the range Your org's pages you're in Login denied a generic error: nothing about the IP address log in log in, right password Outside the range, the right password still fails, and the error doesn't say why. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

From where, gently: trusted IP ranges

Section titled “From where, gently: trusted IP ranges”

There’s a second IP setting, and people mix the two up all the time. Trusted IP ranges are set once for the whole org, under Network Access, and they don’t block anyone. They list the addresses “from which users can log in without receiving an identity verification challenge.” From anywhere else, “Salesforce challenges them to verify their identity” (Set Trusted IP Ranges for Your Org (opens in a new tab), Salesforce Help, checked 2026-11-01).

So the difference is simple to say: login IP ranges on a profile block; trusted IP ranges for the org only skip the challenge. One locks a door. The other decides when the guard asks for more proof.

Trusted IP ranges: outside the range, one more question You, at the office, inside the org's trusted IP range, log in and reach your org's pages with no extra challenge. You, at home, outside the trusted range, log in and are asked to verify your identity, one more question, then you're in. Footnote: trusted ranges skip the challenge; they block no one. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.52.0", "built": "2026-10-28", "id": "DGM-SHR-FD-09", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.4.0", "theme": "stevetecharc 1.4.0"} YOU YOUR ORG You, at the office inside the org's trusted range You, at home outside the trusted range Your org's pages in, with no extra challenge Verify your identity one more question, then you're in log in log in Trusted ranges skip the challenge. They block no one. HOW TO READ IT challenged, not blocked © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Two dated notes. Since Winter ‘26, Salesforce limits how large these ranges can be, for both settings: at most 16,777,216 IPv4 addresses, not counting the private 10.x.x.x range. And for orgs on Hyperforce, Salesforce suggests a preferred alternative to IP allowlists, such as mutual TLS or allowing domains (Set Trusted IP Ranges for Your Org (opens in a new tab), checked 2026-11-01). Addresses change more than they used to, especially for people working from home, so an IP rule is one layer, never the only one.

And treat any IP rule with some caution. An IP address tells you where a request seems to come from, not who sent it. Addresses can be spoofed in some attacks, and more often they’re borrowed: an attacker who gets onto a laptop in your office, or onto your company’s VPN, arrives from a trusted address. That’s why trusted IP ranges only ever skip a challenge, and why even login IP ranges sit beside passwords, MFA and sessions rather than replacing them. IP rules are a real level of security. They’re good to a point, but they’re not perfect, and no design should depend on them alone.

When: login hours

Section titled “When: login hours”

On a profile you can also set the hours its users may log in. If I know a team only works certain hours, I don’t want anyone with that profile logging in at midnight or one in the morning. If they are, that could be nefarious activity.

The catch is the same one as IP ranges. When I set a narrow window on a profile, one hour a day, and try to log in outside it, I get the generic error message again. It’s a hard stop, and it can make the user think they have a password problem. Know that before you set it, and tell your help desk.

Two more details from Salesforce. If users are still logged in when their hours end, “they can continue to view their current page, but they can’t take any further action.” And the time zone matters: the first time login hours are set on a profile, they follow the org’s default time zone, and after that they stay put, “even when a user is in a different time zone or the org’s default time zone changes” (View and Edit Login Hours in Profiles (opens in a new tab), Salesforce Help, checked 2026-11-01). For a team spread across time zones, do the arithmetic before you save. Login hours work for programs too. Salesforce’s guidance is to “restrict service accounts to expected operational windows” (Well-Architected: Trust (opens in a new tab)): a nightly job that only ever runs between one and three in the morning has no reason to log in at noon.

Login hours: outside the hours, the same generic error A user with the profile logs in at 9 a.m. on a Tuesday, inside the profile's hours, and reaches your org's pages. The same user tries at 1 a.m. on a Sunday, outside the hours, with the right password, and is denied, marked with an X, with the same generic error. Footnote: a login at 1 a.m. from a 9-to-5 team is worth stopping; tell the help desk why it fails. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.52.0", "built": "2026-10-28", "id": "DGM-SHR-FD-10", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.4.0", "theme": "stevetecharc 1.4.0"} YOU YOUR ORG 9 a.m., Tuesday inside the profile's hours 1 a.m., Sunday outside the hours Your org's pages you're in Login denied the same generic error log in log in, right password A login at 1 a.m. from a 9-to-5 team is worth stopping. Tell the help desk why it fails. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

How long: sessions

Section titled “How long: sessions”

Back to the wristband from module 1. Once someone is in, the session is what they show on every page, and while it’s valid, it is the access. So how long it lasts is a security decision.

The session timeout is the duration of inactivity before Salesforce makes the user log in again. Shorter is safer: an unattended laptop or a copied session token is only useful for so long. And it shouldn’t be the same for everyone. Salesforce’s guidance is to set timeouts “appropriate to user privilege levels (shorter timeouts for high-privilege accounts reduce risks from unattended sessions)” (Well-Architected: Trust (opens in a new tab)). An admin’s session should end sooner than a sales rep’s. Users get a warning shortly before it happens, and you can choose to force a logout when it does. Like passwords, you can set this for the whole org and on a profile: “When set, the profile settings override the org-wide settings” (Edit Session Settings in Profiles (opens in a new tab), Salesforce Help, checked 2026-11-01).

Two more session settings tie the wristband to where it was given out (Modify Session Security Settings (opens in a new tab), Salesforce Help, checked 2026-11-01):

  • Lock sessions to the IP address from which they originated. A session stolen and replayed from somewhere else stops working. That’s real protection against session hijacking, but it can trouble mobile users and some apps, whose address changes while they work. Salesforce also warns that it “can break automated integrations”, and gives the fallback: “where locking isn’t viable, enforce Strict Login IP Ranges at the profile level with ‘Enforce login IP ranges on every request’ as the compensating control” (Well-Architected: Trust (opens in a new tab)).
  • Enforce login IP ranges on every request. Normally a login IP range is checked when you log in. With this, it’s checked on every page, so leaving the range mid-session ends the session too.
A session locked to its IP address You, at your address, logged in with a session, use your org's pages. Someone else, at another address, tries the org's pages with a copy of your session and is rejected, marked with an X, because the session is locked to the address it came from. Footnote: lock the wristband to the wrist it was given to. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.52.0", "built": "2026-10-28", "id": "DGM-SHR-FD-11", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.4.0", "theme": "stevetecharc 1.4.0"} YOU YOUR ORG You, at your address logged in, with a session Someone else, another address with a copy of your session Your org's pages your session works here, from your address Session rejected locked to the address it came from pages, with your session pages, with the copied session Lock the wristband to the wrist it was given to. HOW TO READ IT a copied session © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Where you can’t come from: anonymizing networks

Section titled “Where you can’t come from: anonymizing networks”

The last layer is one Salesforce now applies for you. Since 20 November 2025, it has taken “enhanced measures” against connections from anonymizing VPNs, proxies and high-risk IP addresses, the kind of networks attackers hide behind. Since 24 April 2026 it covers connected app and API traffic too, and the response is strong: the user account “will be frozen,” every OAuth refresh token granted to it is revoked, and an admin has to restore access (Preventing Connections from Anonymizing VPNs, Proxies and High-Risk IP Addresses (opens in a new tab), Salesforce Help, published 2026-09-04, checked 2026-11-01).

For an architect, that’s a line in every integration design: an integration that routes its traffic through an anonymizing VPN or proxy will freeze its own user. Know where your integrations really connect from.

What an architect decides here

Section titled “What an architect decides here”
  • Which profiles need login IP ranges, and how wide each profile’s ranges must be to cover every office its users work from, and no wider.
  • Which integration users can be locked to one originating address.
  • Which addresses, if any, are trusted for the org, knowing that trust only skips the challenge.
  • Which profiles need login hours, in which time zone, and what the help desk tells a user who hits the generic error.
  • How long a session lasts, org-wide and per profile, shorter for the most privileged users, and whether sessions are locked to their IP address, or, where that breaks an integration, checked against the login IP ranges on every request.
  • Which service accounts and integration users get login hours that match when their jobs actually run.
  • Where every integration really connects from, so none of them freezes its own user.

Beyond the exam: what AI changes. A stolen password or a stolen session is only useful from somewhere. Attackers, now helped by AI tools that work around the clock, try from wherever they can hide. Every layer in this module narrows the somewhere: not from that address, not at that hour, not for that long, and not from an anonymizing network.

Explore

Section titled “Explore”

Volg mij

© 2023–2026 Twinshark LLC. All rights reserved. · Gebruik van content

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.

Juridische mededelingen zijn in het Engels, en de Engelse versie is leidend.