Salesforce non-human identity sprawl exposes a broader control gap

At a glance

What this is: The article argues that Salesforce environments expand the non-human identity attack surface through integrations, long-lived tokens, and over-privileged service accounts.

Why it matters: This matters because IAM, PAM, and NHI programmes must govern machine identities in Salesforce with the same discipline used for user access, or risk broad data exposure and lateral movement.

By the numbers:

• 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.
• 71% year-over-year increase in cyberattacks that used stolen or compromised credentials.
• Compromised credential attacks can also be costly for organizations, accounting for an average of $4.81 million per breach.

👉 Read Entro Security's analysis of non-human identity risks in Salesforce

Context

Salesforce security is not just an application problem. In practice, it is an identity governance problem shaped by service accounts, API keys, OAuth tokens, and connected apps that can widen access far beyond the CRM itself. The article centres on non-human identities in Salesforce and the way third-party integrations can turn a controlled platform into a distributed access graph.

The governance gap is that many teams still treat Salesforce access as if it were primarily a human-user control problem. Once integrations, low-code extensions, and shared secrets enter the picture, lifecycle review, privilege scoping, and offboarding need to cover machine identities as first-class subjects, not exceptions.

Key questions

Q: How should security teams govern non-human identities in Salesforce environments?

A: Treat every API user, OAuth token, named credential, and connected app as a governed identity with an owner, scope, and expiry. Inventory them continuously, restrict permissions to task scope, and revoke unused access quickly. Salesforce becomes safer when machine identities are managed as lifecycle objects, not as hidden implementation details.

Q: Why do service accounts and tokens create more risk than many teams expect?

A: Because they often carry standing privilege, operate quietly, and remain valid long after the business need changes. That combination increases blast radius when a credential is exposed and makes detection harder than with human accounts. The risk is not the token itself. It is the duration and breadth of access it enables.

Q: What do organisations get wrong about Salesforce integration security?

A: They often secure the platform but ignore the identities that connect it to other systems. Shared secrets in collaboration tools, forgotten OAuth tokens, and misassigned permissions all widen exposure beyond the CRM. Strong governance requires reviewing integrations as access pathways, not just as application features.

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.

Technical breakdown

Why Salesforce integrations turn machine identities into a governance problem

Salesforce integrations rely on machine identities such as OAuth clients, API users, webhook secrets, and named credentials to move data between systems. These identities are often long-lived and highly privileged because they must support automated workflows, but that durability makes them harder to govern than human access. The real risk is not the platform itself. It is the accumulation of access paths across AppExchange apps, low-code customisations, and shared collaboration channels where credentials are exchanged. Once a secret is copied into email, Slack, or Jira, the control boundary is already weakened.

Practical implication: Inventory every non-human identity connected to Salesforce and treat each integration as a governed access relationship.

How over-privileged API users create latent blast radius

The article points to API users with permissions such as Modify All Data and to service accounts lacking IP restrictions or MFA. That is a classic standing-privilege problem. When a machine identity has broader rights than the task requires, compromise is not contained to one action or one object. It becomes a platform-wide exposure that can affect CRM records, contract workflows, and downstream SaaS systems. In Salesforce, privilege is especially sensitive because integrations often need cross-object and cross-system access to function, which makes precise scoping more important, not less.

Practical implication: Map every machine account to a specific business function and remove permissions that are not essential to that function.

Why token rotation and lifecycle management fail when secrets are forgotten

The article describes outdated OAuth tokens, inactive named credentials, and forgotten integrations that remain valid long after they should have been reviewed. This is a lifecycle failure, not just a detection failure. If teams cannot identify who owns a credential, when it was last used, or which systems still depend on it, they cannot rotate or revoke it with confidence. That leaves dormant access available for lateral movement or unauthorized data exchange. In identity terms, the control gap is the absence of authoritative ownership and expiration discipline for machine identities.

Practical implication: Tie each token or credential to an owner, an expiry rule, and a revocation path before allowing it into production.

Breaches seen in the wild

• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 a first-order identity governance issue, not a platform hygiene issue. The article shows how API keys, OAuth tokens, service accounts, and low-code integrations expand the access surface beyond the CRM boundary. That means identity teams cannot treat Salesforce as a single application with a few administrative roles. They must treat it as a connected NHI ecosystem with its own lifecycle, privilege, and offboarding risks. The practitioner conclusion is simple: govern the identities around Salesforce as carefully as the data inside it.

Shared-secret workflows create trust debt that accumulates faster than review cycles. The article describes credentials being exchanged in collaboration tools and reused across integrations, which creates persistent exposure even when the underlying app is legitimate. This is a structural problem for NHI governance because the access relationship outlives the original transaction. The implication is that teams need to question any operating model that depends on secrets remaining private across people, tools, and time.

Modify All Data permissions in machine accounts are an identity design failure, not an anomaly. When service identities are granted broad object and record rights to keep business processes moving, the platform becomes hard to secure by exception handling. That pattern weakens least privilege and makes blast-radius control impossible to reason about in advance. The practitioner takeaway is to redesign entitlement patterns around task scope, not operational convenience.

