Salesforce security and access management are under strain

At a glance

What this is: This is a Salesforce security analysis showing how growing integrations, secrets sprawl, and over-privileged access create governance gaps for both human users and non-human identities.

Why it matters: It matters because IAM, PAM, and NHI programmes must now govern Salesforce access as a living system, not a static role model, if they want to limit blast radius and preserve auditability.

👉 Read Entro Security's analysis of Salesforce authorization and access management

Context

Salesforce security is really an identity and authorization problem: as more humans, service accounts, APIs, and automated workflows touch the platform, the number of decisions about who or what can act keeps rising. In that environment, static permissions and periodic reviews no longer describe the real risk boundary for Salesforce security.

The platform becomes harder to govern because the same integration sprawl that enables business agility also increases secrets exposure, privilege creep, and audit gaps. For IAM and NHI teams, the question is no longer whether access exists, but whether every access path is attributable, scoped, and reversible.

Key questions

Q: What breaks when Salesforce integrations rely on broad service account access?

A: Broad service account access breaks containment. When one integration credential can read large parts of Salesforce or trigger multiple workflows, a single compromise can expose customer data, alter business processes, and persist across connected systems. The safer pattern is to scope each principal to one use case, one owner, and one revocation path.

Q: Why do Salesforce environments make secrets management harder than many other SaaS platforms?

A: Salesforce environments spread credentials across code, metadata, external systems, and automation chains, which makes inventory and rotation difficult. The problem is not only storage, but duplication and ownership drift. If teams cannot tell where a token lives or who depends on it, they cannot reliably rotate it or prove it was removed.

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: Who is accountable when a Salesforce integration is over-privileged and causes data exposure?

A: Accountability should sit with the business owner of the integration, the identity team that approved the scope, and the platform team that failed to constrain it. Shared responsibility does not mean shared ambiguity. Every high-risk integration needs a clear owner, an expiry or review trigger, and an auditable approval chain.

Technical breakdown

Secrets sprawl in Salesforce integrations

Salesforce environments often distribute credentials across Apex classes, custom metadata, external systems, and CI or integration workflows. That creates secrets sprawl, where the same token or API key may be copied into multiple places and rotated inconsistently. Hardcoded credentials are especially dangerous because they often survive deployment changes and are difficult to inventory. In NHI terms, the problem is not only exposure, but the inability to prove where a credential exists and which workflow still depends on it. That makes containment slow and revocation risky.

Practical implication: centralise credential inventory and remove hardcoded secrets before you rely on them in production integrations.

Over-privileged access and Salesforce permission design

Salesforce commonly forces teams into broad permission sets because fine-grained access is complex to model across profiles, fields, records, and automation. The result is privilege creep, where NHIs and users accumulate access beyond their actual task scope. For service accounts and API users, the risk is amplified because long-lived permissions often outlast the use case that justified them. Least privilege in this context is not a slogan; it is the difference between a contained integration and one compromised credential exposing large customer datasets.

Practical implication: redesign integrations so each account, token, or API client has the smallest possible scope for the shortest possible duration.

Why audit trails and monitoring break down

Salesforce monitoring becomes difficult when high-volume automation, external integrations, and human activity all generate similar-looking events. Quarterly access reviews are too blunt to catch short-lived misuse, and out-of-the-box logging often misses the context needed to distinguish legitimate automation from abuse. The technical challenge is attribution across a distributed identity chain, especially when one automation triggers another. Without reliable logs, security teams cannot easily reconstruct whether an action came from a person, a service account, or an integration path.

Practical implication: correlate event monitoring with identity context so that every high-risk action can be traced to a specific principal and approval path.

Threat narrative

Attacker objective: The attacker wants durable access to Salesforce data and automation paths that can be used for surveillance, exfiltration, or downstream abuse.

1. Entry occurs through exposed or hardcoded Salesforce credentials, often embedded in integrations, Apex code, or external automation flows.
2. Credential access turns into standing privilege abuse when the token or service account carries broad permissions that were never tightly scoped to a single workflow.
3. Impact follows through data exfiltration, covert manipulation of automation, or long-term persistence across connected apps and business processes.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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 security is really a non-human identity governance problem with human spillover. The article is clear that APIs, service accounts, and automated workflows now sit beside users in the same trust boundary. That means IAM teams cannot treat Salesforce as a pure SaaS access problem, because authorization failures increasingly begin with NHIs that are over-scoped, under-monitored, and hard to retire cleanly. The practitioner conclusion is that Salesforce governance has to be designed around principal type, not just application tier.

Secrets sprawl is the named failure mode hiding inside many Salesforce integrations. Credentials are spread across Apex, metadata, external systems, and automation layers, which creates persistence even when individual accounts are rotated. This is exactly the kind of lifecycle weakness OWASP-NHI is meant to surface, because the real issue is not the existence of secrets but their uncontrolled duplication and unclear ownership. The practitioner conclusion is that every integration path must have one accountable owner and one authoritative credential source.

