Remote Access
Remote Access is the original Salesforce framework for letting an external application authenticate through OAuth and call into an org on a user's behalf.
Definition
Remote Access is the original Salesforce framework for letting an external application authenticate through OAuth and call into an org on a user's behalf. It is the older predecessor of the Connected App, and Salesforce kept the name alive mostly as a Setup area where legacy integration records still appear so admins can inventory them.
Remote Access is a legacy feature. Any record created under the old model still functions for backward compatibility, but you should not build new integrations this way. Connected Apps replaced it years ago, and External Client Apps are now the recommended option for new work as of Spring '26.
From Remote Access to Connected Apps to External Client Apps
What Remote Access actually did
A Remote Access application was a record that registered an external program with your org so it could use OAuth instead of storing a raw username and password. Each record produced a consumer key and consumer secret, the two values an outside system presents to prove which application is asking for a token. A desktop tool, a server job, or a mobile app would send those credentials, the user would approve access once, and Salesforce would issue an access token scoped to what that user could already see and do. This was a real step forward at the time. Before it existed, many integrations simply embedded a login and called the SOAP API directly, which meant a leaked password handed over full account access. Remote Access moved the trust boundary onto a registered application with a revocable token. The model was deliberately simple, which is also why it was limited. There were few policy controls, no fine grained IP or session settings, and no clean way to package the definition and ship it to another org. Those gaps are exactly what the next generation set out to close.
Why Connected Apps took over
Salesforce introduced Connected Apps as the successor and quietly retired the Remote Access creation experience. The Setup page you may still see exists for one job, which is to surface the old records so you can review or remove them. When you open an existing Remote Access entry in a long lived org, Salesforce often presents it through the Connected App interface, because under the hood the platform now treats both as the same kind of object. Connected Apps carried over the OAuth idea and added everything the original lacked. You get a full set of OAuth scopes, support for SAML and OpenID Connect alongside OAuth, IP relaxation rules, refresh token policies, session timeout controls, and the ability to pre authorize specific profiles or permission sets. A Connected App can also be installed from a managed package, so an ISV can distribute one integration to many customer orgs. For an admin inheriting an environment, the practical takeaway is that anything still labelled Remote Access predates all of these controls and deserves a closer look.
External Client Apps, the current recommendation
The lineage did not stop at Connected Apps. External Client Apps are the newest framework, and Salesforce now recommends them for new integrations in nearly every situation. They keep the OAuth and SAML foundations but fix two long standing pain points. First, they are fully metadata compliant, so their configuration can be tracked in source control and deployed through the Metadata API like any other component. Second, they support second generation managed packaging and keep developer and admin roles separate, which matters for ISVs and for change management. As of Spring '26, Salesforce restricts the creation of brand new Connected Apps. Existing Connected Apps keep working during and after that release, and you can still run anything already in place. To create something new, the default path is an External Client App. If a team genuinely must keep building Connected Apps, that now requires contacting Salesforce Support. So the full ladder reads cleanly. Remote Access came first, Connected Apps replaced it, and External Client Apps are where new development should land today.
Why an old Remote Access entry is a security concern
An active Remote Access or legacy Connected App record is a standing credential. It holds a consumer key and secret, and it may already have refresh tokens that let an external system pull data without anyone logging in interactively. If nobody can say which integration a given entry belongs to, you are looking at the precise thing an attacker wants, which is durable programmatic access that does not trip a password reset. The risk is worse for the oldest records because they predate modern guardrails. They may grant the full API scope, allow connections from any IP address, and never force token expiry. They also tend to run as a powerful integration user, so the blast radius of a stolen token is large. None of this means the entry is malicious. It usually just means it was set up long ago by someone who has since left. The job during a security review is to prove ownership, confirm the scope is still appropriate, and either tighten the configuration or revoke it outright.
Auditing and decommissioning safely
Treat the Remote Access and Connected Apps area as part of every access review, not a page you skip. Build an inventory of each entry alongside its consumer key, the OAuth scopes it requests, the policies it enforces, and a named human owner. Cross check that list against the OAuth Connected Apps usage report, which shows how many users have authorized each app and when it was last used. An entry with zero recent use and no owner is your first candidate for removal. Decommissioning needs care because revoking access breaks any live job that depends on it. Confirm an integration is truly idle before you act, then revoke its tokens and watch for failures over a full business cycle. For anything still active, the better move is migration. Recreate the integration as an External Client App, or at minimum a properly configured Connected App, point the external system at the new credentials, and only then retire the legacy record. That sequence keeps the integration running while you remove the unmanaged credential.
A worked example of finding and replacing one
Picture inheriting an org with a Remote Access entry named "Legacy ETL Sync" and no documentation. You open it and see the full api scope, IP relaxation set to relax restrictions, and a consumer key that an old data pipeline still uses. The usage report shows daily activity under a service account, so this is clearly live, not dead. The safe path is methodical. You trace the consumer key to the external scheduler and identify the team that owns the pipeline. You stand up a new External Client App with the same scope but tighter policy, for example IP enforcement and a defined refresh token lifetime. You hand the new consumer key and secret to the pipeline owner, who updates the connection during a maintenance window. You run both in parallel briefly to confirm the new path works, then revoke the old tokens and remove the Remote Access record. The integration never stopped, yet you replaced an unmanaged relic with a tracked, policy controlled app. That is the whole point of knowing this term: not to use it, but to clean it up correctly.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Remote Access.
Hands-on resources to go deeper on Remote Access.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does the Remote Access Setup page manage in Salesforce?
Q2. What replaced Remote Access for building new external integrations?
Q3. Why does an inherited org's Remote Access page matter during a security review?
Discussion
Loading discussion…