Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
DictionaryNNetwork Access
AdministrationAdvanced

Network Access

Network Access is the Salesforce Setup configuration that defines trusted IP ranges from which users can log in without triggering Identity Verification challenges.

§ 01

Definition

Network Access is the Salesforce Setup configuration that defines trusted IP ranges from which users can log in without triggering Identity Verification challenges. The page exposes a list of IP address ranges that the platform considers trusted networks (typically corporate office IPs, VPN endpoints, or known partner infrastructure). Users logging in from within these ranges skip the verification prompt that would otherwise fire on a new device or location. Network Access works alongside per-profile Login IP Range restrictions; Network Access is org-wide trust, profile-level Login IP Range is per-profile restriction.

The two settings serve different purposes that are often confused. Login IP Range on a profile restricts which IPs users with that profile can log in from; users outside the range cannot log in at all. Network Access lists trusted ranges that exempt users from verification but still allow login from any IP. Most B2B orgs configure both: Login IP Range to restrict integration users to specific data center IPs, Network Access to reduce verification friction for office-based employees.

§ 02

How Network Access reduces login friction

Network Access versus Login IP Range

Network Access is org-wide and additive (adding IPs reduces verification friction). Login IP Range is per-profile and restrictive (adding IPs may further restrict where the profile can log in). Conflating the two produces misconfiguration: admins sometimes add trusted office IPs to Login IP Range thinking they are reducing friction, when in fact they are restricting access. Understand the distinction before configuring either.

Configuration through Setup

Setup > Security > Network Access > New. Enter the start and end IP for the range (IPv4 or IPv6). Save. The IPs are immediately trusted; the platform stops prompting verification for logins from within the range. The configuration is org-wide; there is no per-profile or per-user Network Access setting.

Trusted IP range identification

Add corporate office public IPs, VPN egress IPs, partner data center IPs that should be considered trusted. Get the IP list from corporate IT; DHCP-assigned ranges or shifting cloud IPs are poor candidates because they change without notice. Stable known-good IPs are the right targets.

Effect on Identity Verification

Logins from trusted IPs skip the new-device and new-location verification challenges that Identity Verification would otherwise trigger. MFA enforcement still applies independently: an org with mandatory MFA still prompts for MFA even from trusted networks. Network Access reduces but does not eliminate authentication friction.

Effect on API access

Network Access affects browser-based login flows. API access using OAuth or session tokens has its own IP restriction mechanisms through the Connected App. Network Access does not directly affect API integration patterns; for those, configure the Connected App's IP restrictions.

Maintenance and audit

Network Access ranges accumulate over time. Old office IPs no longer in use, retired VPN endpoints, partners no longer active. Quarterly audit: review each range, confirm it is still trusted, remove stale entries. Bloated Network Access reduces the security value of the feature; trusted should mean actually trusted.

Interaction with VPN and remote work

Remote work shifted many users away from corporate offices. Network Access often becomes less useful: home IPs are dynamic, VPN endpoints may shift. Some orgs rely entirely on Identity Verification for the modern workforce, with Network Access only listing the legacy corporate data center IPs. Plan based on your workforce model.

§ 03

Configure trusted IP ranges

Configuring Network Access is straightforward but the design decisions about which IPs to trust matter. The steps below cover both.

  1. Identify trusted IP ranges

    Work with corporate IT to get stable known-good IPs: office public IPs, VPN egress IPs, partner data center IPs. Exclude dynamic ranges.

  2. Open Network Access

    Setup > Security > Network Access. The page lists current trusted ranges.

  3. Add ranges

    For each range, click New, enter start and end IP, optional description. Save.

  4. Test from a trusted IP

    Log in from within a configured range. Confirm Identity Verification does not trigger. If it does, verify the IP is in the range.

  5. Verify MFA still applies

    Confirm MFA prompts even from trusted networks. Trusted IP exemption does not bypass MFA.

  6. Document the ranges

    Maintain a separate doc explaining what each range represents. Future admins will not infer office IPs from the addresses alone.

  7. Schedule quarterly audit

    Add calendar reminder to review the list. Remove ranges no longer in use; confirm remaining ranges are still trusted.

Key options
IPv4 rangeremember

Start and end IPv4 addresses. Standard format.

IPv6 rangeremember

Start and end IPv6 addresses. Use for IPv6-enabled networks.

Description fieldremember

Optional note explaining the range's purpose. Critical for future audits.

Org-wide applicationremember

All users in the org are affected. No per-profile or per-user override.

Range sizeremember

Small (single IP) to large CIDR blocks. Smaller is safer; large blocks include more risk.

Gotchas
  • Network Access and Login IP Range are different. Conflating produces misconfiguration.
  • DHCP ranges and shifting cloud IPs do not belong in Network Access. They change without notice and break the trust assumption.
  • MFA is independent. Trusted IPs skip verification but still prompt MFA when mandatory.
  • Network Access does not affect API access. For OAuth integrations, configure Connected App IP restrictions.
  • Remote work reduces Network Access value. Home IPs are dynamic; rely primarily on Identity Verification for remote workforce.
Was this entry helpful?
Help us write better definitions. Quick reactions or detailed edit suggestions.

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. Why is understanding Network Access important for Salesforce admins?

Q2. Can a Salesforce admin configure Network Access without writing code?

Q3. What is the primary benefit of Network Access for Salesforce administrators?

§

Discussion

Loading…

Loading discussion…