Salesforce Connected App Security Changes: What You Need to Do

Look, here's the thing. If you've ever had someone call your org's users pretending to be "Salesforce IT support" and talk them into authorizing a sketchy app, you already know why Salesforce nuked the old connected app model. And if you haven't experienced that yet, you've probably heard the horror stories from companies like Air France, KLM, and others who got hit by ShinyHunters running vishing campaigns in 2024-2025.

The thesis: Salesforce fundamentally changed how connected apps work in September 2025. Users can no longer self-authorize uninstalled apps by default. This is a good change, but if you haven't prepared for it, your integrations are probably already broken.

The Real Problem Salesforce Is Solving

Before September 2025, any user could authorize an external app to access your org; no admin review required. Sure, the app was technically limited by that user's permissions, but here's the failure mode you're preventing: a threat actor calls your power user, says "Hi, I'm from IT, we need you to troubleshoot Data Loader," and talks them into authorizing a cloned malicious app. 

Boom! API access to everything that the user can see.

The OAuth 2.0 Device Flow made this especially easy to exploit. That's the authentication method where Data Loader shows you a code and says "enter this at salesforce.com/device." An attacker could generate that code on their end and convince a user to "verify" it. The user has no way to tell they're authorizing a fake app.

The fundamental risk: Connected apps operate in an "allow by default" model. Salesforce flipped this to "deny by default" for uninstalled apps.

What Actually Changed:

The rollout happened in phases:

• August 28, 2025: New orgs immediately enforced
• September 2, 2025: Data Loader's OAuth Device Flow died completely
• September 2-17, 2025: Phased enforcement across existing orgs

If you're reading this in 2026 and wondering why your form tool integration stopped working for new team members, this is why.

The New Rules

1. Uninstalled apps are blocked for most users. If an app isn't formally installed in your org (meaning it only shows up in Connected Apps OAuth Usage with an "Install" button), regular users can't authorize it anymore.
2. Existing authorizations are grandfathered. Users who already connected an uninstalled app before enforcement can keep using it unless that app used OAuth Device Flow, which is now dead everywhere. No exceptions. No extensions.
3. Two permissions can bypass the restriction:

• Approve Uninstalled Connected Apps -- New in Summer '25. Lets a user authorize uninstalled apps. System Administrators get this by default on the standard profile.
• Use Any API Client -- The nuclear option. Bypasses all connected app restrictions, including blocked apps. If API Access Control is enabled in your org, this is the only permission that works.

What You Actually Need to Do

Step 1: Audit Your Connected Apps

Go to Setup → Connected Apps OAuth Usage. Right now.

Every row with an "Install" button in the Actions column is an uninstalled app that's potentially affected. Note:

• What the app is
• Who's using it (check the user count)
• Whether your org actually needs it

The decision rules:

• Known business-critical app (Donorbox, Mailchimp, FormAssembly, etc.)? → Install it
• Unknown or unused? → Block it
• Recognized but abandoned? → Block it (you can always unblock later)

Step 2: Install the Apps You Trust

Click "Install" next to each app you want to keep. After installing:

1. Click "Manage" on the installed app
2. Find Permitted Users under OAuth Policies
3. Set it to "Admin approved users are pre-authorized"
4. Add the specific Profiles or Permission Sets that should have access

This is the secure approach. Don't leave it on "All users may self-authorize"--that defeats the whole point.

Step 3: Handle the "Approve Uninstalled Connected Apps" Permission Carefully

Who should get this permission: Admins and developers who need to test new integrations before formal installation. That's it.

Who should NOT get this permission: End users. Sales reps. Anyone who might get a phone call from a social engineer.

If API Access Control is enabled: This permission doesn't work. You need Use Any API Client instead– but that's even more dangerous since it bypasses blocked apps too. Use with extreme caution.

Pro tip: The permission is automatically assigned to the standard System Administrator profile. If you're using custom admin profiles, you may need to add it manually.

Step 4: Fix Data Loader Before It Breaks

OAuth Device Flow is gone. Period. Your options are:

Concrete steps:

1. Download Data Loader v64.1.0 or later
2. When logging in, choose Password or OAuth Web Server Flow
3. Update your team's documentation
4. If you have automated Data Loader jobs using Device Flow, they're broken. Migrate them

Step 5: Talk to Your Vendors

Many third-party apps have published specific guides. Check:

• Your AppExchange app vendors
• Any integration consultants you work with
• The documentation for tools like Zapier, Workato, etc.

Anti-Patterns to Avoid

• "Just give everyone Approve Uninstalled Connected Apps" You've now recreated the old security model. Congratulations, you've accomplished nothing except adding an extra click.
• Ignoring this until users complain New employees won't be able to connect to legitimate tools. You'll be firefighting integration issues one at a time.
• Blocking everything without checking usage That "random" app with 47 users might be running your entire volunteer management system.
• Assuming installed apps are automatically safe Installation gives you control, not security. You still need to review OAuth scopes and permitted users.

Decision Framework

If You Want to Go Further: API Access Control

Salesforce offers a feature called API Access Control that switches your entire org from "allow by default" to "deny by default" for all connected apps. This is the gold standard for security, but:

• It's opt-in, so you have to request it from Salesforce Support
• It will break things if you haven't inventoried and approved all your apps first
• Users who need to bypass it require Use Any API Client, which is extremely permissive
• Treat enabling this as a one-way gate

When to enable API Access Control: You're in a regulated industry, you've completed a full connected app audit, and you have governance processes to approve new apps.

What to Do Tomorrow Morning

If you do nothing else:

1. Run the audit: Setup → Connected Apps OAuth Usage. Screenshot it. Know what's there.
2. Install the obvious ones: Your email marketing tool, your donation platform, your form builder--click Install.
3. Block the suspicious ones: Apps you don't recognize with zero users? Block them.
4. Update Data Loader: Make sure everyone's on v64.1.0+ and using a supported auth method.
5. Communicate: Let your team know that new app connections require admin approval.

Your future self will thank you when someone doesn't get to explain to the board how a vishing attack exported 49 million records because Kevin in marketing clicked "Allow" on a fake Data Loader.

Salesforce made these changes for good reason, but making sure they actually protect your org takes a bit of hands-on work. If you’re unsure which connected apps are still in play, worried about broken integrations, or just want a second set of eyes on your setup, Arkus can help. We work with teams every day to sort through connected apps, tighten security the right way, and keep Salesforce running smoothly without slowing anyone down.

If you’d like to talk through what this means for your org, reach out anytime through our contact form.