Why do Salesforce integrations create privileged access risk?

Why This Matters for Security Teams

Salesforce is rarely the only system in play. Connected apps, middleware, iPaaS jobs, support automations, and service accounts can all inherit access that is far broader than the original use case. That is why integration risk is not just an API concern; it is an identity governance problem. When an integration can read CRM data, write records, trigger workflows, and reach downstream SaaS tools, it becomes a privileged path that deserves the same scrutiny as any admin role. The Ultimate Guide to NHIs — Key Challenges and Risks notes that 97% of NHIs carry excessive privileges, which helps explain why integrations so often exceed intended access boundaries. Guidance from the OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 both point toward least privilege, ownership, and continuous oversight as core controls. In practice, many security teams encounter Salesforce integration abuse only after a token is reused, a connector is over-scoped, or the original business owner has already left the organisation.

How It Works in Practice

A Salesforce integration usually relies on an NHI such as a connected app, OAuth token, API key, certificate, or service account. If that NHI is persistent, it can keep working long after the project it supported has changed. If it is shared across teams, nobody may know who approved its scopes or who should revoke it. If it is embedded in automation, the credential often spreads into config files, CI/CD systems, or orchestration tools, which makes review even harder. The risk is amplified when the integration is granted broad CRM permissions and then chained into other systems, because the Salesforce trust path becomes a launch point rather than a simple data connector. A practical control set is straightforward:

• Assign a named owner for every connected app, token, and API account.
• Restrict scopes to the minimum records, objects, and actions needed.
• Prefer short-lived secrets and rotate them on a defined cadence.
• Use PAM and RBAC for human administrators, but treat the integration as a separate NHI with its own lifecycle.
• Log token use, privilege escalation, and unusual API volume, then review those events against business intent.

The Ultimate Guide to NHIs and the Salesloft OAuth token breach illustrate how a single compromised integration can pivot into Salesforce data access and broader lateral movement. These controls tend to break down when the integration is owned by a project team that rotates frequently, because access reviews lag behind the actual operational footprint.

Common Variations and Edge Cases

Tighter integration control often increases operational overhead, requiring organisations to balance security with deployment speed and support burden. That tradeoff is most visible in environments that rely on third-party apps, managed packages, or legacy automations that cannot easily support granular scoping. Current guidance suggests that these cases should not be exempted from governance, but they may need compensating controls such as tighter monitoring, explicit approval workflows, and time-bound access. There is no universal standard for this yet, especially where business teams demand uninterrupted syncing or real-time customer workflows. A common edge case is the “temporary” integration that becomes permanent because nobody defines an offboarding trigger. Another is the shared API user used by multiple jobs, which makes attribution impossible when something goes wrong. A third is the vendor-managed connector that appears low-risk but can still inherit powerful OAuth grants if the consent screen is approved without review. The Top 10 NHI Issues and Ultimate Guide to NHIs — Why NHI Security Matters Now both reinforce the same point: persistent secrets and unclear ownership are what turn convenience into privilege creep. The right answer is usually not to block Salesforce integrations, but to make them time-bound, reviewable, and revocable by design.

Related resources from NHI Mgmt Group

• Why do Salesforce integrations increase NHI risk?
• When does JIT access create more risk than it reduces?
• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?