Lifecycle governance for Salesforce integrations must assume forgotten credentials will exist. The article’s examples of outdated OAuth tokens and inactive named credentials match the broader NHI pattern where access persists long after its business purpose ends. That is why offboarding, recertification, and ownership assignment matter for machine identities just as much as for human access. Teams should treat dormant credentials as expected debt, not exceptional noise.

Salesforce exposes the NHI market’s central tension: automation increases business value while making access governance more distributed. The more business processes rely on integration identities, the more identity security must move upstream into provisioning, review, and revocation discipline. This does not mean automation is the problem. It means the control model must keep pace with the number of identities and the breadth of their reach. Practitioners should expect NHI governance to become a core Salesforce security requirement, not a specialised add-on.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• In the same research, 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• That pattern makes the next step clearer: the Top 10 NHI Issues resource is useful for turning Salesforce secret exposure into a broader governance programme.

What this signals

Shared-secret sprawl is now a board-level identity risk. When service identities move through Salesforce, Slack, email, and Jira, the practical control problem is not just rotation. It is whether the organisation can prove ownership, scope, and revocation across every handoff. Teams that cannot do that will keep discovering access after it should already have died.

5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs, which explains why Salesforce integrations so often outgrow manual review. The governance signal is not that teams need more dashboards. It is that they need an identity model that treats machine access as a continuously changing inventory.

Identity blast radius is the right way to think about Salesforce now. As integrations multiply, the question becomes how far a single compromised token can travel across CRM data, collaboration tools, and adjacent SaaS services. Practitioners should prepare for policies that link discovery, ownership, rotation, and offboarding instead of treating them as separate tasks.

For practitioners

• Inventory every Salesforce machine identity Build a complete register of service accounts, API users, OAuth clients, named credentials, and third-party integrations. Record owner, business purpose, permissions, last use, and revocation path so that no credential exists without accountability. Use the Ultimate Guide to NHIs as the reference model for lifecycle governance.
• Remove standing privilege from integration accounts Replace broad entitlements such as Modify All Data with task-scoped access where possible. Review object, record, and API permissions separately, and use least privilege to reduce the blast radius of a compromised token.
• Shorten the lifespan of shared secrets Rotate OAuth tokens, API keys, and webhook secrets on a defined schedule, then revoke unused credentials immediately. Pair rotation with ownership checks so expired or inactive credentials do not remain silently valid.
• Separate human and machine permissions in Salesforce Audit permission sets that were intended for integrations but were assigned to people, and vice versa. This prevents accidental overexposure and keeps operational access aligned with the identity type actually using it.
• Use external guidance for zero-trust control mapping Map Salesforce access patterns to the NIST Cybersecurity Framework 2.0 and the Ultimate Guide to NHIs so that discovery, protection, detection, and revocation are linked to real identity ownership.

Key takeaways

• Salesforce security weakens quickly when machine identities are treated as implementation details instead of governed access subjects.
• Long-lived tokens, over-privileged service accounts, and shared secrets create blast radius that conventional user-centric IAM reviews miss.
• Practitioners should focus on inventory, scope reduction, rotation discipline, and revocation paths for every Salesforce integration identity.

Key terms

• Non-Human Identity: A non-human identity is any digital identity used by software, infrastructure, or automation rather than a person. In Salesforce ecosystems that includes service accounts, API keys, OAuth tokens, webhook secrets, and integration identities. These identities must be governed for ownership, privilege, and lifecycle just like human accounts.
• Standing Privilege: Standing privilege is access that remains permanently available instead of being granted only when needed. For machine identities, it often appears as broad API rights or long-lived tokens that continue to work after the original task has ended. The result is unnecessary blast radius and weaker offboarding discipline.
• Blast Radius: Blast radius is the amount of damage an attacker or failure can cause after compromising one identity or control point. In Salesforce, a single over-privileged token can expose CRM data, contracts, collaboration content, and connected applications. Smaller blast radius is the practical goal of least privilege and short-lived access.
• Lifecycle Governance: Lifecycle governance is the discipline of provisioning, reviewing, rotating, and revoking identities across their useful life. For non-human identities, it requires clear ownership, usage tracking, and disposal rules so credentials do not persist after the business purpose ends. Without lifecycle governance, dormant access becomes a predictable security debt.

What's in the full article

Entro Security's full blog covers the operational detail this post intentionally leaves for the source:

• Examples of Salesforce permission sets and API account patterns that commonly create overexposure.
• The classification logic Entro uses to identify service accounts, OAuth tokens, and other machine identities at scale.
• Platform-specific blind spots around outdated tokens, inactive named credentials, and misconfigured third-party integrations.
• How Entro detects unusual usage patterns in Salesforce environments after discovery.

👉 Entro Security's full post covers the Salesforce exposure patterns, blind spots, and machine identity controls in more detail.

Deepen your knowledge

Salesforce non-human identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for integrations, secrets, and service accounts, it is a practical place to start.