Network Access
A Network Access setting in Salesforce is the org-wide list of trusted IP address ranges from which users can sign in without being challenged to verify their identity.
Definition
A Network Access setting in Salesforce is the org-wide list of trusted IP address ranges from which users can sign in without being challenged to verify their identity. You find it in Setup by entering Network Access in the Quick Find box. When a login comes from an IP inside a trusted range, the platform skips the identity verification prompt that normally fires on a new device or new location. A login from outside the ranges is not blocked. The user is simply asked to verify, usually by entering a code sent to their mobile device or email.
Network Access is often confused with the Login IP Range setting on a profile, but the two do opposite things. Network Access is additive trust applied to the whole org, and it reduces verification friction. A profile Login IP Range is restrictive. It denies login outright from any IP not in the range, for users assigned that profile. Many companies use both: a tight Login IP Range to pin integration users to known data center IPs, and Network Access to spare office staff the verification prompt.
How trusted IP ranges shape the login experience
Network Access versus profile Login IP Range
These two settings sit near each other in Setup and both deal with IP addresses, so admins mix them up constantly. Network Access is org-wide. Adding a range there marks those IPs as trusted, which means logins from them skip identity verification. It never blocks anyone. A user outside every trusted range can still log in after passing a verification challenge. A profile Login IP Range works the other way. It is assigned per profile, and it is a hard restriction. If a user with that profile tries to log in from an IP outside the listed ranges, the login is denied with no challenge offered. The practical mistake is adding office IPs to a profile Login IP Range while thinking you are reducing friction. You are not. You are locking that profile to those IPs and risking a lockout when the office network changes. Decide first what you want: looser prompts (Network Access) or a hard boundary (profile Login IP Range). They are not interchangeable, and using the wrong one quietly creates either a security gap or a support ticket.
What happens on an untrusted login
When someone logs in from an IP that is not in any trusted range, Salesforce treats it as a potential new device or location and starts identity verification. The user receives a one-time code, typically by email or to a registered mobile device, and types it back into the login screen to continue. This is not a block. After the code is verified, the session proceeds normally. Trusted IP ranges only remove that extra step for known-good networks. They do not change what the user can see or do once inside. It also helps to know what trusted ranges do not cover. Multi-factor authentication is a separate control. If your org enforces MFA, users still complete the MFA step even when they connect from a trusted IP, because MFA verifies the person rather than the network. Single sign-on flows have their own device activation behavior too. So a trusted range trims identity verification specifically, not every authentication prompt a user might hit on the way in.
Configuration limits introduced in Winter 26
Trusted IP ranges used to grow without much restraint, and some orgs accumulated enormous ranges that drained the security value of the setting. As of the Winter 26 release, Salesforce enforces hard limits. A single IPv4 range cannot span more than 33,554,432 addresses, which is two to the power of twenty-five, equivalent to a /7 CIDR block. Across all your ranges combined, the total trusted IPv4 address count cannot exceed 16,777,216. There are matching limits for IPv6, and if you use an IPv4-mapped IPv6 address the IPv4 limit applies to it. One useful exclusion: addresses in the private 10.0.0.0 to 10.255.255.255 block are not counted toward the total, because they are internal and not routable on the public internet. If you try to add a range that pushes you past a limit, the save is rejected. The takeaway is to add only the specific public IPs your users actually log in from. Wide, lazy ranges are now both unnecessary and not allowed.
Choosing which IP ranges to trust
The right entries are stable, known-good public IPs. Good candidates are corporate office egress IPs, the public IP of a VPN concentrator, and partner data center IPs you have verified with that partner. Get the list from your network or IT team rather than guessing, because the address a user sees on a personal device is rarely the egress IP the office presents to Salesforce. Poor candidates are anything dynamic. Home broadband IPs assigned by DHCP shift over time. Cloud provider egress IPs can rotate. Coffee shop and airport networks are obviously untrusted. If you trust a range that later gets reassigned to someone else, you have handed verification-free login to a stranger. So favor IPs you control and can confirm. When a network genuinely uses a fixed public address, that is the ideal thing to list. When it does not, leave it out and let identity verification do its job for those logins.
Maintenance, auditing, and cleanup
Trusted IP ranges are easy to add and easy to forget, so the list grows stale. Offices relocate, VPN endpoints get replaced, and partners end their engagements, but the old ranges often stay listed for years. Every entry that is no longer genuinely trusted is a small hole in your security posture, because it exempts that IP from verification for anyone who happens to be on it. Build a recurring review, quarterly is a sensible cadence, where you walk each range and confirm with IT that it still maps to a network you trust. Remove anything you cannot justify. The Winter 26 limits add a second reason to keep the list lean, since bloated ranges may now bump against the cap and block legitimate additions. Pair the review with a glance at Login History to see where users are actually connecting from. If a trusted range never shows up in real logins, it is a candidate for removal. A short, accurate list is both safer and easier to reason about than a sprawling one nobody remembers building.
Remote work and the shrinking role of IP trust
Network Access was designed for a world where most users sat in a corporate office behind a small set of fixed public IPs. That model has weakened. With distributed teams, people log in from home connections with dynamic addresses, from mobile networks, and from locations that change week to week. Trusting all of that is impractical and unsafe, so for many organizations the useful scope of Network Access has narrowed to a few legacy data center or office ranges, with everything else handled by identity verification and MFA. This is not a failure of the feature. It reflects a shift in how authentication is layered. The modern approach leans on verifying the person and the device, through MFA and adaptive checks, rather than trusting the network they happen to be on. Network Access still earns its place for the stable corporate IPs you do control, where skipping verification for known staff is a reasonable convenience. Just size your expectations to your actual workforce. If almost nobody logs in from a fixed office IP anymore, a long trusted list buys you very little.
History and the December 2007 baseline
Trusted IP ranges are an old part of the platform, which is worth knowing when you inherit an org with entries nobody can explain. Salesforce introduced the feature in December 2007. For orgs that were already active before that date, Salesforce populated the trusted IP list automatically at launch, seeding it from the IPs those orgs were already using. That means a long-lived org can carry trusted ranges that predate every current admin, set during a different era of corporate networking. If you are auditing an older org and find ranges with no documentation, this history is often why. Do not assume an old entry is still valid just because it has been there forever. Treat undocumented ranges with suspicion, confirm them against your current network reality, and remove the ones that no longer correspond to anything. The age of an entry is a reason to scrutinize it, not a reason to trust it. Pair this cleanup with the limit checks from Winter 26 so the list you keep is both current and within bounds.
How to add a trusted IP range
Add a trusted IP range so users on that network skip identity verification at login. You need the Manage IP Addresses permission, usually held by a System Administrator.
- Open Network Access
From Setup, type Network Access in the Quick Find box and select Network Access under the IP and Domain Access area.
- Start a new range
Click New. You will enter the first and last address of the range you want to trust.
- Enter the start and end IP
Type the Start IP Address and End IP Address. For a single host, use the same value in both fields. The range must stay within the Winter 26 size limits.
- Describe and save
Add a short description naming the network, such as the office or VPN it belongs to, then click Save. The IPs are trusted immediately.
- Verify with a real login
Have someone on that network log in and confirm they are not prompted for identity verification. Check Login History to see the source IP recorded.
The first address in the trusted range. Use a stable public IP your users actually log in from.
The last address in the range. Set it equal to the start for a single trusted host.
A free-text label. Name the network and owner so future audits can tell why the range exists.
- Network Access never blocks anyone. Outside-range users can still log in after passing identity verification, so do not use it as an access restriction.
- As of Winter 26 a single IPv4 range is capped at 33,554,432 addresses and the org total at 16,777,216. Oversized ranges are rejected on save.
- MFA still applies from trusted IPs. Trusted ranges remove identity verification, not the MFA step, so users in MFA-enforced orgs are still prompted.
- Do not confuse this with profile Login IP Range. That setting denies login outside its range. Network Access only relaxes verification.
Prefer this walkthrough as its own page? How to Network Access in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Set Trusted IP Ranges for Your OrgSalesforce
- Restrict Login IP Addresses in ProfilesSalesforce
Straight from the source - Salesforce's reference material on Network Access.
Hands-on resources to go deeper on Network Access.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does adding an IP range to Network Access do for users logging in from that range?
Q2. How does Network Access differ from per-profile Login IP Range?
Q3. Which IPs are good candidates to enter as trusted ranges in Network Access?
Discussion
Loading discussion…