Salesforce restricted the creation of new connected apps as of Spring '26, so every new API integration now has to be built as an External Client App, and every existing connected app is a migration decision. Existing connected apps keep working, which makes it tempting to do nothing, but the integration estate around them is exactly where recent Salesforce data theft campaigns started. This guide explains what changed, the official status, which apps can migrate and which cannot, how to inventory the OAuth clients and integration users behind them, and how to test and roll back. It is for Salesforce administrators, integration architects and identity teams who own the API access into an org. For the wider platform, see the Salesforce Security Guide; for a step-by-step review of current apps, see How to review Salesforce connected apps and integration users.
This is an independent guide from NHI Mgmt Group, based on Salesforce's public documentation as of November 2026. It is not sponsored or reviewed by Salesforce. Product features change, so confirm settings against Salesforce's current documentation.
Key takeaways
- New connected apps are restricted. Salesforce Help states that connected app creation is restricted as of Spring '26 and recommends External Client Apps instead; an exception requires a Salesforce Support case.
- Existing apps still work, for now. Salesforce says you can keep using existing connected apps during and after Spring '26, so migration can be planned rather than rushed.
- External Client Apps are closed by default. They cannot be used in an org until an admin installs them, and developer settings are separated from admin-controlled policies.
- In-place migration keeps credentials. Migrating a local connected app preserves its consumer key and secret and keeps refresh tokens valid, so most integrations do not need reconfiguring.
- Some patterns cannot move. The username-password flow will not be made available for External Client Apps, and user provisioning, Canvas, dynamic client registration and SSO apps block the migration button.
What is changing and why
A connected app is the long-standing Salesforce framework that lets an external application authenticate to an org with OAuth 2.0 or SAML. By default, an app created in one org can be authorised by users in other orgs without being installed, so restrict user authorisation of uninstalled apps to the ones you approve.
External Client Apps (ECAs) are described by Salesforce as the next generation of connected apps. They support the same OAuth flows, with a few exceptions, and change the security model in four ways:
- Closed by default: an ECA cannot be used in an org until an admin installs it, which is why Salesforce lists API access control as not needed for ECAs.
- Separated roles: developers own app settings (OAuth flows, callback URLs, scopes), which are packaged; subscriber org admins own policies (allowed users, refresh token validity, session timeouts, IP restrictions), which are never packaged and which developers cannot edit.
- Protected secrets: sensitive consumer details live in a global OAuth settings file that can never be packaged; a local OAuth settings file holds the rest and references it.
- Metadata compliant: ECAs are fully expressed in metadata (
ExternalClientApplication,ExtlClntAppGlobalOauthSettings,ExtlClntAppOauthSettings,ExtlClntAppOauthConfigurablePolicies), so they can be versioned, reviewed and deployed through source control and second-generation managed packaging (2GP).
| Capability | Connected app | External Client App |
|---|---|---|
| Default availability | Usable from other orgs without installation | Closed until an admin installs it |
| Settings and policies | One object, edited by whoever manages the app | Developer settings packaged; admin policies local and never packaged |
| Packaging | 1GP only (2GP needs a 1GP workaround) | Designed for 2GP; can also go into 1GP packages |
| Metadata API | Subset of features via ConnectedApp | Fully metadata compliant |
| Username-password flow | Supported | Will not be made available |
| Dynamic client registration | Supported | Not yet supported |
| User provisioning | Supported | Not available |
| Sandbox refresh | Copied | Local ECAs are not copied; packaged ECAs are |
| New creation | Restricted as of Spring '26 | Available in App Manager or via Metadata API |
Official timeline and current status
| Date or release | Change | Source |
|---|---|---|
| Early September 2025 (as stated by Salesforce) | Uninstalled connected app usage restriction: new users blocked from uninstalled connected apps; device flow apps that are uninstalled blocked for everyone; enabled automatically for all orgs and cannot be turned off. The Approve Uninstalled Connected Apps permission bypasses it. | Salesforce Help knowledge article 005132365 |
| Spring '26 | Creation of new connected apps restricted; existing connected apps continue to work; Salesforce Support can enable creation where it is still required. | Salesforce Help: Create a Connected App; REST API Developer Guide |
| Current (checked 8 November 2026) | Salesforce recommends using External Client Apps "in all situations" and migrating local connected apps to local ECAs. No retirement date for existing connected apps is published on the pages checked. | Salesforce Help: External integrations overview |
Salesforce has not published, on the pages checked, a date after which existing connected apps stop working. Treat that as a gap to monitor in each release's notes, not as a guarantee that connected apps are permanent.
Who and what is affected
- Internal integrations: middleware, ETL, data warehouse loaders, CI/CD deployment users and scripts that authenticate with a locally created connected app. These are the main migration candidates.
- ISVs and AppExchange partners: packaged connected apps in 1GP packages. New packaged integrations should be built as ECAs in 2GP; the Help pages checked do not describe in-place migration of packaged connected apps, so partners need their own plan.
- Legacy username-password flow clients: scripts and older tools that send a username, password and security token. They cannot move to an ECA and must change flow, to the web server flow with PKCE for interactive users or the client credentials flow for server-to-server.
- Identity provisioning: connected apps with user provisioning enabled, and SSO apps, cannot use the migration button.
- Sandbox pipelines: local ECAs are not copied on sandbox refresh, so environments that relied on connected apps appearing after a refresh will need ECAs deployed through metadata.
- Users of third-party tools: since the uninstalled app restriction, new users of an uninstalled connected app see "app must be installed into org" or, with API Access Control,
error=OAUTH_APP_BLOCKED.
Finding affected systems and identities
- List every app. In Setup, App Manager lists connected apps and ECAs. Retrieve
ConnectedAppandExternalClientApplicationmetadata into source control so the inventory can be diffed between releases. - See what is actually used. The Connected Apps OAuth Usage page shows which apps users have authorised, including uninstalled ones, and how many users each has. Salesforce directs admins to review it and install the apps they trust.
- Classify each app. Record: local or packaged, OAuth flows enabled (flag username-password and device flow), scopes (flag
full,apiplusrefresh_token), callback URLs, IP relaxation, refresh token policy, and whether user provisioning, Canvas or SAML is enabled. - Map the integration users. For client credentials apps, identify the run-as user and its profile and permission sets; for user-authorised apps, identify who authorised them. Integration users with Modify All Data or View All Data are the highest risk.
- Find the client side. Search secrets stores, middleware configuration and repositories for each consumer key so every app has a known owner and system.
- Check who can bypass controls. List users holding Approve Uninstalled Connected Apps; Salesforce notes custom profiles cloned from System Administrator are not updated automatically, so check both directions.
Event Monitoring adds the runtime view: API and login events by connected app show which apps are dormant and which export at volume. See the Salesforce Event Monitoring Detection Guide.
Migration options
| Situation | Path | Notes |
|---|---|---|
| Local connected app, eligible | In-place migration: App Manager, open the app, Migrate to External Client App | Consumer key and secret preserved; refresh tokens remain valid; original kept read-only. UI only, no API or CLI. |
| Local app using username-password flow | Change the client to web server flow with PKCE or client credentials, then migrate or rebuild | The migration cannot detect this flow, so confirm it yourself before migrating |
| Not eligible (provisioning, custom Apex handler, Canvas, dynamic client registration, Triple DES SAML, SSO) | Create a new ECA with equivalent settings and rotate the client to its credentials | A credential change, so schedule it like a rotation |
| ISV or packaged integration | Build a packageable ECA (distributionState Packageable) and ship it in 2GP | Subscriber admins then set their own policies |
| Unused app | Revoke tokens, block, then delete | The cheapest migration is retirement |
The in-place migration is supported in Lightning Experience in Professional, Performance, Unlimited and Developer editions, and requires the "Create, edit, and delete External Client Apps" permission.
Hardening while you migrate
- Policies: restrict allowed users to admin-approved users and grant access through permission sets, set refresh token validity to an expiry rather than "valid until revoked", and enforce IP restrictions for server-to-server integrations.
- Flows: prefer client credentials for machine integrations, with a dedicated, minimum-permission integration user. See the Machine-to-Machine OAuth (Client Credentials) Guide.
- Scopes: drop
fullandrefresh_tokenwhere not needed; scopes are developer settings, so change them in source control. - Secrets: keep consumer secrets in a secrets manager and use the global settings for key and secret rotation.
- API Access Control: with all integrations installed, enabling API Access Control blocks every client that is not explicitly allowed, closing the gap that connection code phishing relied on.
Testing and rollback
- Start in a sandbox: migrate the app in a full or partial sandbox, remembering local ECAs are not copied by refresh, so recreate or deploy them after each refresh.
- Run each integration end to end: token request, refresh, API calls and bulk jobs, and check Event Monitoring for the new app identity.
- Verify policies: confirm that users outside the assigned permission sets are refused and that refresh token expiry behaves as set.
- Migrate production in a change window: one app at a time, with the client owner watching for errors.
- Do not delete the original: both apps share the same consumer, so Salesforce warns against deleting the read-only connected app.
- Rollback: Salesforce states that deleting the External Client App reactivates the connected app with the settings and policies it had at migration time. Changes made in the ECA after migration are lost, so record them.
Risks of doing nothing
- Integration sprawl stays open by default: connected apps keep their old policy model, including "all users may self-authorise" and long-lived refresh tokens.
- Token theft impact stays high: long-lived refresh tokens held by third parties let a holder call Salesforce APIs as a trusted app, so keep their lifetimes short and their scopes narrow.
- Blocked delivery: teams that need a new integration and find connected app creation restricted will request Support exceptions or reuse an existing app with broad scopes, both worse than an ECA.
- Legacy flow lock-in: clients still on the username-password flow have no ECA path, so the longer they stay, the harder the eventual change.
- Change control outside metadata: settings not held in metadata cannot be reviewed or diffed, so drift and backdoor apps go unnoticed.
Framework mapping
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev 5 | ATT&CK v20 |
|---|---|---|---|
| Integration and OAuth client inventory | ID.AM-02 | CM-8 | T1199 Trusted Relationship |
| Consumer secrets and refresh tokens | PR.AA-01 | IA-5 | T1528 Steal Application Access Token |
| Integration user permissions and scopes | PR.AA-05 | AC-6 | T1550.001 Application Access Token |
| Third-party app approval | GV.SC-07 | SA-9 | T1199 Trusted Relationship |
| Disabling legacy flows and unused apps | PR.PS-01 | CM-7 | T1528 Steal Application Access Token |
Practitioner checklist
- Export every connected app and ECA to metadata and record owner, flows, scopes, run-as user and client system.
- Review the Connected Apps OAuth Usage page, install trusted apps and block the rest.
- Find every client on the username-password flow and move it to web server with PKCE or client credentials.
- Migrate eligible local connected apps in a sandbox, test end to end, then migrate production one app at a time.
- Keep the read-only connected app after migration and document the rollback.
- Set refresh token expiry, permission set based access and IP restrictions in each ECA policy.
- Audit holders of Approve Uninstalled Connected Apps, including cloned admin profiles.
- Enable API Access Control once all required integrations are installed.
Standards and references
- Salesforce Help: External Client Apps
- Salesforce Help: Comparison of Connected Apps and External Client Apps Features
- Salesforce Help: Connected App to External Client App Migration
- Salesforce Help: Migrate a Local Connected App to an External Client App
- Salesforce Help: Create a Connected App
- Salesforce Help: Uninstalled Connected App Usage Restriction
- Salesforce Developers: Authorization Through External Client Apps or Connected Apps and OAuth 2.0
- Salesforce Developers Blog: Secure Your Org with External Client Apps
Related NHI Mgmt Group resources: Salesforce Security Guide · How to review Salesforce connected apps and integration users · Salesforce Event Monitoring Detection Guide · OAuth and SaaS integration breaches