The situation
An integration that has authenticated the same way for years suddenly cannot log in:
- A scheduled ETL job fails overnight with an authentication error instead of pulling data
- A vendor connector that uses a username, password, and security token reports that login was rejected
- A Data Loader command-line automation exits with a login failure
- The same credentials still work when a person logs in through the browser, so the account is not locked
- The failure appears in a newly created org, or shortly after someone opted the org into a new enforcement
Nothing about the credentials changed. What changed is how Salesforce treats the SOAP login() authentication call those integrations rely on.
Root cause
The integrations are authenticating with the SOAP API login() call — the legacy username-password-and-token mechanism that older tooling uses to obtain a session. Salesforce is retiring this call, and Summer ‘26 introduces the first enforcement lever.
The timeline matters because the wording in release notes is easy to misread:
- The SOAP
login()call in API versions 31.0 through 64.0 is scheduled for full retirement in Summer ‘27, not Summer ‘26 - It has already been removed from API version 65.0 and later, and is disabled by default in newly created orgs
- Summer ‘26 adds the enforcement gate: in new orgs where an administrator has enabled SOAP
login(), the authenticating user now needs a new Use API Auth permission, or the login call is rejected. Existing orgs can opt into this enforcement ahead of the retirement
So a failure today most commonly means one of two things: the integration is running against a new org where the user lacks the Use API Auth permission, or the org has been opted into the enforcement early. Either way, the underlying problem is the same — the integration depends on a login mechanism that is on its way out, and Summer ‘26 is the point where that dependency starts to bite.
The places SOAP login() hides are predictable and easy to overlook: scheduled ETL jobs, older Java or .NET services, Data Loader automations, vendor connectors, deployment scripts, and the “temporary” script that quietly became permanent because it worked.
Diagnosis
Identify every integration using SOAP login()
Inventory anything that authenticates with a username, password, and security token rather than OAuth. The candidates are scheduled jobs, middleware connections, Data Loader batch processes, and any custom service holding stored Salesforce credentials. If an integration stores a password and security token, it is almost certainly using SOAP login().
Run the test run in Setup
Salesforce provides a test run in Setup that surfaces integrations still depending on the retiring login behaviour. Use it to produce a concrete list of impacted callers rather than guessing — it identifies affected integrations early, before enforcement forces the issue.
Check the integration user’s permissions
For a failure in a new org, check whether the integration user has been assigned the Use API Auth permission. Its absence is the proximate cause of the rejection in Summer ‘26 new orgs where SOAP login() is enabled.
Check the API version of the login call
If the integration calls version 65.0 or later, SOAP login() is already gone there regardless of org settings. Confirm which API version each integration’s login endpoint targets.
Resolution
There is a short-term unblock and a real fix. Do the short-term one only to buy time; the real fix is the one that survives the Summer ‘27 retirement.
Fix 1 — Short-term unblock (new orgs only)
If an integration is failing in a new org purely because the user lacks the permission, assign the Use API Auth permission to the integration user to restore authentication. This keeps the integration running but does nothing about the underlying retirement — it is a stopgap, not a solution.
Fix 2 — The real fix: migrate to OAuth 2.0 via External Client Apps
Move each integration off SOAP login() and onto OAuth 2.0, configured through an External Client App. The appropriate OAuth flow depends on the integration:
- Server-to-server integrations with no interactive user → OAuth 2.0 JWT bearer flow, using a connected certificate rather than a stored password
- Integrations acting on behalf of a specific user → OAuth 2.0 web server or refresh token flow
This replaces the stored password and security token with token-based authentication that is not subject to the SOAP login() retirement.
Fix 3 — Update each integration and retire stored credentials
For each integration, reconfigure its authentication to use the OAuth client credentials and the appropriate flow, then remove the stored Salesforce password and security token once OAuth is confirmed working. Data Loader, most modern ETL tools, and current vendor connectors all support OAuth — the work is configuration, not redevelopment, in the large majority of cases.
Fix 4 — Schedule against the Summer ‘27 deadline
Treat Summer ‘27 as a hard deadline for any integration still on API versions 31.0 through 64.0 using SOAP login(). After retirement, those calls receive an error indicating the endpoint has been deactivated, with no per-org override available.
Verification
| Check | Expected |
|---|---|
| Integration inventory | Every SOAP login() caller identified and tracked |
| Setup test run | No unresolved integrations flagged |
| Authentication method | Each integration authenticates via OAuth 2.0, not username/password/token |
| Stored credentials | Passwords and security tokens removed once OAuth is confirmed |
| Sandbox test | Each migrated integration authenticates and runs end to end |
Once every integration authenticates through OAuth and no stored passwords remain, the org is insulated from both the Summer ‘26 enforcement and the Summer ‘27 retirement. The Use API Auth permission stopgap can then be removed, since nothing depends on SOAP login() any longer.