They increase risk because they extend trust beyond the core CRM into third-party apps, collaboration tools, and low-code automations. Each connection can carry its own secrets and permissions, and those credentials are often reused or shared informally. That combination creates more exposure points and a larger blast radius if one credential is stolen.
Why Salesforce Integrations Expand NHI Risk
Salesforce becomes a risk multiplier because it rarely sits alone. Integrations often connect CRM records to marketing automation, support platforms, data pipelines, middleware, and low-code workflows, each with its own non-human identity and secret. That widens the trust boundary and makes it harder to know which account can reach which system at any moment. NHI governance guidance shows how quickly this gets out of hand: the Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties and 96% store secrets outside secrets managers in vulnerable places. For Salesforce, that means OAuth apps, API keys, and automation tokens can outlive the business need that created them.
The real issue is not just more integrations. It is more hidden authority. A connector that looks like a simple sync job may have read-write access across customer data, case history, and downstream SaaS apps. Once a token is reused, copied into code, or handed to a contractor informally, the blast radius is no longer limited to Salesforce. Current guidance from NIST Cybersecurity Framework 2.0 still applies, but the identity layer must be treated as part of the attack surface, not a back-office implementation detail. In practice, many security teams encounter the exposure only after an integration is already forwarding sensitive data to places no one can fully enumerate.
How the Risk Shows Up in Real Integrations
Most Salesforce risk emerges through the mechanics of authentication and automation rather than the CRM itself. An integration typically uses a connected app, a service account, or an OAuth grant to move data between systems. If that credential is long-lived, broadly scoped, or shared across multiple jobs, compromise of one workflow can unlock several others. NHIMG research on a real-world Salesloft OAuth token breach illustrates the pattern: a token intended for one integration became the path into Salesforce data and adjacent systems.
Practitioners should think in terms of credential lifecycle, not just access setup. Stronger patterns include:
- Assigning one secret per integration, not one shared token for many automations.
- Using least privilege and scoping OAuth grants to the exact objects and actions required.
- Preferring JIT issuance and short TTLs where the platform allows, so credentials expire after the task completes.
- Separating production, test, and vendor-facing connectors so a single compromise does not bridge environments.
- Monitoring token use, unusual API volume, and privileged admin consent changes as identity events.
That approach aligns with Top 10 NHI Issues and the NIST CSF emphasis on continuous monitoring, but it also exposes a practical gap: Salesforce estates often mix human admin access, vendor integrations, and automation accounts in ways that make clean segmentation hard to sustain. These controls tend to break down when low-code builders, managed packages, and shadow IT integrations all share the same connected app model because ownership and revocation paths become unclear.
Common Variations and Edge Cases
Tighter integration control often increases operational friction, requiring organisations to balance security against release speed, support burden, and partner coordination. That tradeoff is especially visible in Salesforce ecosystems that rely on rapid app deployment, managed packages, and external consultants. Best practice is evolving, but there is no universal standard for this yet: some teams favour per-app service identities, while others move toward workload identity, policy-as-code, and context-aware approval gates for sensitive actions. In higher maturity environments, that means authorisation is evaluated at request time rather than being assumed from a static role.
Edge cases matter. A read-only reporting connector may still become risky if it can export regulated data to another tenant. A low-code automation may be low code, but the underlying token can still create high privilege. Vendor support accounts, sandbox refreshes, and emergency break-glass integrations often escape normal review because they are seen as temporary. NHIMG analysis of breach patterns in the 52 NHI Breaches Analysis reinforces that missed rotation, overbroad access, and weak offboarding are recurring failure modes. For control design, Ultimate Guide to NHIs is useful for framing the governance baseline, while NIST Cybersecurity Framework 2.0 helps translate that into continuous risk management. The common mistake is treating each Salesforce integration as a one-time setup rather than a living identity relationship that must be reviewed, rotated, and revoked.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and SPIFFE/SPIRE set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Salesforce integrations rely on secrets that often outlive their purpose. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central to reducing integration blast radius. |
| SPIFFE/SPIRE | Workload identity is a strong fit for machine-to-machine Salesforce integrations. |
Use workload identity where possible so systems prove who they are without relying on shared static secrets.
