Starting with Spring ’26, Salesforce disabled the creation of new Connected Apps by default across all orgs. Your existing ones still work for now.
But the direction is clear: External Client Apps are the future, and the clock is running.
This guide covers what changed, why Salesforce made this move, what External Client Apps actually give you, which apps are and are not affected, and a step-by-step migration walkthrough through App Manager.
The second half is a structured checklist for the audit before you migrate and the testing after. The TLS certificate changes happening in the same release are covered at the end, because both come from the same security-first motivation.
Why Salesforce is making this change
Connected Apps have been part of Salesforce for over a decade. If you have ever set up OAuth for a third-party integration, configured Data Loader, or connected a custom web application to the Salesforce API, you have used one. They are everywhere, and most of them work fine.
The problem is not the apps that are configured properly. The problem is the ones that are not, and the architecture that makes unsafe configurations easy to create.
By default, Connected Apps allow any API-enabled user in an org to self-authorise a connection to an external application, without admin approval.
That is how phishing and vishing attacks that targeted Salesforce orgs worked: trick a user into authorising a malicious Connected App, and the attacker has API access to the org’s data. Salesforce responded by tightening this behaviour, but the structural issue remained.
External Client Apps take a different starting position. They adopt a closed security posture by default.
Access is not granted unless an administrator explicitly permits it. Furthermore, the architecture separates developer configuration from admin policy, which means a developer building an integration cannot inadvertently override security settings that the admin put in place.
What changed in Spring ’26, specifically
The rollout has been gradual. In Winter ’26, Salesforce disabled Connected App creation by default in new orgs, with an option for admins to re-enable it manually.
Spring ’26 tightened that further: new Connected App creation is now disabled across all orgs, including existing ones. Getting the ability back requires a Salesforce Support request, and Salesforce has been clear that this option will eventually disappear entirely.
Two categories of Connected Apps are not affected by this change.
Connected Apps created as part of a managed package continue to work and can still be created in that context. Connected Apps used for Slack in the legacy Agentforce Builder are also excluded.
Everything else follows the new default. Any new integration from Spring ’26 onward must be built as an External Client App.
- The New Connected App button no longer appears in App Manager — the option is gone from the UI entirely.
- Attempting to create one via the Metadata API returns an error. There is no workaround inside the platform.
- Any new integration built after Spring '26 that requires its own OAuth client must use an External Client App instead.
- If a specific business case genuinely requires a new Connected App, you must open a Salesforce Support case and explicitly request the capability. Salesforce may or may not grant it, and this option will be removed in a future release.
What External Client Apps offer that Connected Apps do not
External Client Apps are not just Connected Apps with a new name. The differences are architectural, and several of them matter a lot depending on how your org is set up.
Separation of developer settings and admin policies
In a Connected App, the developer configuration and admin security policies live in the same record. A developer with edit access to the Connected App can change the OAuth scopes, the IP restrictions, and the session policies.
In an External Client App, those roles are separated. Developers manage the technical settings; admins manage the access policies. Neither can override the other without the appropriate permission.
For ISVs and AppExchange partners, this matters enormously. It means the admin installing your package can control how it behaves in their org without touching the underlying app configuration.
Second-generation packaging support
External Client Apps are designed specifically for second-generation packaging, or 2GP.
Connected Apps technically work with 2GP, but the process required manual steps that were fragile and time-consuming. ECAs package cleanly, distribute correctly, and integrate naturally with source control and CI/CD pipelines via the Metadata API.
For admins managing integrations rather than building packages, the practical difference is that ECAs behave more predictably in sandboxes and scratch orgs.
Scratch Org support for External Client Apps was added in Spring ’26, which makes the developer testing cycle considerably cleaner.
Closed security posture by default
A new External Client App is not accessible to any user until an administrator explicitly grants access. There is no self-authorisation pathway by default. This is the core security difference from Connected Apps, and it is the reason Salesforce is moving in this direction.
What ECAs do not yet support
Two important gaps remain.
External Client Apps do not support the Username-Password OAuth flow. If any of your existing Connected Apps use this flow, you cannot migrate them yet.
They need to stay as Connected Apps until Salesforce adds support, or until you migrate the underlying integration to a supported OAuth pattern such as JWT Bearer Flow.
Push notifications are also not available in External Client Apps. If your Connected App handles mobile push notifications, migration is not yet possible for that specific functionality.
These are the two scenarios where staying on a Connected App is the right call, not a shortcut.
Which of your Connected Apps actually need attention
Before looking at the migration steps, it helps to categorise what you have. Open Setup, search for App Manager, and filter by type. You are looking for Connected Apps that your org created and manages, not managed package apps created by vendors or installed from AppExchange.
Then ask four questions about each one.
Is it still in use? Check the Connected App OAuth Usage page in Setup. It shows the last authorisation date and the number of active tokens. Apps with no recent activity are candidates for removal, not migration.
Does it use Username-Password OAuth flow? If yes, leave it on the Connected App for now. Mark it for future review when ECA support for that flow is added.
Does it need to be distributed via managed package? If yes, migrate it. The 2GP packaging benefits are the clearest case for an ECA, and this is exactly what ECAs were designed for.
Is it an internal integration with no packaging needs? For integrations that work, are not being distributed, and do not use the Username-Password flow, migration is optional for now. Existing Connected Apps continue to function. Migration for its own sake is not necessary unless you are planning a security audit or a rebuild.
How to migrate a Connected App to an External Client App in App Manager
Salesforce built a migration path directly into App Manager.
When you migrate, the original Connected App becomes read-only. It keeps its consumer key, and any existing integrations using that key continue to work.
The External Client App gets a new consumer key, and new integrations use that instead.
Consequently, migration does not break anything on day one. The old app keeps working for existing authorisations while you transition connections to the new app.
Step 1: Review the Connected App record
Open App Manager in Setup and locate the Connected App you are migrating.
Make a note of the OAuth scopes, IP restrictions, permitted users policy, and any callback URLs. You will need to replicate these settings in the External Client App.
Also check whether the app has any custom attributes or Canvas configuration, as these need separate handling.
Step 2: Initiate the migration
From the App Manager record, click the dropdown next to the Connected App and select Migrate to External Client App.
Salesforce will walk you through the migration wizard. Review each screen carefully.
The wizard carries over most settings, but the separation of developer settings and admin policies means some configuration moves to a different location than you might expect.
Step 3: Configure the OAuth plugin
In an External Client App, OAuth settings are managed through a plugin model. T
he core app defines what the integration is; the OAuth plugin defines how it authenticates.
During migration, Salesforce creates the plugin automatically from your existing Connected App settings. Verify the scopes, callback URLs, and token policies match what the original app had.
Step 4: Validate in a sandbox first
Do not migrate directly in production. Test the External Client App in a sandbox, update the consumer key in your integration, and run a full authentication flow.
Verify that token issuance, scope enforcement, and callback handling all work as expected before you touch the production app.
Step 5: Update your integration credentials
Once the External Client App is validated in sandbox, update the consumer key in your external system or middleware to point to the new app. Schedule this change for a low-traffic window.
After the cutover, monitor error logs for 24 to 48 hours to confirm the new app is functioning correctly before decommissioning the old Connected App record.
Step 6: Retire the Connected App
After the migration is confirmed and all active tokens have been re-issued against the new External Client App, revoke the old Connected App’s tokens and set it to inactive. Keep the record for 30 days as a rollback reference, then delete it.
What to expect in Summer ’26 and beyond
The current situation is that existing Connected Apps continue to work, new creation requires a Support request, and Salesforce has indicated that the Support workaround will itself go away in a future release.
The expected enforcement deadline referenced across Salesforce partner communications is Summer ’26.
Summer ’26 also brings a separate but related enforcement: Triple DES for SAML Single Sign-On configurations stops working completely.
If your org uses SAML SSO and the signing algorithm is Triple DES, that configuration breaks in Summer ’26 regardless of whether you have migrated your Connected Apps.
Specifically, this affects both configurations where Salesforce is the identity provider and configurations where it is the service provider.
Additionally, the legacy hostname retirement is an ongoing enforcement.
Any integration, bookmark, or hardcoded URL still referencing old Salesforce instance URLs rather than My Domain will fail once the redirection ends.
Audit your middleware, custom code, and SSO configurations for instanced URL references.
The TLS certificate changes happening in parallel
Running alongside the Connected Apps migration is a separate but equally important change: TLS certificate lifespans are getting shorter, and they will keep getting shorter over the next three years.
This is not a Salesforce-specific decision.
The CA/Browser Forum, the consortium that sets standards for digital certificates, voted in April 2025 to mandate progressive reductions in certificate validity. Salesforce is following the industry timeline.
The schedule
Until March 14, 2026: maximum certificate lifespan is 398 days (the previous standard).
-From March 15, 2026: new certificates have a maximum lifespan of 200 days.
-From March 15, 2027: the maximum drops to 100 days.
-From March 15, 2029: the maximum drops to 47 days.
Existing certificates keep their current expiration dates. Self-signed certificates are not in scope. However, any CA-signed certificate created from March 15, 2026 onward falls under the new rules immediately.
What this means in practice
By 2029, teams managing certificates manually will be renewing them roughly eight times a year instead of once.
That is not a sustainable process without automation. The organisations that start planning now are the ones that will not face emergency renewal work when the 47-day window arrives.
Three actions are worth taking now. First, stop certificate pinning. Pinning hardcodes a specific certificate in your integration code, which means every rotation breaks the connection.
Second, assign the Expired Certificate Notification permission to at least two admins in your org. Salesforce is also stopping the practice of manually announcing first-party certificate rotations, so automated alerts inside the org are the replacement.
Third, review whether the Certificate Metadata API can automate your renewal process. For Experience Cloud custom domains, the Salesforce CDN handles certificate management automatically.
For integrations using CA-signed certificates, your IT or security team should evaluate whether a Certificate Lifecycle Management tool is worth implementing now before the 100-day window takes effect in 2027.
Common mistakes to avoid during this migration
Migrating without an inventory
The Connected Apps that matter in your org are rarely the ones you remember. Before starting any migration, run the Connected App OAuth Usage report in Setup and export the full list.
Apps with zero recent activity are deletion candidates. Apps with active tokens but no known owner are a security risk that this migration is a good excuse to address.
Testing only the happy path
Most integration failures after an app migration happen in error scenarios, not in the main flow.
After migrating to an External Client App, test what happens when a token expires, when a callback URL is wrong, and when a user with restricted permissions tries to authorise. These edge cases are where the differences between Connected Apps and ECAs are most visible.
Ignoring the Username-Password flow gap
If an integration uses the Username-Password OAuth flow and you migrate its Connected App, the integration stops working. There is no fallback.
Audit your OAuth flows before migrating and flag any that use Username-Password as blocked migrations until Salesforce adds support or you rebuild the auth layer.
Skipping the sandbox validation step
The App Manager migration wizard is straightforward, but the configuration differences between Connected Apps and ECAs are subtle enough that production testing without a sandbox run first is not worth the risk. The migration takes longer when you do it properly once than when you have to rollback and redo it.
The migration window is open. The orgs that plan this properly in Spring ’26 are the ones that will not be scrambling when Summer ’26 enforcement arrives.
Have connected apps in production that you have not looked at in a while? Now is the time.
Our Salesforce team can audit your org and help you migrate without surprises. Reach out to us. Follow us on LinkedIn for more release-critical updates.
