An integration user is a dedicated Salesforce identity used by systems rather than people. It should represent one business purpose and one access pattern. When multiple applications share the same user, privilege tends to accumulate and the blast radius of compromise expands quickly.
What an integration user is for
An integration user is not a person-like convenience account. It should exist to support a single system purpose, with a single access pattern, so the organisation can reason clearly about what the integration is allowed to do, who owns it, and what must change when that integration changes.
That narrow purpose matters because shared integration identities tend to become catch-alls. Over time, teams add permissions to avoid breaking connected apps, and the account starts to represent more than one business process.
Why separate integration users matter
When one integration user is reused across multiple applications, the account stops being a clean boundary and becomes a shared trust channel. If one connected app is compromised or misconfigured, the same credentials, tokens, and permissions may expose every workload using that identity.
This is why dedicated users reduce blast radius. A compromise, token leak, or bad access change then affects only one business integration instead of every system that borrowed the same identity.
That same principle is a core theme in Service Account Security Guide, which treats shared non-human identities as a governance and least-privilege problem rather than just an administration choice.
Common failure patterns
The most common failure is privilege accumulation. A team starts with enough access for one API or vendor connection, then adds more access to support adjacent workflows, emergency troubleshooting, reporting, or legacy dependencies.
Another failure pattern is shared ownership. When several systems or teams depend on the same user, nobody has a complete view of the permissions, token lifetime, or revocation impact. That makes offboarding, audit, and incident response slower and less reliable.
Integration-user sprawl often shows up as shared credentials, long-lived refresh tokens, and broad object or API permissions. OAuth and SaaS integration breaches is relevant here because it shows how connected-app trust can fail when token scope and revocation discipline are weak.
How to manage an integration user safely
A well-run integration user maps one business function to one identity, with permissions limited to the exact objects, APIs, and workflows that function needs. That makes review easier and supports clean offboarding when the vendor, app, or process is retired.
Security teams should also treat the connected application and the user as a pair. The user’s permissions, the app’s OAuth settings, and the logging around its activity all need to be reviewed together, because the weakness is often in the relationship between them rather than in either component alone.
How to review Salesforce connected apps and integration users is a practical reference for the review-and-tighten workflow, and Salesforce Security Guide places that work in the wider org security model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Integration users are service identities that need controlled authentication and traceability. |
| AC-6 — Least Privilege | Dedicated integration users should only hold the permissions each automation needs. | |
| Recommendation — Apply IA-9 to bind each integration user to a distinct authenticated service trust path. Enforce AC-6 so each integration user has only the permissions its workflow requires. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Shared integration users commonly accumulate excessive access across multiple systems. |
| NHI-07 — Long-Lived Secrets | Integration users often rely on tokens or credentials that persist beyond safe rotation windows. | |
| NHI-01 — Improper Offboarding | Retiring an integration user safely requires removing access and revoking connected app trust. | |
| Recommendation — Reduce NHI-05 exposure by splitting shared integrations into dedicated, minimally scoped users. Rotate and shorten-lived integration credentials to limit NHI-07 exposure. Retire integration users with explicit offboarding so stale access does not remain active. | ||
Related resources from NHI Mgmt Group
- Guide: Gong, Drift and Sales Engagement OAuth Integration Security Guide
- What is the difference between user compromise and SaaS integration compromise?
- Who is accountable when a user approves a malicious SaaS integration?
- Who is accountable when a connected integration keeps access after a user disconnects it?
- Why do user-controlled scripting features create outsized risk in data integration and BI platforms?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org