Salesforce Is Retiring the OAuth Username-Password Flow: What It Means for Every AI Tool Connected to Your Org
Salesforce has set February 20, 2027 as the enforcement date for retiring the OAuth 2.0 username-password flow for connected apps, and integrations that still use it will stop receiving access tokens.
ConvoPro Team
Salesforce Advisors
Featured
Salesforce Is Retiring the OAuth Username-Password Flow: What It Means for Every AI Tool Connected to Your Org
Most Salesforce teams learn about this the same way. A security email gets forwarded. Someone opens Setup. And then nobody in the room can say with confidence how many integrations are still authenticating with a username, a password, and a security token.
That question now has a date attached to it.
The change, stated plainly
Salesforce is retiring the OAuth 2.0 username-password flow for connected apps. In the release update, Salesforce is direct about the reasoning: the flow passes user credentials in HTTP requests, which presents security risks. Any connected app integration still using the flow stops working once the update is enforced.
The timing moved once. The retirement was first announced in Spring '26 and originally scheduled to enforce with the Winter '27 major release. Salesforce changed the enforcement date to February 20, 2027. That is a stated calendar date rather than a date tied to your instance's release upgrade weekend, which removes a common source of confusion during release planning.
There is a second detail worth noting. Orgs created in Summer '26 and later already have this flow blocked. On the OAuth and OpenID Connect Settings page, the option to allow the username-password flow is disabled and greyed out. If you cannot find the release update in your own Setup, the flow is already blocked in your org and this change does not apply to you.
So the work is concentrated in one place: established orgs carrying integrations that were wired up years ago, by people who may no longer work there.
Why this lands differently in 2026
A credential retirement in 2022 would have touched a data loader, a middleware sync, and maybe a reporting script. In 2026 the surface is wider.
Salesforce orgs are now connected to AI assistants, agent platforms, document processing tools, MCP servers, model APIs, vendor apps, and internal scripts that someone stood up during an AI pilot. Each of those connections needed a way in. Many of them got one quickly, because the point of a pilot is to prove something fast.
The result is a familiar pattern. The number of systems authenticating into Salesforce has grown considerably. The inventory of those systems, and the record of who approved each one and what it is permitted to do, usually has not grown at the same rate.
This retirement is a forcing function. It gives admins and IT leaders a legitimate reason to build that inventory now, on a schedule they control, rather than after an incident.
It also arrives alongside a broader tightening. Salesforce has been moving a set of security controls from recommended to enforced through 2026, including multi-factor authentication for employee users and phishing-resistant MFA for administrators and other privileged users. The current scope and dates are maintained in Salesforce's security requirements documentation, which is worth reading in full rather than through summaries.
How teams usually connect systems to Salesforce today
Three patterns cover most of what admins find when they go looking.
The first is credentials stored in a middleware configuration screen. A username, a password, and a security token sit in a connection profile inside an integration platform, and a scheduled job uses them every few minutes. It works, it has worked for years, and nobody has had a reason to touch it.
The second is a shared integration user that is quietly a system administrator. It was set up that way to unblock a deadline, with the intention of tightening permissions later. The tightening did not happen.
The third is a script. It runs on a server, it posts credentials to the token endpoint, and its author has moved on. There is no documentation, and the business process it supports is still running.
None of these are unusual, and none of them reflect badly on the team that built them. They reflect how integration work accumulates when the pressure is to deliver.
Where these approaches break
The failure mode here is the part worth planning for, because it is quiet.
When enforcement lands, an affected integration does not display a banner in Setup and does not send an alert. It requests a token, receives an authentication error, and stops. Where that error surfaces depends entirely on how the middleware was written. In a well-instrumented integration, it lands in a log that someone monitors. In the more common case, it lands in a nightly job that processes zero records, and the first sign of trouble is a report that looks short several days later.
There is a second, less discussed break. A credential set that works for one integration typically works for everything that user can see. When the same integration user is shared across three tools, a permission granted for one purpose silently extends to the other two. Retiring the flow does not fix that on its own, but the migration is the natural moment to fix it.
How to find your exposure
This is a genuine sequence, so work through it in order.
In Setup, open Login History and filter by the OAuth password login type. Export the results.
Group the export by application and by user. That grouping is your first draft inventory.
In Setup, review Connected Apps OAuth Usage to see which apps hold active tokens and which have gone dormant.
Open the Release Updates node in Setup and locate the username-password flow retirement. Treat the date shown there as your source of truth, because Salesforce postpones, narrows, and occasionally cancels release updates, and your Setup reflects the current state for your org.
For every application on the list, record an owner, the business process it supports, the Salesforce objects it touches, and whether it reads, writes, or both.
One caveat on step one. Login History retains a limited window, so an integration that runs quarterly or annually can be absent from the export entirely. Cross-check against your finance calendar, your data warehouse jobs, and any vendor contracts that mention a Salesforce connection.
Apps with active tokens and no identifiable owner deserve attention beyond this migration. That is not a scheduling problem, it is a security finding.
Choosing the replacement flow
Salesforce names two replacements in the release update, and the right one depends on whether a person is involved.
Connection type | Recommended flow | What changes in practice |
|---|---|---|
Server-to-server work with no signed-in person, such as a nightly sync, a middleware job, or a backend service | OAuth 2.0 client credentials flow | The app authenticates as a designated integration user. No end-user password is stored or transmitted. |
A tool acting on behalf of a signed-in person, such as an assistant used inside a browser session | OAuth 2.0 web server flow with the Proof Key for Code Exchange extension | The person authenticates with Salesforce directly, and the tool receives a token tied to that authorization. |
A vendor application you did not build | Determined by the vendor | Contact the vendor and request their migration timeline in writing before February 20, 2027. |
A certificate-based JWT bearer flow is another server-to-server option many teams use, and it removes the stored secret entirely in exchange for certificate lifecycle management. Salesforce's release update names the web server and client credentials flows specifically, so treat JWT bearer as an architectural choice to discuss with whoever owns identity in your organization rather than a default.
Two practical notes. Provision a dedicated integration user with a least-privilege permission set rather than reusing an administrator profile, since the migration is the cheapest moment you will ever get to scope permissions correctly. And do not decommission the old connection until the new one has run end to end in a sandbox, including its error paths.
Separately, Salesforce is moving from connected apps to external client apps, and provides a documented migration path between them. If you are already opening these integrations to change the auth flow, it is worth understanding how the two efforts relate before you plan the work twice.
Authentication answers only half the governance question
Here is the part that outlasts this particular deadline.
Choosing a supported OAuth flow answers one question: can this system connect. It does not answer the questions that actually determine risk once an AI tool is in the loop. What is this connection allowed to do. On whose behalf is it acting. Which records can it change. What happens between the model producing an output and that output becoming a Salesforce record. And can someone reconstruct, afterwards, why a given record changed.
Governance frameworks make the same distinction. The NIST AI Risk Management Framework treats mapping context, measuring behaviour, and managing risk as ongoing functions, not as a configuration step completed at connection time.
A useful review, applied to every AI tool that touches your org, covers five things.
Identity
Determine whether the connection acts as a specific integration user or in a signed-in person's session. Both are legitimate. Confusing the two is where accountability disappears, because an action taken by a shared integration user cannot be traced to a person.
Permission scope
Confirm that the profile or permission set backing the connection grants access to the objects and fields the workflow needs, and nothing more. If a summarisation tool can update opportunity amounts, that is a scope problem, not an AI problem.
Action scope
Distinguish reading from writing. Many valuable AI workflows never need write access at all. For the ones that do, the write should be narrow and named, not general.
Review point
Decide, per workflow, whether a person approves before the record is created or updated. Review-before-create is the difference between AI proposing a case and AI creating one unsupervised. That decision belongs to an admin, in configuration, not to whoever is using the tool that day.
Traceability
Establish what is recorded when an action happens, and confirm someone reviews it on a cadence. An audit trail nobody reads is a compliance artifact rather than a control.
Where ConvoPro fits
ConvoPro is a practical AI workflow layer for Salesforce. Salesforce remains the system of record, and ConvoPro adds the workflow and action layer on top of it.
The relevance to this migration is the governance model rather than the authentication mechanism. Admins control which connectors are enabled, which tools are available, which actions are permitted, which authentication modes are used, and which workflows are exposed to which users. ConvoPro Automate supports a configurable integration-user pattern for external intake, which keeps submissions from outside your org flowing through one governed path rather than through whatever credential a project team happened to have. You can read more on the ConvoPro product page, and specific authentication, permission, and retention questions should be confirmed directly through the ConvoPro security overview before production use.
This is also worth saying plainly. ConvoPro is not a replacement for Salesforce Flow, Experience Cloud, Agentforce, or Data 360, and it does not remove the migration work described above. If your process is fully inside Salesforce, stable, and transactional, Flow is the right home for it. If you need a full authenticated portal with an entitlement model, Experience Cloud is the right answer. If your organization is ready to build, deploy, and orchestrate agents at scale, Agentforce is built for that. ConvoPro is useful in the narrower case where work starts outside Salesforce, arrives messy, needs review before anything is written, and must end in clean Salesforce data.
A worked example
Consider a field service team taking in equipment issues from customer sites.
Today, a technician emails a description and two photos to a shared mailbox. A coordinator reads the email, opens Salesforce, creates a case, retypes the asset details, attaches the photos, and picks a queue. The step happens forty times a week and produces inconsistent records, because free text does not map itself to required fields.
In a governed workflow, the technician scans a QR code that opens a structured form carrying asset context. Photos and notes upload with the submission. The messy input is mapped into the fields the case actually requires. The coordinator sees the proposed case with the mapping already done, corrects anything wrong, and approves. Only then is the record created in Salesforce, through an approved authentication path with a scoped permission set.
The AI work happens in the mapping step. The governance happens in the approval step. The authentication decision determines what that connection could ever do if something went wrong. All three matter, and this migration is a good reason to make all three explicit.
What to do in the next thirty days
Build the integration inventory described above and assign an owner to every entry.
Confirm your org's enforcement date in the Release Updates node in Setup rather than relying on any summary, including this one.
Email every third-party vendor with an active connection and ask, in writing, which flow their integration uses and when they will migrate.
Pick the replacement flow for each internally built integration, provision least-privilege integration users, and test in a sandbox including failure paths.
While each integration is open, review its permission scope, its action scope, and whether a human review step should exist where one currently does not.
If step five surfaces AI tools writing to Salesforce with no review point in front of them, that is the finding worth taking to your leadership team. The February date is a deadline. The review gap is the actual risk.
Frequently asked questions
Does this retirement affect my org if it was created recently? Probably not. Salesforce blocks the username-password flow in orgs created in Summer '26 and later, and the option is disabled on the OAuth and OpenID Connect Settings page. If the release update does not appear in your Setup, the flow is already blocked for you.
Was this enforced with Winter '27? No. It was originally scheduled to enforce with the Winter '27 major release, and Salesforce changed the enforcement date to February 20, 2027. Because release updates can be postponed, narrowed, or cancelled, confirm the current date in the Release Updates node in your own Setup before planning the migration.
What actually happens on the enforcement date? Connected app integrations still using the flow stop receiving access tokens and fail to authenticate. There is no banner in the interface, so where the failure becomes visible depends on how each integration handles errors. Jobs that fail quietly are the ones to identify first.
Which flow should we move to? For server-to-server integrations with no signed-in person, Salesforce points to the OAuth 2.0 client credentials flow. For end-user login and authorization, it points to the OAuth 2.0 web server flow with the PKCE extension. For applications built by a vendor, the vendor owns the migration and should be able to state their timeline.
How do we find every affected integration? Start with Login History in Setup, filtered by the OAuth password login type, and review Connected Apps OAuth Usage alongside it. Because Login History retains a limited window, cross-check against infrequent jobs that may not appear in the export.
Does moving to a supported flow make our AI integrations governed? No. A supported flow controls how a system connects. Governance is about what that system is permitted to do once connected, whether a person reviews proposed changes before records are written, and whether actions can be reconstructed afterwards. Those are configuration decisions that sit above authentication.
Where should we start if our AI connections grew faster than our documentation? Pick the one workflow that runs most often and touches the most sensitive object. Document its identity, permissions, actions, review point, and traceability. Fix that one properly, then use it as the template for the rest. If you want to see how a governed intake workflow is structured end to end, you can start a ConvoPro Studio trial or review ConvoPro pricing to understand how it would fit your team.
