Salesforce security and access management are under strain

At a glance

What this is: Entro Security argues that Salesforce security is being strained by more access points, more secrets, broader privileges, and weaker auditability across human and non-human identities.

Why it matters: IAM and NHI teams need to tighten lifecycle, secrets, and authorization controls because Salesforce now behaves like a high-churn identity surface rather than a static application.

Context

Salesforce security is now an identity governance problem as much as an application security problem. When users, integrations, APIs, and automated processes all touch the same CRM data, the real question becomes which identities are allowed to act, for how long, and under what audit trail.

The article’s central concern is that the usual control model, periodic reviews plus static permissions, does not keep pace with fast-changing non-human identities. That makes secrets management, least privilege, and access certification part of the same operating model rather than separate workstreams.

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 APIs and service accounts often expand unauthorized access risk?

A: APIs and service accounts often carry broad, persistent permissions that are hard to see and easy to reuse. When authorization is weak or poorly mapped, an attacker does not need a password spray success to move through the environment. The risk rises when the same secret can reach many systems without additional checks.

Q: How do security teams know whether Salesforce access reviews are actually working?

A: Access reviews are working only if they remove stale privileges before they become usable in production. Good signals include fewer dormant service accounts, faster revocation after role or workflow changes, and audit logs that consistently match approved principals to real activity. If reviews happen but access patterns do not change, the process is cosmetic.

Q: Should organisations prioritise secrets governance or role cleanup first in Salesforce?

A: Start with the credentials that can still be used, then clean up the privilege model around them. If secrets remain exposed or long-lived, role cleanup alone will not stop misuse. If permissions are broad but unused credentials are removed, you still need to tighten the residual trust boundary.

Technical breakdown

Why Salesforce identity sprawl changes the attack surface

Salesforce environments often accumulate humans, service accounts, APIs, connected apps, and automation that all need different access semantics. That creates identity sprawl, meaning the number of distinct trust relationships grows faster than the controls used to govern them. In practice, each integration adds a new path to customer data, and each path can carry its own credentials, permissions, and logging gaps. The result is not just more access, but more difficult-to-model authorization boundaries across the CRM estate.

Practical implication: inventory every human and non-human access path before you can reason about least privilege or audit coverage.

How secrets sprawl weakens Salesforce access control

Secrets sprawl occurs when API keys, tokens, and passwords are scattered across code, metadata, and external systems instead of being centrally governed. In Salesforce settings, that matters because automation flows and service accounts often rely on long-lived credentials that are hard to track, hard to rotate, and easy to reuse across integrations. Once a secret is embedded in Apex, custom fields, or adjacent tooling, the organisation loses direct control over when it is exposed, who can reuse it, and whether it still matches the intended scope.

Practical implication: treat every stored credential as a lifecycle object with ownership, rotation, and revocation requirements.

Why quarterly access review cycles miss NHI risk

Quarterly reviews were designed for relatively stable access relationships, not for service accounts that appear, change scope, and persist through DevOps workflows. Salesforce automation can create a mismatch between what is certified and what is actually executing, especially when NHIs carry elevated permissions for integrations or business processes. That gap makes audit evidence stale before the next review cycle begins. In other words, the control plane is trying to validate a moving target using a static calendar.

Practical implication: move review and attestation closer to issuance, change events, and privilege changes rather than relying on calendar-based certification alone.

Threat narrative

Attacker objective: The objective is to reach high-value Salesforce customer and business data through identity paths that are easier to reuse, harder to monitor, and broader than intended.

1. Entry occurs through the expanding Salesforce ecosystem, where integrations, APIs, and automated processes add many credentialed paths to the platform.
2. Credential access and misuse become easier when API keys, tokens, and passwords are scattered across code, custom metadata, and external systems, especially if they are long-lived.
3. Escalation follows over-privileged accounts and broad permission sets, which widen the blast radius of any compromised human or non-human identity.
4. Impact is sustained data exposure, harder investigations, and weaker compliance evidence because audit trails and monitoring do not fully cover the access chain.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

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 identity governance is now a hybrid problem of human access, NHI lifecycle, and authorization drift. The article shows that the platform is no longer governed well by user-centric access reviews alone because service accounts, APIs, and automated workflows have become first-class identities. That shifts the operating model from periodic review toward continuous lifecycle control. Practitioners need to govern Salesforce as an identity fabric, not just an application.

