An integration that works today can stop working a year from now without anyone changing a thing. Salesforce is pulling the plug on the OAuth 2.0 username-password flow for connected apps: an integration that authenticates with grant_type=password will no longer receive an access token. No warning appears in the interface. That hits exactly the kind of integration we see every day, between Salesforce and an accounting or ERP package.

What changes, and when

Salesforce enforces this release update on 20 February 2027. That date was revised: enforcement was originally set to arrive with the Winter ’27 release, but Salesforce has decoupled it from your org’s release weekend. So you have one fixed date to work towards, rather than a date that differs per org.

Two things already apply today:

  • In orgs created in Summer ’26 and later, the flow cannot be used at all.
  • On the OAuth and OpenID Connect Settings page, the option to allow OAuth username-password flows is disabled and greyed out.

A second track affects the same integrations. The SOAP API login() call in API versions 31.0 through 64.0 retires with the Summer ’27 release, and it does not exist at all in version 65.0 and later. In orgs created from Winter ’26 onwards it is off by default. Where it is still switched on, a user needs the Use Any API Auth permission to authenticate; without it, the request comes back with an INSUFFICIENT_ACCESS error.

How to find out which integrations this affects

You do not have to guess at this. In Setup, go to Login History and create your own list view with Login Subtype as a filter. That field shows, per login, which OAuth flow a connected app came in on, the username-password flow included. The page holds six months of logins and can be downloaded as a CSV, so a single pass tells you whether any traffic still runs on the old flow.

For the SOAP side, look in that same Login History for entries with:

  • Login Type “Other Apex API” or “Partner Product”;
  • Login Subtype “SOAP API”;
  • API Type “SOAP Enterprise”, “SOAP Partner” or “SOAP Tooling”.

If such an entry shows “N/A” in the Application field, no data is missing. That is precisely the sign that the client is not bound to a connected app, and so belongs to the group that has to migrate. The Username field tells you which service account is involved, and from there which application sits behind it. To look deeper, the API Total Usage EventLogFile gives you the matching API calls: the past 24 hours by default, and thirty days with Event Monitoring.

Where to migrate to

Salesforce points to two routes. For server-to-server integrations, which covers most connections to an accounting package, that is the OAuth 2.0 client credentials flow. If the integration runs on behalf of a logged-in user, the web server flow with the PKCE extension is the way to go. Replacing a SOAP login() call gives you the JWT bearer flow as an option alongside client credentials.

If you built the integration yourself, this is your job. If it came from a vendor, ask now which version supports the new flows, rather than in February 2027. For how these integrations are put together, see our piece on the Salesforce API and custom integrations and our overview of Salesforce connectors.

Would you like a review of which of your integrations still run on the old authentication, and what migrating them takes? Our consultancy works through your connected apps and service accounts and records what has to change before 20 February 2027. Get in touch and we will schedule it.