Salesforce Integration Authentication: 3 Deadlines to Meet

Many Salesforce orgs still have at least one integration that signs in with a plain username and password: an ETL job, a backup tool, a middleware connector or an old script nobody remembers writing. Salesforce integration authentication is changing in three steps between now and Summer '27, and each step can silently break one of those connections. This guide explains what changes, who is affected, the deadlines, and the exact steps to migrate without a Monday-morning outage.

What is changing in Salesforce integration authentication

Salesforce is phasing out the two password-based ways that integrations have used for years to log in.

1. SOAP API login() now needs a specific permission (Winter '27). The developer documentation for the login() call explains that login() can be restricted to users holding the Use Any API Auth permission. When that restriction applies, a login() attempt by a user without the permission fails with an INSUFFICIENT_ACCESS error. The same page notes that login() is available up to API version 64.0 and is disabled by default in new orgs. With Winter '27, this check reached orgs instance by instance during the upgrade waves between late August and mid-October 2026.

2. The OAuth 2.0 username-password flow stops working for connected apps (February 20, 2027). The Salesforce release note Retirement of OAuth 2.0 Username-Password Flow for Connected Apps set this change for Winter '27, and enforcement was then postponed to February 20, 2027. Integrations that send grant_type=password to the token endpoint will be refused from that date.

3. SOAP login() is retired (Summer '27). The official SOAP API End-of-Life Policy schedules the retirement of login() for Summer '27. The same policy marks SOAP API versions 31.0 to 40.0 as deprecated and unsupported from Summer '27, with full retirement in Summer '28.

What does not change: SOAP data operations such as query, create, update and delete keep working. Only the password-based way of opening the session goes away.

Who is affected

The impact depends less on your Salesforce edition than on how your integrations were built.

• Admins: you own the inventory. Any integration user that relies on a password and lacks Use Any API Auth is already exposed since Winter '27.
• Integration and IT teams: custom scripts, Python or Java jobs and middleware flows that call login() or post a username and password to the OAuth token endpoint must be rewritten.
• Business owners of third-party tools: backup, data loading, BI, telephony or marketing tools may still use password login. Check each vendor's migration notes; several have already published them.
• Sales and service managers: you are not touching code, but you are the first to notice when leads stop syncing or a dashboard stops refreshing. Ask your admin for the inventory status now.

A detail that catches many teams: Use Any API Auth is a different permission from Use Any API Client. Granting the wrong one does not fix the error.

How to find password-based integrations in your org

You cannot migrate what you have not found. The goal is a list of every integration user, the system behind it, and the authentication method it uses.

1. Check Release Updates. In Setup, open Release Updates and look for the update about the retirement of the OAuth 2.0 username-password flow for connected apps. Read its test instructions for your org.
2. Filter Login History. In Setup, open Login History and create a view filtered on Login Subtype equals OAuth Username-Password. The Application column shows which connected app is involved. Repeat for SOAP API logins to spot login() callers.
3. Remember the history window. Login History keeps a limited period of data, so a job that runs only quarterly or yearly may not appear. Ask business owners about rare jobs such as year-end exports.
4. Do not rely on Connected Apps OAuth Usage alone. That page does not show integrations using the username-password flow, even active ones.
5. Search code and configurations. Look in middleware, scripts and repositories for grant_type=password, "password grant" or calls to login().
6. Test the switch-off in a sandbox. In Setup, under OAuth and OpenID Connect Settings, the option Allow OAuth Username-Password Flows can be disabled. Doing it in a sandbox first shows which integrations fail with an invalid_grant error before production does.

Which OAuth flow to use instead

Salesforce documents several replacement options in OAuth Authorization Flows. Choosing the right one is mostly a question of "who is the integration acting for?".

• Client credentials flow: best fit for server-to-server jobs and middleware. The app authenticates with a consumer key and secret and runs as a designated integration user, so no password is stored.
• JWT bearer flow: server-to-server as well, signed with a certificate uploaded to the app. Very robust, but you must plan certificate rotation.
• Web server flow with PKCE: for tools that act on behalf of a real person who signs in interactively.
• Named Credentials: for callouts from Salesforce, they keep endpoints and secrets out of Apex code.

Do not migrate to the username-password flow as a "quick fix" for the SOAP change: it has its own deadline in February 2027. Salesforce also positions External Client Apps as the successor to connected apps, so new integrations are a good moment to adopt them.

What to do now: a 6-step plan

1. Build the inventory this month. One line per integration: system, owner, integration user, current authentication method, criticality.
2. Fix Winter '27 exposures first. If a login()-based integration must keep running while you migrate, check whether its user needs Use Any API Auth and whether its license supports that permission.
3. Create least-privilege integration users. Each OAuth app should run as a dedicated user with a permission set limited to the objects and fields it needs, not as an administrator.
4. Migrate the critical flows before February 20, 2027. Start with integrations that move revenue data: lead capture, order sync, invoicing.
5. Retire login() before Summer '27. Replace remaining SOAP logins with OAuth, and upgrade any integration pinned to SOAP API versions 31.0 to 40.0.
6. Turn off the legacy option and monitor. Once everything is migrated, disable Allow OAuth Username-Password Flows in production and keep an eye on Login History for failed attempts.

Before and after, in short:

• Before: a shared admin account, a password stored in a script, a security token reset every time the password changes.
• After: one app per integration, OAuth tokens, a dedicated least-privilege user, and a clear owner for each connection.

This work is also a good security check. Our step-by-step guide on how to check your org for Salesforce attacks covers related reviews of connected apps and access, and our field guide to stopping CRM technical debt explains how to keep integrations documented once they are clean.

Conclusion

These are not optional updates you can postpone: each deadline turns a password-based integration into a failed sync. The good news is that the migration is well understood. Inventory, choose the right OAuth flow, test in a sandbox, then switch off the old option. If you want help mapping your integrations or rebuilding them on modern authentication, our CRM migration and integration team and our Salesforce Sales Cloud consultants can run the audit and the migration with your IT team.