Short answer: From 1 December 2026, a SOAP API login() call succeeds only if the user logging in has the Use Any API Auth user permission. Without it, Salesforce rejects the login with an INSUFFICIENT_ACCESS error. The rule is already the default in new orgs and is enforced in all orgs and environments on 1 December. The short-term fix is to assign the permission, through a permission set or profile, to every user an integration logs in as with SOAP login(). (Source: Salesforce Help KA 005132110.)
This is the first of several upcoming SOAP login() changes. The longer-term fix is to move those integrations to external client apps and OAuth before SOAP login() is retired in API versions 31.0–64.0 with the Summer '27 release.
What changes
KA 005132110 lists the change as: "SOAP login() succeeds only if the user has Use Any API Auth user permission assigned. Without it, the request fails." The matching Release Update in Setup is Assign Use Any API Auth Permission for SOAP login().
This only affects the login step: an integration that sends a username and password (plus a security token, where needed) to the SOAP endpoint and gets a session ID back. For the wider retirement, Salesforce defines the scope as login() calls to /services/Soap/c/ (Enterprise WSDL) and /services/Soap/u/ (Partner WSDL) in API versions 31.0–64.0. According to the KA, the Setup page for downloading WSDLs isn't in scope.
Who's affected
Any code, package, middleware or ETL tool that authenticates with SOAP login() as a user who doesn't have Use Any API Auth. Typical examples are older data loaders, sync tools and scripts built on the Partner or Enterprise WSDL. Salesforce also lists two of its own features that use SOAP login(): the Salesforce Connect Cross-Org Adapter and the CRMA Connector. Salesforce says its product teams are aware, and that the CRMA Connector will be moved off SOAP login() before the retirement.
This permission check is about SOAP login(). Integrations that already authenticate with OAuth through a connected app or external client app don't call login(), so it doesn't apply to them (other OAuth dates on the timeline may).
If you received Salesforce's email titled "ACTION REQUIRED: Update Unsupported Platform SOAP API login()", Salesforce detected SOAP login() use in your org during the period named in the email.
How to check your org
1. Find SOAP login() callers in Login History. KA 005132110 says to look for entries with:
- Login Type Other Apex API or Partner Product, and
- Login Subtype SOAP API, and
- API Type SOAP Enterprise, SOAP Partner or SOAP Tooling.
The Application column will show N/A. Salesforce says that's expected because these clients aren't tied to an app. Note the Username on each row instead, since that's the user who needs the permission (and the person to ask what the integration is).
2. Cross-check with API Total Usage logs (optional). In the ApiTotalUsage EventLogFile, rows with API_FAMILY = SOAP and API_RESOURCE = login are SOAP login() calls. An empty CONNECTED_APP_ID means the call authenticated with SOAP login() or a session. Every org gets 24 hours of this log; Event Monitoring extends it.
3. Check each username for the permission. For every user from step 1, confirm Use Any API Auth is granted through a permission set or the profile. Salesforce suggests using Setup with Agentforce to find active, API-enabled users who don't have the permission.
4. Ask about rare jobs. Login History only shows what has run recently. Ask integration owners and vendors about annual, seasonal or disaster-recovery jobs.
What to do
Before 1 December:
- Assign Use Any API Auth through a permission set to each integration user that needs SOAP
login(), and only to those users. - Test in a sandbox using the Release Update, then confirm in production.
- After 1 December, an
INSUFFICIENT_ACCESSerror on a SOAP login most likely means a user was missed.
Before Summer '27 (the real fix):
- Move custom integrations to external client apps and OAuth. For server-to-server or headless jobs, Salesforce recommends the JWT bearer or client credentials flow. For browser-based or user-driven integrations, it recommends the web server flow.
- Ask third-party vendors for a version that supports external client apps and OAuth.
- Once integrations are migrated, use the SOAP API login() retirement Release Update's Enable Test Run in a sandbox. It blocks all SOAP
login()calls so you can see what still depends on it. Don't run it in production unless you're ready, because it blocks every SOAP login for as long as it's on.
Timeline
| Date | SOAP login() change | Source |
|---|---|---|
| Already in effect | SOAP login() not available in API 65.0+; disabled by default in orgs created from Winter '26 onward |
KA 005132110 |
| 1 Dec 2026 | Use Any API Auth required in all orgs/environments | KA 005132110 |
| 15 Dec 2026 (sandbox) / 31 Jan 2027 (production) | Security token (or mTLS) required for logins from a broad IP range (error 1502 / TOKEN_REQUIRED). One-time check disables SOAP login() in orgs with no SOAP login activity in the past 6 months |
KA 005132110 |
| Summer '27 | SOAP login() retired in API 31.0–64.0 |
KA 005132110 |
FAQ
What does INSUFFICIENT_ACCESS on SOAP login() mean after 1 December 2026?
Most likely the user logging in doesn't have the Use Any API Auth permission. Assign it through a permission set or profile, then try again.
Is assigning Use Any API Auth a permanent fix?
No. It keeps SOAP login() working while the method is still supported. The 15 December 2026 / 31 January 2027 security checks can still stop it, and SOAP login() is retired in API 31.0–64.0 with Summer '27, so integrations need to move to external client apps and OAuth.
Does this affect OAuth integrations?
This permission check applies to SOAP login(). Integrations that authenticate through a connected app or external client app with OAuth don't use SOAP login().
Why does Login History show "N/A" for the application?
SOAP login() clients aren't tied to a connected app or external client app. Salesforce says that's intentional, not missing data. Use the Username column to trace the integration.
What other SOAP login() dates are coming?
On 15 December 2026 in sandboxes and 31 January 2027 in production, logins from broad IP ranges need a security token (or mTLS), and a one-time check turns off SOAP login() in orgs with no use in the past six months.
Sources
- KA 005132110, Platform SOAP API login() Retirement & new Security Requirements (publish date Oct 19, 2026; page also says "Updated - October 9, 2026")
- KA 005461287, Connected App & External Client App Security Requirement Updates (Oct 14, 2026), for the related OAuth dates
Last checked: 29 October 2026, against the Salesforce Help pages above. If Salesforce's page and this article ever disagree, Salesforce's page is correct.
Need a list of every SOAP login() user in your org? Check 3 of the free 15-Minute Integration Auth Risk Check walks through it, with no sign-up. It's also on the sfauthdeadline.com checklist section. When you're ready to move those integrations to OAuth, the Connected App Retirement Kit includes a flow decision tree and migration runbooks.
sfauthdeadline.com is an independent resource. It is not affiliated with, endorsed by or sponsored by Salesforce. Salesforce is a trademark of Salesforce, Inc.