Salesforce OAuth device flow restrictions (30 November 2026): is your app compliant?

If none of your apps use the device flow, this change doesn't affect you. A Login History query (below) is the quickest place to start, though it only covers about the last six months.

What changes

The device flow is the "go to this URL and enter this code" login used by apps on devices with limited input or display. Salesforce's examples are smart TVs, appliances and other IoT devices. KA 005461280 says the flow is intended only for those cases, and Salesforce is restricting it for security.

An app is compliant only when it meets all four requirements:

1. It's an external client app (not a connected app).
2. Its distribution state is Local (not packaged).
3. Its callback URL is https://localhost.
4. No other OAuth flows are enabled on it.

Since August 2026, Salesforce has been showing banners in Setup and restricting some changes to apps that use the device flow:

• You can't save changes to a non-compliant app while the device flow is enabled.
• If you disable the device flow on a connected app or packaged external client app, you can't turn it back on unless you use a compliant local external client app. (For a packaged external client app, the option stays unavailable until its distribution state is changed to Local.)
• Turning on the device flow in a local external client app automatically sets the callback to https://localhost, removes other callback URLs and disables other OAuth flows.

The callback URL isn't actually used by the device flow. Salesforce uses it to check that the app is local.

Who's affected

• Connected apps with the device flow enabled. All of them are non-compliant.
• Packaged external client apps using the device flow.
• Local external client apps that miss any one rule, for example one that also has the web server flow enabled.
• Apps you installed but didn't build, including managed packages. Salesforce says the developer is responsible for shipping a compliant version before enforcement, so contact the vendor.

In practice, the flow can turn up in command-line tools, kiosk and IoT setups, and older internal utilities. If your team doesn't recognize it, it's still worth running the check below.

How to check your org

1. Query Login History (KA 005461280 gives this exact query; use the English value as written):

SELECT Application
FROM LoginHistory
WHERE LoginSubType = 'OAuth Device'

You can also open Setup → Login History and filter where Login Subtype is OAuth Device. Salesforce notes that Login History covers up to six months, so an app that hasn't been used recently won't show up.

2. Look for the warning banner. In App Manager, open each app with App Type Connected (row menu → View). In External Client App Manager, open each app. A non-compliant app with the device flow enabled shows a warning at the top of the page saying it "doesn't meet new security requirements." If the warning isn't there, the app isn't affected in its current configuration.

3. Check the Release Update. In Setup → Release Updates, open Restrict the OAuth 2.0 Device Flow to Local External Client Apps and follow Salesforce's testing and activation steps.

What to do

For each app that still needs the device flow:

• Connected app: use the automated migration to a local external client app if the app is eligible. If not, create a local external client app by hand that matches it. Set the distribution state to Local and turn on Enable Device Flow.
• External client app: update it to meet all four rules, or create a new local external client app. Salesforce says creating a new one is generally simpler if the existing app is packaged or uses several OAuth flows.
• Split multi-flow apps. If one app serves both the device flow and, for example, the web server flow, create a separate local external client app just for the device flow.
• Update client code with the new client ID and secret if you created a new app.
• Test in a sandbox, including the business process the device supports, then deploy to production.
• Vendor apps: ask the developer for a compliant version, and test it before 30 November.

If something breaks after enforcement, Salesforce's recovery steps are the same: use Login History to identify the app, check the four rules, migrate or replace it, update the credentials and test again.

Timeline

FAQ

Can a connected app keep using the OAuth device flow after 30 November 2026?

No. Every connected app with the device flow enabled is non-compliant. Salesforce says to migrate it to a local external client app before 30 November 2026.

Can one app use the device flow and another OAuth flow?

No. A compliant device-flow app can't have any other OAuth flow enabled. Create a separate local external client app for the device flow.

Why did my callback URL change to https://localhost?

Enabling the device flow on a local external client app sets it automatically. The device flow doesn't use the callback; Salesforce uses it to confirm the app is local.

My app shows no warning banner. Is it affected?

Not in its current configuration, according to Salesforce. The banner appears only when the device flow is enabled and the app is non-compliant. You can still run the Login History query to confirm.

What if the app comes from a managed package?

Contact the developer. Salesforce puts the responsibility for a compliant version on them.

Sources

• KA 005461280, Security Change: OAuth 2.0 Device Flow Restrictions by November 30, 2026 (publish date Oct 7, 2026)
• KA 005461287, Connected App & External Client App Security Requirement Updates (roadmap table, Oct 14, 2026)

Last checked: 29 October 2026, against the Salesforce Help pages above. If Salesforce's page and this article ever disagree, Salesforce's page is correct.