When a user connects a third-party application to Salesforce via OAuth, they grant that application a persistent access token. That token remains valid — and that application retains access — long after the user changes roles, leaves the company, or simply stops using the tool.
What connected apps can see
The risk depends heavily on what scopes the application requested at the time of authorization. An app with api scope can query any Salesforce object the authorizing user can access. For a System Administrator, that means everything.
Common connected apps that security teams find in Salesforce environments include:
- Productivity tools (Zapier, Make, n8n) with broad API scope
- Data enrichment vendors with access to contact and account objects
- Marketing automation platforms synchronized with lead and contact data
- Analytics tools that pull opportunity and pipeline data
- Developer tools and CLI utilities authorized by engineers
The lifecycle problem
Most organizations have no systematic process for reviewing connected app authorizations. Tokens granted by former employees continue to work until someone explicitly revokes them. Apps used for a brief test or integration project retain access indefinitely.
When these apps are operated by vendors who have suffered their own security incidents — or when they were abandoned rather than properly decommissioned — that token represents a persistent path into your Salesforce data.
What good connected app governance looks like
Effective management of connected apps requires a current inventory of every authorized application, the scopes granted, the authorizing user, and the last time the token was used. Applications authorized by former employees should be reviewed immediately. Applications with broad scopes that have not been used recently should be evaluated for revocation.
This is not a one-time audit — it requires continuous monitoring as new applications are authorized and existing ones fall dormant.