Least privilege in Salesforce breaks when teams use broad access to compensate for modelling complexity. The article shows how convenience drives all-or-nothing permissions, especially for integrations and automated workflows. That is a governance pattern, not just a configuration issue: the access model becomes too coarse to support real accountability, so blast radius expands by design. The practitioner conclusion is to treat broad permission sets as a risk signal, not a normal operating state.

Quarterly access reviews are too slow for the way Salesforce abuse actually happens. The article notes that months can pass before unauthorized access or data leakage is noticed, which is a classic lifecycle blind spot. NIST CSF style governance depends on detection and response loops that can keep up with operational change, and Salesforce automation often outruns those loops. The practitioner conclusion is that review cadence must be tied to identity change events, not calendar cycles.

Salesforce’s real security challenge is identity blast radius, not just authorization failure. The combination of integrations, broad permissions, and sparse monitoring means a single compromised NHI can reach far beyond the original entry point. That makes CRM security a governance discipline about limiting how far one principal can move, read, or trigger downstream actions. The practitioner conclusion is to measure the maximum damage any one Salesforce principal could cause today, then reduce it systematically.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed, 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to the same report.
• For deeper lifecycle context, review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs alongside this Salesforce analysis.

What this signals

Salesforce teams should expect identity governance to move closer to application operations, because the boundary between business workflow and machine access is already collapsing. Identity blast radius: a single API client or service account can now become the shortest path from a harmless integration to broad data exposure. That is why entitlement scope, not just authentication strength, will determine whether Salesforce remains governable.

When organisations rely on long-lived integration credentials, they inherit the same problem pattern seen across broader NHI sprawl. The security programme should watch for duplicated secrets, shared API users, and stale scopes in connected apps, then map those patterns into a control plan that aligns with the OWASP Non-Human Identity Top 10.

The practical shift is toward event-driven governance, not review theatre. If access changes, integrations appear, or permissions expand, the identity workflow should react immediately, because delayed certification leaves Salesforce exposed to the same breach conditions documented across NHIs and workload identity environments.

For practitioners

• Consolidate Salesforce credential ownership Assign every API key, token, and certificate to a named owner and a single authoritative source of truth. Remove duplicates across Apex classes, metadata, and external stores so rotation and revocation happen once, not in scattered copies.
• Break broad integration accounts into narrow principals Create separate service accounts or OAuth clients for each integration and scope them to the minimum objects, fields, and records they require. Avoid shared “all purpose” API users that turn one compromise into platform-wide access.
• Replace calendar-based reviews with change-triggered governance Trigger recertification when a role changes, an integration is added, a scope expands, or a credential is rotated. Quarterly reviews alone leave too much time for stale access to persist in Salesforce.
• Correlate Event Monitoring with identity context Tie high-risk actions to the exact human user, service account, or integration path that initiated them. Focus alerting on exports, mass reads, permission changes, and unusual API call patterns.
• Shorten token lifetime where automation permits Use short-lived OAuth or JWT-based credentials for integrations that can tolerate them, and retire long-lived tokens wherever possible. The goal is to reduce the window in which a leaked credential remains useful.

Key takeaways

• Salesforce security failures often start with non-human identities that are over-scoped, duplicated, and hard to retire.
• Quarterly access reviews and coarse permission sets are too slow and too blunt for modern Salesforce automation.
• The strongest control move is to reduce identity blast radius by tightening scopes, centralising credentials, and tying governance to change events.

Key terms

• Secrets Sprawl: Secrets sprawl is the uncontrolled spread of credentials across code, configuration, automation, and external systems. In Salesforce environments, it makes rotation, revocation, and ownership tracking difficult because no single place tells you where a token lives or who still depends on it.
• Identity Blast Radius: Identity blast radius is the amount of damage one compromised principal can cause. In Salesforce, it is shaped by permission scope, connected workflows, and downstream integrations, so a single service account can expose far more than the function it was meant to support.
• Event-Driven Governance: Event-driven governance is access management that responds to real change, not calendar cycles. For Salesforce and other NHI-heavy systems, it means triggering reviews and controls when roles, scopes, integrations, or credentials change, rather than waiting for quarterly certification windows.
• Non-Human Identity: A non-human identity is a digital principal used by software, automation, or workloads to access systems and data. It includes service accounts, API keys, tokens, and certificates, and it needs lifecycle controls just as much as human identities do.

What's in the full article

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

• Step-by-step guidance on OAuth 2.0 and JWT flows for Salesforce integrations.
• Practical examples of rotating service-account credentials across connected apps and automation tools.
• Implementation detail for field-level security, record-level security, and Salesforce Shield usage.
• Monitoring patterns for Event Monitoring dashboards and anomaly detection across API activity.

👉 The full Entro Security blog covers Salesforce-specific access controls, monitoring detail, and secret handling patterns.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.