Short answer: Salesforce adds two SOAP API login() checks, from 15 December 2026 in sandboxes and 31 January 2027 in production. First, a login from a broad login IP range must include the user's security token (or use mTLS). If it doesn't, the login fails and Login History records 1502 / TOKEN_REQUIRED. Second, a one-time check turns off SOAP login() in any org that had no SOAP login() activity in the previous 6 months. (Source: Salesforce Help KA 005132110.)
The 6-month check isn't a rolling window. Salesforce calls it "a one-time check during the rollout, not an ongoing sliding window." One SOAP login() call by any user in the org during the 6 months before the check keeps SOAP login() on for the whole org.
What changes
1. Security token required from broad IP ranges. As a general rule, Salesforce doesn't ask for a security token on an API login that comes from an IP address in the org's trusted IP ranges (Network Access) or inside the user profile's login IP ranges. Salesforce's SOAP API Developer Guide explains how that check works. The new rule changes this when the range is broad: from that IP range, SOAP login() needs the token anyway.
KA 005132110 defines broad as larger than /8 for IPv4 (16,777,216 addresses) or larger than /29 for IPv6. The range can be set for the whole org (Network Access) or on a profile (Login IP Ranges). With a broad range, a username and password alone fail with TOKEN_REQUIRED, which Login History records as result code 1502. The related Release Update is SOAP API login() Security Remediation.
For example, a profile login IP range of 0.0.0.0 to 255.255.255.255 covers the whole IPv4 address space, which is far wider than a /8.
2. One-time inactivity check. At rollout, Salesforce turns off SOAP login() in orgs that had no SOAP login() activity in the previous 6 months. Salesforce's summary table says this covers production orgs and their sandboxes. In new orgs, SOAP login() is off if it was never used. Once it's off, SOAP login() calls fail.
Who's affected
- Integrations that log in with only a username and password as a user covered by a broad IP range. Check integration-user profiles in particular, because a wide login IP range is one way to avoid handling a security token.
- Orgs where only rare jobs use SOAP
login(). Salesforce names annual, seasonal and disaster-recovery jobs as the risk. If nothing in the org called SOAPlogin()in the 6 months before the check, those jobs fail the next time they run.
The inactivity check won't switch off an org with regular SOAP login() traffic. Those orgs still face three other changes: the 1 December 2026 Use Any API Auth requirement, the token rule above and the Summer '27 retirement.
How to check your org
Find SOAP login() callers. In Setup → Login History, look for:
- Login Type Other Apex API or Partner Product
- Login Subtype SOAP API
- API Type SOAP Enterprise, SOAP Partner or SOAP Tooling
For these rows the Application column shows N/A. Salesforce says that's intentional and no data is missing. Use the Username to trace each integration.
The API Total Usage EventLogFile can add detail: look for API_FAMILY = SOAP and API_RESOURCE = login. Salesforce's SOAP login() article (KA 005132110) says all users can see the past 24 hours of this log. With Event Monitoring the window is longer (KA 005132110 says 30 days, extendable to 1 year).
Check for broad IP ranges. For each integration username, check two places: its profile's Login IP Ranges and the org's Network Access trusted ranges. Note any range wider than /8 (IPv4) or /29 (IPv6).
Check whether you'd pass the inactivity check. Login History might show no SOAP login() entries for the past 6 months. If so, ask integration owners and vendors about anything that runs once a year, once a season or only during a disaster-recovery test.
Test. Salesforce points to the SOAP API login() Security Remediation Release Update, which it lists with an October 2026 test run, for testing the token rule. This card may not be listed in every org. If you can't find it, check for broad ranges directly in Network Access and in each profile's Login IP Ranges (KA 005132110).
To pull SOAP login() entries with user, source IP and API version into a CSV, the Connected App Retirement Kit includes a read-only discovery script (query D07), and its inventory workbook records each integration's current auth method, target method and deadline.
What to do
KA 005132110 gives three options for the token rule and puts migration first:
- Preferred: move the integration to an external client app and OAuth. For server-to-server or headless jobs, Salesforce recommends the JWT bearer flow or the client credentials flow. For browser-based or user-driven integrations, it recommends the web server flow.
- Interim: append the user's security token to the password. Users get a new token with Reset My Security Token. Salesforce also accepts mTLS (a mutual authentication certificate) in place of the token.
- Interim: narrow the IP range so it's no longer broad.
For the inactivity check, find any rarely run integration that still needs SOAP login(). Migrate it to an external client app and OAuth before the check. Salesforce's table also mentions keeping a live SOAP login() if you must retain the method until Summer '27 (KA 005132110). We don't recommend relying on that: SOAP login() in API 31.0–64.0 is retired in Summer '27 anyway, so it only delays the migration.
Timeline
| Date | SOAP login() change | Source |
|---|---|---|
| 1 Dec 2026 | Use Any API Auth permission required in all orgs | KA 005132110 |
| 15 Dec 2026 | Sandboxes: token required from broad IP ranges; one-time 6-month inactivity check | KA 005132110 |
| 31 Jan 2027 | Production: the same two changes | KA 005132110 |
| Summer '27 | SOAP login() retired in API 31.0–64.0 (already unavailable in 65.0+) |
KA 005132110 |
FAQ
What does TOKEN_REQUIRED / 1502 mean for SOAP login()?
Under the new rule, it means a user logged in from a broad login IP range without a security token. Fix it by appending the token to the password, using mTLS, narrowing the range or moving to OAuth.
What counts as a "broad" login IP range?
For IPv4, anything larger than /8 (16,777,216 addresses). For IPv6, anything larger than /29. It can be set at the org (Network Access) or on a profile (Login IP Ranges).
Is the 6-month inactivity check a rolling window?
No. KA 005132110 calls it "a one-time check during the rollout, not an ongoing sliding window."
Does one SOAP login() call keep it on for the whole org?
Yes. One call by any user in the 6 months before the check keeps SOAP login() on for the org. Salesforce's table also mentions keeping a live SOAP login() if you must retain the method until Summer '27 (KA 005132110). We don't recommend relying on that: SOAP login() in API 31.0–64.0 is retired in Summer '27 anyway, so it only delays the migration.
Our disaster-recovery job only runs once a year. What should we do?
Migrate it to an external client app and OAuth before the check: 15 December 2026 for sandboxes and 31 January 2027 for production. Salesforce specifically warns that annual, seasonal and DR jobs can look inactive and then fail.
Sources
- KA 005132110, Platform SOAP API login() Retirement & new Security Requirements (publish date Oct 19, 2026; updated Oct 9, 2026)
- SOAP API Developer Guide: Security and the API (general security-token and IP-range behaviour)
Last checked: 29 October 2026, against the Salesforce pages above. If a Salesforce page and this article disagree, go by the Salesforce page.
Want to find every SOAP login() user in one pass? The free 15-Minute Integration Auth Risk Check includes the Login History check, and there's no sign-up. It's also in the sfauthdeadline.com checklist section. To move those integrations to OAuth, the Connected App Retirement Kit has the SOAP discovery query, a flow decision tree and migration runbooks for middleware and scripts, plus a SOAP login() runbook.
sfauthdeadline.com is an independent resource. It is not affiliated with, endorsed by or sponsored by Salesforce. Salesforce is a trademark of Salesforce, Inc.