Secrets sprawl is the control failure that makes Salesforce integrations persist beyond their intended trust boundary. When API keys and tokens are hardcoded, scattered, or reused, the organisation loses revocation precision and cannot reliably prove who still has usable access. This is not just poor hygiene; it is a lifecycle defect that turns every integration into a durable trust dependency. The implication is that secret ownership and offboarding must be treated as part of identity governance.

Quarterly access certification is too slow for non-human identities that change with DevOps and automation. The article’s examples show that NHI access can be created, expanded, and left in place faster than review cadences can react. That creates a governance lag in which authorised access is no longer aligned with current business need. Practitioners should assume the certification model is stale by design unless issuance and revocation are tied to change events.

Over-privileged NHI access creates an outsized blast radius because Salesforce permissions are often easier to over-grant than to precisely scope. This is especially visible in integrations that default to broad access for convenience, then remain in place long after the original use case has changed. The result is excess reach without corresponding accountability. IAM teams need to treat privilege scope as a living boundary, not a one-time setup decision.

Salesforce exposes an identity blast radius problem rather than a single-control weakness. The same weaknesses in secrets, authorization, and auditability compound across users, apps, and automation, which is why piecemeal fixes rarely hold. A better framing is to ask where one credential or permission set can cascade into broader data exposure. Practitioners should assess the platform by trust chain, not by feature list.

What this signals

Identity blast radius: Salesforce security now depends on how far one credential, role, or integration can travel across the CRM estate. When the same platform serves users, APIs, and automated workflows, the governance question becomes containment depth rather than access count.

Periodic review models do not map cleanly to NHI behaviour in CRM environments. Access that is created by automation, used by automation, and changed by automation needs lifecycle controls that trigger on issuance and scope change, not just on calendar cadence.

For practitioners

• Map every Salesforce non-human identity Inventory service accounts, API integrations, automation users, and connected apps, then assign an owner and a business purpose to each one. This is the only way to see which identities are still needed and which are legacy exposure.
• Replace long-lived secrets with short-lived tokens Move API access toward short-lived OAuth or JWT-based credentials and remove hardcoded secrets from Apex, metadata, and adjacent systems. Pair that with explicit revocation paths so an exposed credential can be retired without waiting for the next review cycle.
• Reduce standing privilege in Salesforce roles Rework role hierarchies, permission sets, and field-level access so integrations and admins hold only the minimum scope needed for current tasks. Temporary elevation should be tied to a documented use case and removed when the task ends.
• Automate access certification on change events Trigger recertification when a role, integration, or automation changes scope rather than relying on quarterly review windows. That keeps NHI access decisions closer to actual use and reduces the gap between approval and execution.
• Improve monitoring for high-risk Salesforce activity Focus alerts on data exports, unusual API calls, privilege changes, and repeated access from integrations that normally have low-volume behaviour. The goal is to distinguish normal automation from credential misuse before sensitive records leave the platform.

Key takeaways

• Salesforce security problems in this article are driven by identity sprawl, secrets sprawl, and over-privileged access across both people and machines.
• The operational risk is amplified by long-lived credentials, broad integrations, and audit processes that can lag behind actual platform activity.
• Practitioners should govern Salesforce as a living identity system, with tighter lifecycle ownership, shorter credential duration, and change-triggered reviews.

Key terms

• Identity Sprawl: Identity sprawl is the uncontrolled growth of identities, entitlements, and credentials across an environment. For NHIs, it usually appears when automation creates accounts faster than governance teams can inventory, review, and remove them. The result is hidden access, weak accountability, and a wider attack surface.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Access Certification: Access certification is the periodic review of whether an identity still needs its current entitlements. For NHIs, certification is only reliable when reviewers know the identity's owner, purpose, and expiry, otherwise stale machine access can persist long after the original use case has ended.

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.