Date: 20 April 2026

Every organization that runs Salesforce is sitting on a pile of sensitive data. Contact records, deal pipelines, support tickets, internal notes, and financial details; it all lives inside the CRM, accessible to anyone with the right credentials. And that last part is exactly where the risk lives. Credentials get stolen, phished, leaked, and reused across platforms every single day.

Passwords have been inadequate protection for years. Multi-factor authentication raised the bar, but it is not foolproof either: SIM-swapping attacks, MFA fatigue techniques, and session hijacking have all proven effective against it in real-world incidents. This is why network-level controls like IP whitelisting still matter. They add a layer of defense that operates independently of user credentials, and in Salesforce, they are built right into the platform.

How IP Whitelisting Works in Salesforce

The concept is straightforward. You define a list of trusted IP addresses or ranges, and Salesforce only allows login attempts from those sources. Requests originating from any other IP are either blocked outright or subjected to additional identity verification steps.

Salesforce provides two levels of IP restriction:

Organization-wide trusted IP ranges. These are set under Network Access in Setup. Any login from a trusted range skips the identity confirmation step that Salesforce normally triggers when it detects an unfamiliar IP. This is useful for office networks and corporate VPN exit nodes where you can reasonably trust that the person behind the keyboard is who they claim to be.

Profile-level login IP ranges. These are stricter. When configured, users assigned to that profile simply cannot log in from outside the defined IP ranges. There is no fallback verification, no email confirmation – the login is denied. This is the appropriate setting for profiles that have access to the most sensitive data or administrative functions.

The distinction between these two levels matters. Organization-wide ranges are a convenience feature with a security benefit. Profile-level ranges are a hard enforcement mechanism. Most organizations should be using both, applied strategically based on data sensitivity and user roles.

Why So Many Salesforce Orgs Get Access Control Wrong

Salesforce provides granular access control tools: profiles, permission sets, sharing rules, field-level security, and record-level access. On paper, the platform gives administrators everything they need to enforce least-privilege access. In practice, most Salesforce environments are far more permissive than they should be.

There are a few reasons this happens repeatedly.

Speed wins over structure during implementation. When a company first rolls out Salesforce, the priority is getting the system live. Teams grant broad access to avoid workflow disruptions, planning to tighten things later. But later gets pushed to the next quarter, then the next year, and eventually the over-permissive setup becomes the permanent baseline.

Permission sets stack up without review. As new features and integrations get added, users accumulate permission sets. Nobody goes back to audit whether earlier permissions are still necessary. Over time, individual users end up with far more access than their role requires — a textbook violation of least-privilege principles.

Sharing rules create unintended visibility. Salesforce sharing rules can expose records across teams and hierarchies in ways that are not always obvious from the admin console. A sharing rule that made sense for a five-person sales team can become a data exposure risk when the org scales to fifty users across multiple departments.

Custom code bypasses built-in security. Apex classes that run in system context ignore the user’s permission set entirely. If a developer writes a trigger or a batch job without explicitly checking object and field permissions, that code effectively has unrestricted access to the database. This is one of the most common and most dangerous patterns in Salesforce development.

These problems do not fix themselves. They require deliberate attention from someone who understands both the Salesforce permission model and the security implications of each configuration choice. This is where professional Salesforce development services become relevant — particularly for organizations that built their Salesforce environment quickly and never went back to audit access controls.

IP Restrictions and Remote Work: The Tension

Remote work created a real challenge for IP-based access controls. When employees work from home, coffee shops, or co-working spaces, their IP addresses change constantly. Enforcing strict IP whitelisting becomes impractical if it means locking out half your workforce every time their ISP rotates their address.

There are a few practical approaches to solving this without abandoning IP restrictions entirely.

VPN with static exit IPs. The most common solution. Employees connect to a corporate VPN, and all their traffic exits through a known IP range. That range gets whitelisted in Salesforce. The downside is that VPN adoption requires enforcement — if employees can bypass it, they will, and then the IP restriction is only protecting you from attackers who are not on the VPN either.

Zero Trust Network Access (ZTNA) tools. These replace traditional VPNs with identity-aware proxies that verify device posture, user identity, and context before granting access. Some ZTNA solutions can integrate with Salesforce session policies, creating a more dynamic access control model than static IP whitelisting alone.

Tiered IP restrictions by profile. Not every user needs the same level of restriction. Administrative profiles and users with access to financial or PII data can be locked to strict IP ranges, while standard sales or support users might operate under looser restrictions supplemented by MFA. This balances security with usability.

The right approach depends on the organization’s size, risk tolerance, and existing infrastructure. But doing nothing is a decision that carries measurable risk.

Session Security Settings That Complement IP Controls

IP whitelisting does not work in isolation. Salesforce offers several session-level security settings that should be configured alongside network restrictions:

Session timeout values. The default session timeout in Salesforce is two hours. For environments with sensitive data, shortening this to 30 or 60 minutes reduces the window during which an unattended session can be exploited. Users will need to re-authenticate more frequently, which is a minor inconvenience with a meaningful security payoff.

Lock sessions to the originating IP. When this setting is enabled, a session token becomes invalid if the user’s IP address changes mid-session. This defends against session-hijacking attacks in which a stolen session cookie is used from a different network. It can cause friction for users on unstable mobile connections, so it is best applied selectively to high-privilege profiles.

Require HttpOnly attribute. This prevents client-side scripts from accessing session cookies, which reduces the effectiveness of cross-site scripting (XSS) attacks against Salesforce. It is a simple setting with no real user-facing impact and should be enabled in every org.

Login flow enforcement. Salesforce allows administrators to create custom login flows that collect additional verification information during the authentication process. These can be configured to check device fingerprints, enforce security questions, or flag logins from unusual geographic regions based on IP geolocation data.

Monitoring and Responding to Access Anomalies

Configuring access controls is only half the equation. The other half is watching for signs that those controls are being tested or circumvented.

Salesforce provides several tools for this. The Login History page shows every authentication attempt, including the source IP, browser, and login status. Event Monitoring (available with the Salesforce Shield add-on) captures detailed audit logs covering data exports, report views, API calls, and permission changes.

Patterns worth investigating include repeated failed logins from unfamiliar IPs, successful logins from geographic regions where your organization has no employees, bulk data exports by users who do not normally pull reports, and API access spikes from connected applications.

Organizations that actively review these logs catch problems early. Those that do not tend to discover breaches months after the fact — often when a customer or regulator brings it to their attention.

Building Access Control Into the Foundation

The mistake most organizations make is treating access control as a settings page to fill out during setup and never revisit. In reality, access control in Salesforce is a living system that needs to adapt as the organization grows, as roles change, as new integrations are added, and as the threat environment shifts.

IP whitelisting, permission hierarchies, session policies, and monitoring are not separate tasks. They are interconnected components of a security posture that either work as a whole or fail at the weakest point. Getting them right requires planning, technical skill, and ongoing attention.

If your Salesforce environment has been running for more than a year without a dedicated access control review, the odds are good that permissions have drifted, IP restrictions are incomplete or missing, and session policies are still set to defaults. That is not unusual, but it is fixable, and the sooner it gets addressed, the smaller the window of exposure.