Somewhere in your org there is probably an integration user whose password sits in a script, a middleware setting or a vendor tool. Salesforce is retiring the OAuth 2.0 username-password flow that those integrations rely on, and it has set the date: 20 February 2027. This is a breaking change for any integration still using it, and the Salesforce username-password flow retirement is easy to miss because nothing fails until enforcement. This guide covers what Salesforce has announced, how to find the integrations that depend on the flow, and how to choose and test a replacement for each one.
It is a different change from the SOAP login() retirement, which we cover in debugging the SOAP login() retirement.
What Salesforce has announced
Salesforce’s Winter ’27 architect highlights state that the username-password, user-agent and hybrid user-agent flows are retired on 20 February 2027. Salesforce’s security requirement updates list the same date. Salesforce’s release update says enforcement was first planned for Winter ’27 and later moved, so older guides quoting an autumn 2026 date are out of date.
Several nearby changes affect the same integrations:
- Refresh tokens: the idle time-to-live is limited to 30 days, enforced from 21 October 2026 in sandboxes and 4 November 2026 in production. A token that is not used for 30 days stops working.
- Device flow: restricted to local external client apps from 30 November 2026.
- Connected apps: end of support in Summer ’27.
Plan the work around the whole list, not only the 20 February date.
Why these integrations get missed
Password-based integrations are usually old and quiet: a Data Loader script for a nightly load, a vendor tool connected years ago, an integration user who belongs to someone who left. Because the flow still works today, nobody opens the configuration. After enforcement, the job that ran every night simply starts failing when it asks for a token.
Audit checklist: find every dependent integration
Build one row per integration. For each, record:
- The caller: the system, script, middleware job or vendor tool that authenticates, and the team that owns it.
- The connected app: which app and client ID the caller uses.
- The identity: which Salesforce user it logs in as, and whether that user is a dedicated integration user.
- The work it does: objects touched, direction and rough volume.
- The route to change: whether you control the code or must wait for a vendor to update their tool.
Our practical sources for this inventory are the connected apps list, Login History for your integration users, the Release Updates page in Setup, and a search through scripts, pipelines and middleware configuration for password-based token requests. This is our suggested method, not a Salesforce procedure. Where a vendor owns the tool, ask in writing which flow it uses and when it will change.
Choose the right replacement for each integration
Salesforce’s migration guidance maps the common cases:
- Server-to-server, one identity: move to the client credentials flow. Enable the flow on the app, set a Run As user in each org, and update the client to request tokens the new way.
- One client, several usernames in the same org: client credentials will not fit. Salesforce recommends the JWT bearer flow.
- A person typing a username and password into the client: use a headed flow such as the web server flow.
Two details catch teams out. The client credentials flow does not support login.salesforce.com or test.salesforce.com, so the client must use the My Domain login URL, or the sandbox’s My Domain URL. And the Run As user needs a fresh look: it inherits whatever access the old integration user had, which is a good moment to remove access the integration never needed.
Because Salesforce says connected app support ends in Summer ’27, also ask whether the replacement should be built as an external client app rather than a connected app you will migrate again within months. Check Salesforce’s documentation for the flow you intend to use before you commit.
Test in a sandbox before you change production
Treat each switch as a small release. Configure the new flow in a sandbox, point a copy of the integration at the sandbox’s My Domain URL, and run it against realistic data. Confirm that it authenticates, can still read and write every object it needs, and reports a failed login somewhere a person will see it. Move one integration at a time, and keep the old route until the new one has run through a full business cycle. The same discipline applies to any cutover; our guide to planning a zero-downtime org cutover covers rehearsal, reconciliation and rollback.
How we help
Our data migration and integration team can run this audit with you: inventory the callers, map each to a supported flow, and test the changes in a sandbox before production. We make no assumption about any tool’s authentication, including our own, and confirm each one against its documentation. A certified Salesforce engineer reviews every change before it reaches production.
Frequently asked questions
When does Salesforce retire the username-password flow?
Salesforce states that the flow is retired on 20 February 2027.
What replaces the username-password flow?
For server-to-server integrations with a single identity, Salesforce’s guidance points to the client credentials flow. It recommends JWT bearer where a client uses several usernames, and a headed flow such as web server where people enter their own credentials.
Is this the same as the SOAP login() retirement?
No. The SOAP login() call and the OAuth username-password flow are separate retirements with their own dates, so audit for both.
Key takeaways
- Salesforce retires the username-password flow on 20 February 2027, and the date has already moved once.
- Inventory every caller, including scripts and vendor tools, and name an owner for each.
- Match each integration to client credentials, JWT bearer or a headed flow, then test it in a sandbox first.