TL;DR: Salesforce ecosystems increasingly concentrate service accounts, API keys, OAuth tokens, and third-party integrations in ways that outgrow built-in controls, while credential misuse remains a common attack path, according to Entro Security and IBM X-Force. The governance problem is that machine identities behave like durable access layers, not reviewable user accounts, so lifecycle and privilege assumptions fail.
At a glance
What this is: Entro Security argues that Salesforce NHI sprawl is turning integrations, tokens, and service accounts into a governance problem that built-in controls do not fully contain.
Why it matters: IAM and security teams need to treat Salesforce-connected NHIs as durable access pathways, because review processes built for human users miss stale credentials, excess privilege, and integration drift.
By the numbers:
- Salesforce has over 230K customers globally and a market share of over 20% of the CRM business.
- Research found 98.3% of surveyed organizations were associated with at least one third-party that had experienced a breach in the last two years.
- 50% of organizations have indirect relationships with at least 200 fourth parties that have had breaches in the last two years.
- IBM X-Force reported a 71% year-over-year increase in cyberattacks that used stolen or compromised credentials.
Context
Salesforce is no longer just a CRM platform. In practice, it now sits inside a broader ecosystem of integrations, low-code extensions, and connected services that expands the identity surface well beyond human users.
The governance problem is that many organisations still treat Salesforce-connected access like ordinary application access, even when the actual risk sits with service accounts, OAuth tokens, webhook secrets, and third-party packages that outlive the people who set them up.
Key questions
Q: What breaks when Salesforce integrations rely on shared non-human credentials?
A: Shared machine credentials break ownership, traceability, and offboarding. When the same OAuth token or API key is reused across tools and teams, it becomes difficult to know who is accountable, whether access is still needed, and when it should be revoked. That creates a hidden persistence layer that human-style access review processes cannot reliably govern.
Q: Why do overprivileged Salesforce service accounts create disproportionate risk?
A: Because a single machine identity can carry access across many objects and workflows. If an attacker compromises an account with broad permissions such as Modify All Data, the breach can extend far beyond the original integration. The risk is not just credential theft, but the size of the blast radius attached to that credential.
Q: How do you know if NHI governance is actually working in Salesforce?
A: You should be able to name every machine identity, show who owns it, explain why it exists, and prove when it was last reviewed or rotated. If a credential cannot be tied to a business purpose and a revocation path, governance is incomplete. Visibility and ownership are the clearest signals of control.
Q: Should teams treat third-party Salesforce packages like part of the identity perimeter?
A: Yes. Packages, low-code extensions, and connected apps can all expand who or what can reach sensitive data, so the security boundary is no longer the core tenant alone. If a package can change storage, permissions, or data flow, it belongs in the same governance review as any other access pathway.
Technical breakdown
Why Salesforce integrations turn NHIs into durable access paths
Salesforce integrations rely on machine identities such as service accounts, OAuth tokens, API keys, and webhook secrets to move data between systems. Those credentials often need broad object and API permissions to keep workflows running, which makes them durable access paths rather than temporary application settings. The security problem is not that integrations exist, but that their access scope can persist long after the business need changes. When machine identity inventory is incomplete, teams cannot tell which credentials are active, which are stale, or which third parties can still reach sensitive objects.
Practical implication: maintain a live inventory of Salesforce-connected NHIs with ownership, scope, and expiry so access can be reviewed as a governed asset.
How overprivileged API users widen the blast radius
The article highlights API users with permissions such as Modify All Data, which is the classic pattern of excessive machine privilege. In a Salesforce org, that scope can let an attacker manipulate or exfiltrate records across many objects, not just the integration’s intended dataset. The issue becomes more severe when misconfigured permission sets or default storage locations broaden visibility without clear notification. This is less about one bad credential and more about a privilege model that assumes integrations will remain within their original operational boundary.
Practical implication: constrain integration roles to the smallest object and action set possible, then continuously compare actual access to intended business function.
Why long-lived tokens defeat user-style IAM review
Traditional IAM lifecycle practices work best when an identity has a visible owner, a clear joiner-mover-leaver process, and an expected review cadence. Long-lived OAuth tokens and inactive Named Credentials break that model because they can remain valid for months or years without any human interaction. That means the control failure is not only rotation delay, but the assumption that periodic review will catch risk before use. In a connected Salesforce estate, stale machine credentials become hidden persistence mechanisms.
Practical implication: tie rotation, expiry, and revocation to machine identity lifecycle events instead of relying on human access review cycles.
Threat narrative
Attacker objective: The attacker wants to turn one compromised Salesforce integration into broad access to CRM data and adjacent systems.
- Entry occurs through exposed or shared Salesforce-connected credentials such as OAuth tokens, API keys, or secrets passed through collaboration tools.
- Credential abuse follows when an attacker uses a valid integration identity or overprivileged API user to access Salesforce objects and connected services.
- Impact expands through lateral movement into related apps, CRM records, and third-party SaaS data exposed through the same integration chain.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Salesforce NHI sprawl is really a lifecycle failure, not a point-product failure. The article shows that service accounts, tokens, and integration identities accumulate faster than teams can govern them. That is a classic machine-identity pattern: access is created for business speed, then left in place without the same scrutiny applied to human users. The practical conclusion is that Salesforce-connected NHIs need first-class ownership, expiry, and offboarding, not ad hoc admin oversight.
Overprivileged integrations turn routine compromise into full-org exposure. Permissions such as Modify All Data change a single credential event into an org-wide risk event because the machine identity already holds authority across multiple objects and operations. That is why the issue should be measured in blast radius, not in the number of accounts discovered. Practitioners should read this as a reminder that least privilege for NHIs must be defined by integration function, not by platform convenience.
Long-lived OAuth tokens create trust debt that human IAM reviews are not designed to clear. Tokens and Named Credentials can stay valid long after the original business purpose has changed, especially in large Salesforce estates with many third-party packages. The control assumption that periodic review will catch stale access is too weak when the credential itself is the persistent access path. Teams should treat token lifetime as a governance variable, not a technical detail.
Integration trust debt: Salesforce ecosystems accumulate hidden machine access that outlives the workflows they were created for. This is the named concept the article exposes. Once an integration is allowed to expand data sharing, the organisation inherits an access layer that is hard to inventory and harder to retire. The implication is that governance must follow the integration chain, not just the core CRM tenant.
Third-party reach is the real control boundary in modern Salesforce environments. The article’s strongest point is that Salesforce is no longer the only trust decision that matters. AppExchange packages, low-code extensions, and adjacent collaboration tools all become part of the identity perimeter. That means IAM, PAM, and third-party governance teams need a shared view of connected machine identities, or they will keep missing the same exposure pattern.
From our research library:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
- 1 in every 1,000 non-human identities in enterprise environments is more than 10 years old.
- Read next: Ultimate Guide to NHIs — Key Challenges and Risks
What this signals
Salesforce ecosystems now behave like identity supply chains, where one integration decision can create a long tail of machine access that outlives the original business need. Security teams should assume that every connected app can become a persistence path unless ownership, rotation, and revocation are governed with the same discipline as privileged human access.
Integration trust debt: the longer machine credentials remain embedded in collaboration tools, low-code workflows, and AppExchange packages, the harder it becomes to prove who can still reach CRM data. That is a governance problem first, and a technical problem second.
For practitioners
- Map every Salesforce-connected NHI Build an inventory of service accounts, API users, OAuth tokens, webhook secrets, and Named Credentials, then record ownership, purpose, permissions, and last review date.
- Reduce integration privilege scope Remove broad permissions such as Modify All Data from machine identities unless a documented workflow requires them, and verify object-level access against the integration’s actual function.
- Shorten credential lifetime Set rotation and revocation rules for long-lived OAuth tokens and other reusable secrets so stale access does not survive past business need or vendor change.
- Review third-party package access Reassess AppExchange packages and low-code extensions for data exposure, default storage changes, and permission drift that can widen the Salesforce attack surface.
- Separate human and machine permission sets Keep integration permissions distinct from user permissions so credentials meant for app-to-app communication are not accidentally assigned to people or vice versa.
Key takeaways
- Salesforce-connected NHIs create a wider governance gap than most teams expect, because integrations and tokens can persist outside normal user lifecycle controls.
- Entro Security cites high exposure conditions across third-party relationships, while credential misuse remains a common attack pattern.
- The practical response is to inventory machine identities, narrow integration privilege, and retire stale credentials before they become an access pathway.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on exposed OAuth tokens, API keys, and shared credentials in Salesforce ecosystems. |
| NHI-05 — Overprivileged NHI | API users with Modify All Data permissions show the exact overprivilege pattern discussed here. | |
| NHI-07 — Long-Lived Secrets | Outdated OAuth tokens and inactive Named Credentials are a direct long-lived secret risk. | |
| Recommendation — Scan Salesforce-connected systems for leaked machine credentials and revoke any exposed secrets immediately. Review Salesforce machine identities for excess permissions and trim them to the minimum required scope. Set expiry and rotation rules for Salesforce integration secrets so stale credentials do not remain usable. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OAuth tokens, API keys, and service credentials require lifecycle management under IA-5. |
| Recommendation — Apply authenticator lifecycle controls to rotate, revoke, and retire Salesforce machine credentials on schedule. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about mismatched permissions and entitlement sprawl in Salesforce integrations. |
| Recommendation — Map Salesforce integration entitlements to PR.AA-05 and continuously remove access that exceeds business need. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Stolen tokens and exposed secrets enable credential abuse followed by movement across connected systems. |
| Recommendation — Map exposed Salesforce credentials to TA0006 and TA0008 so detections cover both theft and downstream movement. | ||
Key terms
- Salesforce NHI sprawl: The accumulation of service accounts, API keys, OAuth tokens, webhook secrets, and other machine identities across a Salesforce ecosystem. The risk is not just volume but unmanaged access that persists across apps, teams, and vendors without the lifecycle controls usually applied to human users.
- Integration Trust Debt: The accumulated risk created by long-lived, over-scoped, or forgotten SaaS connections that remain active after their original purpose fades. The debt grows when teams treat integration setup as a one-time task instead of a lifecycle-managed identity relationship.
- Machine identity blast radius: The amount of data, systems, and workflows an attacker can reach after compromising a non-human identity. In Salesforce, broad object permissions and connected services can turn one token into access across CRM records, collaboration tools, and adjacent SaaS applications.
- Named Credentials: Named Credentials are a Salesforce feature that stores authentication details outside application code and inserts them at runtime. They help avoid hardcoded secrets and endpoints, but security depends on how narrowly the endpoint and permissions are configured. Misuse can turn a convenience feature into a broad access path for attackers.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 3, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org