Treat each connected app as a governed identity with an owner, a scope and a review cycle. Limit permissions, set revocation triggers for unused or risky integrations, and coordinate IAM with data protection so the organisation can stop misuse even when access looks legitimate.
How delegated access should be governed in a Salesforce-connected ecosystem
delegated access in a Salesforce-connected ecosystem should be treated as an access governance problem, not just an app-integration problem. The key decision is whether each connected app is allowed to act on behalf of a person or system, on what terms, and for how long. Governance needs an owner, a defined scope, and a review cadence that is tied to business need and data sensitivity.
That framing matters because connected apps often inherit trust from Salesforce, but they can still become a durable access path into CRM data. RFC 8693: OAuth 2.0 Token Exchange is useful here because it captures the delegation pattern: one identity or app can obtain a token that represents another subject, so the organisation has to govern the delegation relationship itself, not only the login event.
The practical control point is to classify every integration by business purpose, data reach, and authority to export, modify, or impersonate. A connected app that can read records but not write them is a different governance object from one that can bulk-export customer data or trigger workflows. The larger the delegated authority, the more the app should look like a privileged identity with explicit lifecycle management.
What good governance looks like for scopes, ownership, and review
Good governance starts with a named owner who can answer three questions: why the app exists, which data it can reach, and when its access should be removed. That owner should be accountable for periodic review, because delegated access decays when the original project ends but the integration remains in place. Review should confirm that the scope still matches the use case and that the integration still has an active business justification.
Scope design should be conservative. Start with the smallest OAuth permissions and Salesforce object access needed for the use case, then deny anything that is not essential to the workflow. Where possible, separate read, write and export functions so that one integration cannot silently become a bulk data movement path. This is especially important in ecosystems with many SaaS-to-SaaS links, because a broad token can become a shortcut around normal user controls.
Teams should also define revocation triggers, not just reviews. Unused integrations, expired projects, failed ownership checks, risky vendor changes, and unusual data access patterns should all trigger reassessment. Human vs Non-Human Identity is a useful model for this because delegated access often blurs the line between a person’s approval and a system’s ongoing authority, which means the governance process has to track both the human decision and the machine-held access.
How to reduce misuse without breaking legitimate automation
Least privilege is necessary but not sufficient. Teams also need to watch for consent drift, overbroad connected apps, and integrations that were approved for one purpose but later reused for another. The organisation should verify that the connected app is still the expected one, that secrets and tokens have not outlived the original trust decision, and that access is limited to the environments and tenants it was meant to support.
Data protection has to sit beside IAM because delegated access can look legitimate while still causing harm. If an app can access sensitive customer, financial, or support data, then logging, anomaly review and export controls become part of the governance model. Identity Data Privacy and Consent Guide aligns well with this problem because consent, minimisation and delegated access need to be managed together when data access is carried through identity-based approvals.
RFC 6749: The OAuth 2.0 Authorization Framework also matters because Salesforce-connected ecosystems frequently rely on OAuth grants and refresh tokens, which means the team must treat token lifetime, revocation and scope restriction as first-class governance controls. If the token can continue working after the original approver has forgotten the integration, the control has already weakened.
Risk and Threat Considerations
Delegated access becomes risky when a legitimate connected app turns into a persistent, trusted path for data theft or misuse. The main exposure is not only compromise of the app itself, but also overtrust in a token, consent grant, or integration that no one is actively watching. In practice, that can enable bulk export, quiet replay of access, or abuse of permissions that users never see in their day-to-day Salesforce workflow.
Failure mechanism: A connected app retains access beyond its intended business purpose, or receives scopes broader than it needs, so stolen tokens, malicious approvals, or vendor compromise can be used to act with legitimate-looking authority.
Impact: Attackers or insiders can read, export, or manipulate CRM data at scale, bypassing normal user scrutiny and turning a trusted integration into a high-blast-radius access path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Delegated access depends on token and secret lifecycle control. |
| AC-6 — Least Privilege | Connected apps should only retain the permissions required for their business purpose. | |
| Recommendation — Manage token issuance, rotation, revocation and expiry for connected apps. Limit each app to the minimum permissions needed to perform its function. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Salesforce-connected access needs defined rules for granting and reviewing permissions. |
| A.8.5 — Secure authentication | Delegated app access depends on strong authentication and token handling. | |
| Recommendation — Define and enforce access rules for connected apps and delegated users. Protect authentication material and verify delegated access tokens are tightly governed. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity management, authentication and access control | Connected-app governance is an identity and access control problem. |
| Recommendation — Inventory, approve and review delegated app access with least privilege. | ||
Practitioner Guidance
What to prioritise: Put every Salesforce connected app into an owner-and-scope inventory, then sort first by data sensitivity and breadth of authority. The integrations that can export, impersonate, or touch regulated records should be reviewed before low-risk automations.
Decision rule: If you cannot explain why the app still needs its current scope, treat it as a candidate for reduction or removal rather than waiting for a confirmed incident. If a token or consent grant outlives the original use case, revocation should be the default response.
What good looks like: The organisation can name who owns each integration, what data it can reach, when it was last reviewed, and what event would force immediate revocation. That is the difference between delegated access that is governed and delegated access that is merely tolerated.
Practitioner takeaway: The control objective is not to eliminate delegation, but to make every delegated path time-bound, scope-bound, and recoverable when trust changes.