Connected Apps Are Being Retired in Salesforce
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. Spring ’26 Migration Timeline & TLS Certificate Phase-Down Connected Apps → External Client Apps 1 Winter ’26 New Connected App creation disabled by default in new orgs Opt-in 2 Spring ’26 New creation disabled across all orgs — Support request required Enforced 3 Summer ’26 Expected enforcement deadline — plan migration before this Deadline 4 Summer ’26 Triple DES for SAML SSO stops working completely Hard Stop TLS Certificate Lifespan Phase-Down (CA-signed certificates only) A Until Mar 14, 2026 Max lifespan 398 days (previous standard) B Mar 15, 2026 Max lifespan drops to 200 days Now C Mar 15, 2027 Max lifespan drops to 100 days Plan for D Mar 15, 2029 Max lifespan drops to 47 days — automation required Automate 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. ⚠ What happens if you try to create a new Connected App without a Support request 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
Salesforce External Client Apps Integration
Most Salesforce orgs have integrations that nobody fully owns. They were built by a consultant who left, configured by an admin who no longer remembers the details, and authenticated with credentials that nobody rotates. They work, so nobody touches them. But now Salesforce just made it a lot harder to ignore. The integration sprawl nobody talks about When teams evaluate their Salesforce stack, they focus on licences, features, and adoption. Integrations sit in the background doing their job until they do not. Then everyone scrambles to find the person who built it, locate the credentials, and understand what it even does. This is common. A mid-size org running Salesforce for several years typically has dozens of active integrations. ERP connectors, marketing platforms, data enrichment tools, internal APIs, partner feeds. Each one was set up for a reason. Very few of them were set up with a clear owner, a documented auth pattern, or a rotation schedule. Shared credentials mean a breach in one system can pivot into Salesforce. Unused integrations with live tokens are open doors. Integrations running on admin user accounts are a compliance issue waiting to surface. Why Connected Apps became a governance headache Connected Apps have been the standard way to give external systems access to Salesforce for years. They work. But they were built for a simpler era when integration landscapes were smaller and security expectations were lower. The core problem with Connected Apps at scale is visibility. They are globally available by default, meaning any external system can attempt to authenticate against your org once a Connected App exists. Developer settings and admin policies were intertwined, making it difficult to separate who was responsible for what. And because they were easy to create, orgs ended up with a lot of them, many with broader OAuth scopes than the integration actually needed. The result is a long list of Connected Apps in Setup, some active, some dormant, most with unclear ownership, and a few with permissions that made sense in 2019 and look alarming today. What External Client Apps actually fix Salesforce introduced External Client Apps as the next generation of integration framework, and the design decisions reflect real governance priorities rather than just technical modernisation. The most important change is the default posture. Unlike Connected Apps, an External Client App cannot be used to authenticate against an org unless it is explicitly installed or defined there. Shadow connections, where an external tool authenticates without an architect or admin ever deliberately permitting it, are no longer possible with this model. The second significant change is role separation. Connected Apps blurred the line between the developer who built the integration and the admin who managed it. External Client Apps formalise two distinct configuration layers. Developers define what the app is capable of. Admins in each org control when and how it is used. That separation creates clear ownership, which is what governance actually requires. Third, External Client Apps are built for modern authentication patterns. Older flows that embedded credentials directly are no longer supported. The model enforces explicit client identity, modern OAuth flows, and clear boundaries between authentication, authorisation, and policy enforcement. What this means for your integration register The shift to External Client Apps is an opportunity to build something most orgs are missing: a documented integration register. Not a spreadsheet someone made two years ago. An actual record of every system connecting to Salesforce, with the following information attached to each entry: System name and business purpose. Integration owner, both technical and business-side. Authentication type and OAuth flows in use. Scopes granted and whether they are proportionate to the function. Token rotation schedule and last rotation date. Whether credentials are shared with other integrations or systems. Risk classification: what data can this integration read, write, or delete. This is not an extensive project. Most of the information already exists somewhere. The work is centralising it, assigning owners, and making it part of standard operational practice rather than a one-time audit exercise. Building an approval flow for new integrations One pattern that pays off quickly is a lightweight approval process for new integrations before they go live. Not a bureaucratic gate, but a structured conversation that covers the basics. What does this integration need to access in Salesforce and why. Which authentication flow will it use. Who owns it on both the vendor side and the internal side. What is the plan when credentials need to rotate or the vendor relationship ends. External Client Apps support this pattern well because the separation between developer configuration and admin policy means there is a natural checkpoint. The integration has to be explicitly admitted into the org. That moment is the right time to answer these questions rather than after the fact. Token rotation and monitoring as standard practice Credential rotation is one of those practices most teams agree with in principle and very few apply consistently. With integrations, the problem is that rotation requires coordination between Salesforce, the external system, and whoever manages that vendor relationship. It is easy to defer. External Client Apps support automated credential rotation through the Metadata API, which removes much of the manual friction. For teams running DevOps pipelines, this means rotation can become part of standard operations rather than a quarterly reminder that gets ignored. On the monitoring side, Setup Audit Trail logs policy and setting updates for External Client Apps. Pairing that with event monitoring on API access gives you a clearer picture of what each integration is actually doing versus what it is permitted to do. Anomalies become visible. Dormant integrations surface. Over-permissioned apps become easier to identify and fix. Migration considerations for existing Connected Apps Salesforce has provided a migration path from Connected Apps to External Client Apps, and the trajectory of the platform makes it clear that External Client Apps are the long-term model. That does not mean everything needs to migrate immediately. Working integrations that are not causing governance problems do not need to be touched
