SOAP API login() with a Broad IP Range Requires a Security Token

What is changing, and why

As part of our ongoing commitment to protect customer data with a secure-by-default posture, Salesforce is hardening the security of the legacy SOAP API login() call.

Today, under certain configurations, a SOAP login() can succeed with username and password alone, without the user’s security token acting as a second factor. The most common configuration for this is a broad range of login IP addresses, which can be configured a couple of ways.

Org level (Setup → Security → Network Access / Trusted IP Ranges), or
Individual user profile (Login IP Ranges).

A broad login IP range is one that exceeds the limit of 16,777,216 IPv4 addresses, a /8 prefix in CIDR notation, or 2^99 (2 to the power of 99) IPv6 addresses.

Effective December 15, 2026 for sandboxes and January 31, 2027 for production, Salesforce will require an API security token for SOAP login() whenever a broad login IP range is configured for the org or the user's profile. This closes the bypass and brings SOAP login() in line with our standard login-security expectations.

Are you affected?

You are likely affected if both of the following are true:

Broad login IP range configured — at the org level (Network Access) and/or on a user profile (Login IP Ranges).
Username and password only — the affected integration(s) authenticate without an API security token (and without mTLS).

How to identify SOAP login() in your org

In Setup search for and open Login History, look for entries with:

Login Type: "Other Apex API" or "Partner Product"
Login Subtype: "SOAP API"
API Type: "SOAP Enterprise," "SOAP Partner," or "SOAP Tooling"
Application: shows "N/A" (expected — a SOAP login() client is not bound to a connected/external client app)

Alternatively, use the API Total Usage event log: look for API_FAMILY = SOAP, API_RESOURCE = login, with an empty CONNECTED_APP_ID (an empty value indicates SOAP login(); a populated value indicates a connected app or external client app).

What happens if you take no action

After enforcement begins in December 2026, affected SOAP login() requests will require the API security token on orgs with a broad IP range. Requests that don’t include a security token will be blocked. The login will fail and the dependent integration will stop working.

The failed login returns a generic authentication error similar to:

"Invalid username, password, security token; or user locked out. Are you at a new location? When accessing Salesforce — either via a desktop client or the API — from outside of your company's trusted networks, you must add a security token to your password to log in. To get your new security token, log in to Salesforce. From your personal settings, enter Reset My Security Token in the Quick Find box, then select Reset My Security Token."

The blocked attempt is also recorded in your org's Login History with a security-token-required failure reason (result code 1502 / TOKEN_REQUIRED), which remains available for troubleshooting even where the code is not surfaced in the API response.

Our recommendation (strongly recommended): migrate to external client apps and OAuth now

SOAP login() is on a phased retirement that ends with full retirement of API versions 31.0–64.0 in Summer '27. A security-token workaround applied now is temporary. You’ll need to migrate to a modern flow before Summer '27 regardless.

To avoid doing the work twice, we strongly recommend moving directly to the long-term secure solution: external client apps (ECA) with OAuth 2.0. This is the durable, most-secure path and it satisfies both the December 2026 security requirement and the Summer '27 retirement in a single migration.

Pick the right OAuth flow for your use case

Your SOAP login() use case	Recommended OAuth 2.0 replacement
Unattended batch / ETL / middleware / CLI / scheduled jobs (headless), running as a dedicated integration user	JWT Bearer and dedicated API Integration User most secure for system integrations
Pure service-to-service, single system identity, in-org only	Client Credentials (run-as user) — JWT Bearer preferred where feasible
Interactive tool where a user logs in once (e.g., Data Loader)	Web Server flow and PKCE
Log in interactively once, then run long-lived headless	Web Server → Refresh Token (with rotation)
First-party personal API access / power-user scripting (ad-hoc scripts, simple-salesforce)	New user JWT bearer flow and Local ECA rolling out ahead of retirement

Alternative action (bridge only and expires at Summer '27 retirement)

If you can’t migrate to OAuth before December 2026, you can keep existing SOAP login() integrations working by doing one of the following. Note that these are temporary measures only. SOAP login() still retires in Summer '27, so you must complete the ECA and OAuth migration before then.

Add the API security token to your SOAP login() request. Append the user's security token to the end of the password in the login call. Reset/obtain a token from Personal Settings → Quick Find → "Reset My Security Token" → Reset My Security Token (the token is emailed to the user).
Tighten the login IP range so it is no longer broad — use a scoped, specific range at the org or profile level. This can be done via configuration alone, with no client/code change.

Timeline

Two separate changes — please plan for both:

When	Change	What it means for you
October 2026	Release Update available (test-run mode)	Validate the change against your integrations before enforcement.
December 2026	Security-token enforcement begins for SOAP login() on orgs/profiles with a broad login IP range	Affected logins without a security token are blocked. Rollout is gradual: new orgs and sandboxes first, then production; lower-risk org types before active paid production; staged over multiple weeks with advance notice.
Summer '27 (API v31.0–64.0)	Full retirement of SOAP login()	SOAP login() stops working entirely in these API versions. All integrations must be on ECA and OAuth by this date.

What you need to do now

Test with the Release Update first. In Setup → Release Updates, find the "SOAP API login() Security Remediation" update → View Update → Enable Test Run. This simulates enforcement (returning the same response as real enforcement) so you can spot breakage safely. Disable Test Run to revert. Do this in a sandbox or non-production org first.
Review Login History to identify every integration and integration user that uses SOAP login(), including those behind third-party/ISV apps or middleware.
Choose your path:
- Recommended: migrate the integration to Local ECA and OAuth. This covers both December 2026 and Summer '27 in one step.
- Bridge only: apply a temporary workaround if you cannot migrate in time, then plan the OAuth migration before Summer '27.
For third-party/ISV apps: confirm the app supports OAuth (or a security token), and coordinate the update with the vendor.
If you need more time: submit an exception request before enforcement reaches your org to avoid an interruption.