Topic starter
03/06/2026 7:27 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Entro Security: “Challenges of non-human Identities in Salesforce”.
By the numbers:
- 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.
Key questions
Q: What breaks when Salesforce integrations rely on shared non-human credentials?
A: Shared machine credentials break ownership, traceability, and offboarding.
Q: Why do overprivileged Salesforce service accounts create disproportionate risk?
A: Because a single machine identity can carry access across many objects and workflows.
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.
Practitioner guidance
- 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.
Bottom line: Salesforce-connected NHIs create a wider governance gap than most teams expect, because integrations and tokens can persist outside normal user lifecycle controls.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
03/06/2026 7:30 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Salesforce non-human identity sprawl exposes a broader control gap
This post was modified 1 day ago by NHI Mgmt Group