Salesforce has emailed admins about a set of security changes to how apps and integrations log in to Salesforce. These are OAuth changes, and they affect connected apps and external client apps. Some deadlines are only weeks away. If an integration uses one of these old login methods and nobody updates it, it will simply stop connecting on the enforcement date.
Here’s what each change means in plain English, who it affects and what to do. Salesforce keeps the full, official list in its Connected App & External Client App Security Requirement Updates page, linked from the email, and each change also has its own release note with the details.
The four changes at a glance
| Change | Enforced | Most likely to affect |
|---|---|---|
| Refresh tokens expire after 30 days of no use | Sandboxes Oct 21, 2026; production Nov 4, 2026 | Integrations that run rarely |
| Device flow limited to local external client apps | Nov 30, 2026 | Very few orgs |
| Username-password flow retired | Feb 20, 2027 | Older scripts and integrations |
| User-agent and hybrid user-agent flows retired | Feb 20, 2027 | Older browser and mobile apps |
1. Refresh tokens expire after 30 days of no use
What changes: a refresh token is what lets an integration stay logged in without asking for a password again. From the enforcement date, if a refresh token isn’t used for more than 30 days, Salesforce cancels it. The integration then has to log in or be authorized again.
Who it affects: integrations that can sit idle for more than a month, such as a quarterly batch job, a seasonal integration, or a desktop or mobile app people rarely open. Integrations that run at least once every 30 days won’t notice. Apps created on or after July 9, 2026 already have this limit switched on, so nothing changes for them.
What to do:
- List the integrations that run less than once a month.
- Either make sure each one uses its refresh token at least once every 30 days, for example with a small scheduled job, or plan who will authorize it again when it’s needed.
2. The device flow is limited to local external client apps
What changes: the device flow is the login where you type a short code on another device, the way you log in to a smart TV. It will only work through local external client apps that use a localhost callback URL. Connected apps can no longer use it.
Who it affects: Salesforce says this is rare. You’re affected if Login History shows logins listed as OAuth Device, or if App Manager shows a device-flow warning banner.
What to do: move the app from a connected app to an external client app before November 30, 2026.
3. The username-password flow is retired
What changes: some integrations log in by sending a Salesforce username and password straight to the OAuth endpoint. That method stops working for connected apps.
Who it affects: orgs where Login History shows OAuth Username-Password logins, or where Setup shows the “Retirement of OAuth 2.0 Username-Password Flow for Connected Apps” release update. This includes custom integrations and apps installed from managed packages. If that release update doesn’t appear in your org, the flow is already blocked there and you aren’t affected.
What to do: switch to the web server flow, where a person approves access once, or the client credentials flow for system-to-system integrations with no person involved. For installed packages, ask the vendor for an updated version.
This is a different change from the SOAP API login() retirement, which we covered in integration logins failing after the SOAP login() retirement. Many older integrations use one or the other, so check for both.
4. The user-agent and hybrid user-agent flows are retired
What changes: these older flows were common in browser-based and mobile apps. They are retired for both connected apps and external client apps.
Who it affects: orgs where Login History shows OAuth User-Agent, OAuth User-Agent for Hybrid Apps or OAuth User-Agent with ID Token, including apps from managed packages.
What to do: move to the web server flow with PKCE. PKCE adds a one-time secret to each login, so an intercepted login code can’t be reused.
How to check your org in 10 minutes
- Open Login History. In Setup, search for Login History. Look for logins listed as OAuth Username-Password, OAuth Device or OAuth User-Agent. Each one points to an app you need to update.
- Check Release Updates. In Setup, search for Release Updates and look for updates about these OAuth flows.
- Check App Manager for a device-flow warning banner.
- List the integrations that run rarely, for the 30-day refresh token limit.
- Test in a sandbox first. The refresh token limit reaches sandboxes two weeks before production, so you get a natural rehearsal.
If you’re setting up new integrations, use external client apps from the start. Salesforce has stopped letting orgs create new connected apps, and our Named Credentials guide covers the secure way for Salesforce to call other systems.
Who to involve
Forward this to whoever owns your integrations: your Salesforce admin, the developers who built them, and the vendors of any installed apps. Salesforce’s own advice is to test in a sandbox and fix things before the enforcement dates, because after those dates the old logins fail without warning.