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

Why This Matters for Security Teams

Broad Salesforce service account access turns a single integration principal into a high-value blast-radius problem. If that account can read large object sets, trigger automations, or call multiple downstream tools, compromise no longer stays inside one workflow. The risk is not just data exposure but business-process manipulation, because integrations often sit at the junction of CRM data, approvals, notifications, and revenue operations.

That is why NHI governance treats service accounts as attack surfaces, not convenience credentials. NHI Mgmt Group has found that only 5.7% of organisations have full visibility into their service accounts, which makes broad access especially dangerous when ownership is unclear. OWASP’s Non-Human Identity Top 10 also emphasises that over-privileged non-human identities are a recurring failure mode, not an edge case.

In practice, many security teams discover the misuse of a broad Salesforce integration only after data has already been exported, workflows have been altered, or a trusted connector has been used to pivot into connected systems.

How It Works in Practice

The safer model is to break the integration into narrowly scoped principals that each map to one use case, one data domain, and one revocation path. For Salesforce, that usually means separating read-only reporting, case synchronisation, notification automation, and write-back actions into different service accounts or connected apps. Each principal should have the minimum object, field, and API permissions required for that task, plus explicit restrictions on where it can authenticate from and what downstream actions it can trigger.

Current guidance suggests treating this as a lifecycle problem, not just an access-control problem. When the integration is owned by a business process, the owner should be able to answer what it does, what data it touches, and how it is disabled. That aligns with the incident patterns seen in 52 NHI Breaches Analysis and with the pattern behind the Salesloft OAuth token breach, where a trusted integration path became a data access vector.

• Use separate principals for separate business functions, not one shared integration identity.
• Prefer short-lived secrets or token-based auth over long-lived static credentials.
• Log each principal’s actions to a specific owner and ticketable change record.
• Review object, field, and API scope regularly, especially after workflow changes.
• Revoke unused credentials immediately when a use case is retired or replaced.

These controls tend to break down when one service account is reused across multiple Salesforce orgs and downstream SaaS tools because ownership, scope, and revocation all become ambiguous at the same time.

Common Variations and Edge Cases

Tighter scoping often increases operational overhead, requiring teams to balance blast-radius reduction against integration sprawl. That tradeoff is real, especially in older Salesforce estates where one account has accumulated permissions over years of automation changes. Best practice is evolving, but there is no universal standard for when to split a service account versus when to retain one identity with stronger conditional controls.

In low-risk read-only use cases, a narrowly scoped account with strong monitoring may be sufficient. In write-heavy or cross-system workflows, however, a shared account is usually the wrong pattern because compromise can alter records, approvals, and notifications at scale. This is where NHI guidance and process governance need to meet: the Ultimate Guide to NHIs — Key Challenges and Risks is explicit that excessive privilege and poor visibility are the conditions that turn routine integrations into systemic exposure.

There is no universal standard for this yet, but the practical rule is simple: if a compromise of one Salesforce credential would let an attacker move laterally, the account is too broad.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on standing access for high-risk roles?
• What breaks when gateway integrations use different auth patterns for each service?
• What breaks when agents are given personal access tokens and service account keys directly?
• What breaks when agent access is treated like a normal service account?