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.
Why This Matters for Security Teams
Salesforce is rarely the weak point by itself. The real exposure usually sits in the identities that connect it to email, ticketing, data pipelines, and automation tools. Teams tend to harden the CRM, then leave OAuth grants, shared secrets, and service accounts in place for months or years. That gap turns integration trust into a durable attack path, especially when permissions were granted for speed and never revisited. NHI Mgmt Group research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is exactly where blind spots grow fastest.
The pattern is not abstract. The Salesloft OAuth token breach shows how a token exposed outside the CRM can still be enough to reach Salesforce data, while the ASP.NET machine keys RCE attack illustrates the same broader mistake: treating a secret as harmless because it is not a human login. Current guidance aligns with NIST Cybersecurity Framework 2.0 by treating identity, access, and monitoring as one control plane rather than separate problems.
In practice, many security teams discover the issue only after an integration starts moving data in ways nobody expected.
How It Works in Practice
Secure Salesforce integration starts with inventory, not policy language. Every connected app, API client, webhook, automation account, and middleware connector should be treated as a non-human identity with its own owner, purpose, and expiry. That means classifying whether the integration uses OAuth, JWT, certificates, or stored API keys, then checking whether the credential can be rotated without breaking production. If the answer is no, the design is already too brittle.
Best practice is to separate standing access from task-based access. For lower-risk workflows, use short-lived tokens, tightly scoped RBAC, and just-in-time approval where human review is still practical. For higher-risk or autonomous workflows, current guidance suggests moving toward context-aware authorisation: the integration should only receive access at runtime, for a specific action, against a defined resource set. That is where NIST Cybersecurity Framework 2.0 and Zero Trust thinking matter, because trust is recalculated continuously rather than granted once.
- Review OAuth scopes and remove broad grants that are not operationally required.
- Bind each integration to a named business owner and a documented offboarding path.
- Rotate secrets on a schedule and test that revocation actually breaks access.
- Log token issuance, API use, and privilege changes as security events, not just admin activity.
Use the Salesloft OAuth token breach as a reminder that access via third-party OAuth apps can be enough to expose Salesforce records even when the core platform remains patched. These controls tend to break down in large, fast-changing SaaS estates because identity ownership, app sprawl, and emergency integrations outpace review cycles.
Common Variations and Edge Cases
Tighter integration control often increases operational overhead, so organisations have to balance resilience against delivery speed. That tradeoff becomes visible when teams rely on brittle middleware, vendor-managed connectors, or long-lived service principals that many downstream jobs share. In those environments, strict rotation and per-task tokens can surface hidden dependencies, and that is usually where implementation work slows down.
There is also no universal standard for this yet. Some teams can adopt short-lived credentials and workload identity quickly; others need a phased model that starts with visibility and scope reduction. For example, a high-volume sync job may need a dedicated secret with aggressive monitoring before it can move to JIT provisioning. The right question is not whether every integration can become ephemeral immediately, but which ones expose the most privilege if stolen.
The ASP.NET machine keys RCE attack is useful here because it shows how a secret can become an execution primitive when placed in the wrong trust boundary. That is the same failure mode with Salesforce integrations: once a token is reused across tools or copied into CI/CD, the blast radius expands far beyond the CRM. Organisations that reduce standing privilege, require explicit ownership, and monitor integration behaviour are usually the ones that catch abuse before it becomes data loss.
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 NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers rotation and lifecycle control for non-human credentials used in integrations. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is the core control gap in overbroad integration permissions. |
| NIST AI RMF | AI RMF governance supports ownership and accountability for autonomous integration behaviour. |
Inventory Salesforce-connected NHIs, rotate their secrets, and remove stale grants on a fixed schedule.
