Salesforce Is Retiring Connected Apps — Here's What Your GTM Tech Stack Needs to Do About It

Sapphire Smith
Apr 24
6 min read

It's Monday morning. Your team wants to roll out a new tool to automate part of the Salesforce pipeline. The engineer heads to Connected Apps in Setup, scrolls to where the create button should be — and it's not there.

That's not a bug. That's the Salesforce Spring '26 release doing exactly what Salesforce intended.

Starting this spring, Salesforce disabled the ability to create new Connected Apps by default across all orgs. It's one of the most significant changes in this release cycle, and one that carries real implications for every team running integrations through their Sales Technology Stack. If Salesforce is the backbone of your GTM tech stack — and for most revenue teams, it is — this deserves more than a passing mention in your admin's release notes summary.

What Are Connected Apps, and Why Is Salesforce Moving On?

For over a decade, Connected Apps have been the mechanism that lets external tools talk to Salesforce. Marketing automation platforms, CPQ tools, data enrichment providers, custom internal apps — if it integrates with Salesforce via OAuth, SAML, or OpenID Connect, there's almost certainly a Connected App underneath it.

They worked well for the era they were built in. The assumptions were simpler then: integrations were fewer, architectures were less distributed, and "accessible to all users by default" felt like a reasonable trade-off for ease of use. That era is over.

Today's enterprise environments are API-first, multi-client, and increasingly AI-powered. The threat landscape has evolved accordingly — and Connected Apps, with their open-by-default posture and shared configuration model, have struggled to keep up.

The Security Wake-Up Call That Accelerated This Transition

The timing of this change isn't arbitrary. In 2025, Salesforce environments across the globe were targeted in a coordinated wave of attacks that put Connected Apps squarely in the crosshairs.

Google's Threat Intelligence Group tracked a financially motivated group of hackers — operating under names including ShinyHunters — who ran an extended campaign using voice phishing to exploit Connected Apps. The playbook was deceptively simple: impersonate IT support staff over the phone, trick an employee into connecting to a malicious replica of Salesforce's Data Loader app, and use the resulting OAuth access to quietly siphon customer data. No software vulnerabilities required.

The victims list included Google, Adidas, Qantas, Allianz Life, Pandora, and dozens of other major organizations. Salesforce was quick to note that its platform itself wasn't compromised — but the ease with which attackers leveraged Connected Apps made clear that the framework's security model was no longer fit for purpose.

Salesforce's response was to tighten Connected App defaults in August 2025, then go further with Spring '26. At this point, the message is clear: Connected Apps are being phased out, and External Client Apps are the replacement.

What's Actually Changing — and What Isn't

There's been a fair amount of noise around this update, so let's be precise.

What IS changing:

As of Spring '26, creating new Connected Apps via the Setup UI or Metadata API is disabled by default across all orgs.
Need to create one anyway? You can contact Salesforce Support to unlock the capability — but Salesforce has been clear that this workaround will eventually disappear in future releases.
Salesforce is actively building out External Client Apps as the supported path forward, with active investment and new capabilities that Connected Apps won't receive.

What is NOT changing (yet):

Your existing integrations are not broken. All current Connected Apps continue to function.
You can still edit, install, deploy, and delete existing Connected Apps as normal.
Connected Apps used for Slack in the legacy Agentforce Builder are not affected.

The broader timeline is worth understanding: Connected App creation was already disabled by default in newly provisioned orgs as of Winter '26 (October 2025). Spring '26 extended that to all existing orgs. Future releases will close the Support workaround entirely. This is a phased sunset, rather than a cutoff, but the endpoint is the same — bye, bye Connected Apps.

Why External Client Apps Are Genuinely Better

ECAs aren't just a rebranded version of Connected Apps. They represent a real architectural step forward — and understanding “why” matters for evaluating how seriously to take this transition.

Built on second-generation managed packaging (2GP), ECAs follow a "closed by default" security model where access is explicitly granted through Permission Sets, not assumed. That's a fundamental difference from how Connected Apps operated, and it directly addresses the kind of overpermissioned access that attackers exploited in 2025.

There's also a forward-looking angle that RevOps and GTM leaders should pay close attention to: ECAs are a prerequisite for Salesforce's AI ecosystem. The Salesforce-hosted MCP (Model Context Protocol) Server — which lets AI agents like Claude and ChatGPT query CRM data directly — requires External Client Apps for OAuth. Old Connected Apps aren't supported. If your org has any plans to leverage Agentforce or AI-driven workflow automation, migrating to ECAs isn't a nice-to-have. It's the on-ramp.

What Admins, RevOps Teams, and GTM Leaders Should Be Doing Now

Nothing in your existing environment is broken today — but that's exactly when you want to be making these moves. The teams that start early will avoid the last-minute scramble when future releases close the remaining workarounds. Here's how to approach it:

1. Audit your integrations — know what you have

Pull up Connected App OAuth Usage in Salesforce Setup and build a complete picture of what's running in your org: which apps exist, who authorized them, when they were last active, and what data they can access.

And honestly, cleaning up stale or redundant apps before the migration is valuable in its own right — every unused connection you remove is one less door left open

2. Evaluate your risk exposure

Not every integration carries the same risk. As you audit, look at each app through a security lens: What scopes does it have? Is it operating on least-privilege, or was it set up with broad access "just in case"? Which users have the "Customize Application" or "Manage Connected Apps" permissions — and is that list as tight as it should be?

Any app with access to sensitive customer data, financial records, or broad API permissions deserves extra scrutiny. Flag the ones that need attention before you start planning migration timelines.

3. Plan your migration to External Client Apps

For most Connected Apps, Salesforce has made migration relatively straightforward: in App Manager, select an existing Connected App and choose "Migrate to External Client App." Once migrated, the original becomes read-only.

Two important caveats to plan around: ECAs do not support the Username-Password OAuth flow — if any of your integrations rely on this method, those require additional work before you can migrate. ECAs also don't currently support push notifications through Connected Apps. Know your inventory before you set a timeline, so there are no surprises mid-migration.

For all new integrations from this point forward, start with External Client Apps. Even if you can still access the Support workaround, getting your team comfortable with ECA configuration now makes the full transition much smoother.

4. Build integration governance into your GTM Tech Stack & RevOps standards

Use this transition as a forcing function to establish the kind of integration hygiene that will serve your org well beyond this specific migration. That means: scheduling regular app audits (quarterly is a solid starting cadence), documenting what permissions new integrations are allowed to request, assigning clear ownership for approving exceptions, and reviewing user permissions tied to integration management whenever team members change roles or leave.

The orgs that come out of this change best won't just have migrated their apps — they'll have built a governance model that prevents the kind of unchecked app sprawl that made the 2025 attacks so effective in the first place.

The Bottom Line

Connected Apps aren't disappearing overnight, and your current integrations aren't at risk today. But Salesforce has made the direction unmistakably clear: External Client Apps are the future of integrations in the platform, and the runway to plan this well is now.

For RevOps teams, this isn't just an IT migration — it's a signal to take a hard look at your entire integration layer. Every tool in your GTM tech stack that touches Salesforce is part of your revenue infrastructure. Managing it with the same rigor you'd apply to any other critical system isn't overhead. It's good RevOps.

At Axiss.io, helping revenue teams navigate exactly these kinds of transitions is what we do — making sure platform changes like Spring '26 don't disrupt operations, and turning them into an opportunity to build a tighter, more scalable GTM foundation. If you want a second set of eyes on your current integration landscape, reach out to schedule a conversation.