Salesforce Connected App Security Changes: A Readiness Guide

Salesforce is moving Connected App access from "open by default" to "approved by default." Uninstalled Connected Apps are now blocked for most users, OAuth 2.0 Device Flow is being retired, and Salesforce is steering everyone toward External Client Apps as the long-term replacement. If your org hasn't audited what's actually authorized to talk to it, some integration will break before you find out why.

What is actually changing with Connected Apps?

Salesforce now blocks uninstalled Connected Apps by default, meaning any app a user authorized on their own, without an admin formally installing it in the org, loses access unless someone grants a specific bypass permission. Apps that still rely on OAuth 2.0 Device Flow lose access outright, even if they were previously authorized. Longer term, Salesforce is retiring the classic Connected App as the primary integration object in favor of External Client Apps, which separate the app definition from its policies and give admins finer control over scopes, IP ranges, and session behavior.

Why is Salesforce tightening this now?

The short version: OAuth authorization became a favorite target. Attackers impersonating IT support have talked employees into approving connected apps that looked legitimate, then used that access to pull data quietly over weeks. That's a social engineering problem, not a platform vulnerability, but Salesforce's response is architectural, making the default posture "nothing connects until an admin says so."

That shift is reasonable. It also means org hygiene that used to be optional, knowing exactly which apps have API access and why, is now the difference between a quiet Tuesday and an unplanned incident call.

Where do integrations actually break?

In our experience supporting Salesforce orgs through platform changes, the failures rarely show up where teams expect. Watch for:

• Middleware and iPaaS connectors set up years ago by someone who's since left the team, with no documented owner.
• Data Loader jobs and scheduled ETL scripts still using OAuth Device Flow for unattended runs.
• Reporting or BI tools authorized by an individual user rather than installed org-wide.
• Partner or ISV apps that were never formally installed, just authorized once during a pilot.

Any of these can pass unnoticed for months until the restriction kicks in and the sync job simply stops, often with no obvious error pointing back to the cause.

How do you audit your org before the restrictions bite?

This doesn't require new tooling, just a deliberate pass through Setup:

• Open Setup > Connected Apps OAuth Usage and list every app currently authorized, not just the ones you installed.
• Flag anything showing an "Install" action, that's your uninstalled, at-risk list.
• Check last-used dates. Apps with no recent activity are candidates to revoke, not preserve "just in case."
• Confirm your org's API Access Control policy and who holds the "Approve Uninstalled Connected Apps" permission.
• For anything you keep, write down who owns it and why. That record is what saves you time during the next platform change, not just this one.

What should change in how you govern integrations going forward?

Treat this as a prompt to formalize integration governance, not a one-time cleanup. New integrations should be installed and scoped deliberately from day one rather than authorized ad hoc by whoever set them up. If you're planning new external connections, building them as External Client Apps from the start avoids a second migration later.

This is exactly the kind of work we do alongside internal Salesforce teams: mapping existing integrations, deciding what to keep, retire, or rebuild, and folding the result into a development process that treats access control as part of the release, not an afterthought.

If you'd rather have someone walk through your org's Connected App inventory with you before the next platform update lands, get in touch and we'll help you build the checklist into something repeatable.

FAQ

Will this break my existing Salesforce integrations?

Only if they're uninstalled or still use OAuth 2.0 Device Flow. Installed apps and modern auth flows keep working without changes.

What is the difference between a Connected App and an External Client App?

External Client Apps separate the app's identity from its access policies, giving admins more granular control over scopes and sessions; Salesforce is positioning them as the long-term replacement for classic Connected Apps.

Who should get the "Approve Uninstalled Connected Apps" permission?

Keep it narrow, admins testing new apps and developers maintaining integrations, since it's an all-or-nothing bypass rather than a per-app grant.

How often should we review Connected App access?

Quarterly at minimum, and immediately after any Salesforce security release, since authorization scope creep happens gradually and is easy to miss.