How should security teams govern non-human identities in Salesforce?

Why This Matters for Security Teams

Salesforce is often treated as a business platform first and an identity surface second, but that view misses how much trust lives inside connected apps, integration users, OAuth grants, named credentials, and API tokens. Those non-human identities can read cases, move data, trigger workflows, and reach downstream systems. When privilege is broad or undocumented, a single compromised integration can become a high-speed path from a vendor foothold to customer data exposure.

Security teams should govern Salesforce NHIs as operational identities with owners, purpose limits, and revocation paths, not as informal technical plumbing. That means continuous inventory, scope review, and lifecycle controls tied to business justification, not just annual access recertification. Current guidance from NHI practitioners also points to the same failure pattern seen across other ecosystems: secrets and tokens stay live long after the integration that created them has changed. The State of Non-Human Identity Security shows that lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, which is a strong warning for Salesforce environments where integrations are rarely simple or static.

Practitioners should also align this work with the NIST Cybersecurity Framework 2.0 by mapping Salesforce identities into asset, access, and recovery processes. In practice, many security teams encounter NHI misuse only after a breached integration has already been used to export data or extend trust to another system, rather than through intentional design.

How It Works in Practice

Effective Salesforce governance starts by separating identity types that are frequently blended together: service accounts, OAuth connected apps, API-only users, named credentials, certificates, and refresh tokens. Each should have an accountable owner, a documented business purpose, and a defined expiry or review date. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because the operational problem is not just discovery, but lifecycle discipline: provision, monitor, rotate, revoke, and offboard.

A practical program usually has five steps:

• Build a complete inventory of Salesforce NHIs, including any integration users hidden behind middleware or automation tools.
• Map each identity to the exact objects, APIs, and workflows it touches, then remove any privilege that is not needed for the stated use case.
• Require short-lived secrets where possible, and rotate long-lived tokens on a fixed schedule with emergency revocation procedures.
• Monitor for abnormal access paths, such as unusual API volume, new login geography, or access to data outside the integration’s normal scope.
• Tie deprovisioning to change management so retired apps, vendors, and automations lose access immediately.

This is also where broader attack lessons matter. The Salesloft OAuth token breach demonstrates how stolen integration trust can be used to reach Salesforce data without needing a traditional user compromise. For standards alignment, the NIST Cybersecurity Framework 2.0 supports this approach through asset management, access control, and recovery discipline. These controls tend to break down when Salesforce is federated across many business units because ownership, token sprawl, and change velocity make revocation slower than the business expects.

Common Variations and Edge Cases

Tighter token control often increases operational overhead, requiring organisations to balance integration reliability against the need to reduce standing trust. That tradeoff becomes more visible in complex Salesforce environments where middleware, sandbox promotion, partner integrations, and automation tools all depend on persistent credentials. There is no universal standard for this yet, but current guidance suggests treating high-risk integrations differently from low-risk internal automations and applying stronger review cadence to anything that can export customer data or write to privileged objects.

One common edge case is managed packages and third-party apps that introduce opaque trust chains. Security teams may not be able to inspect every downstream action, so the safer pattern is to constrain scopes, segregate data domains, and force business approval for each externally connected app. Another edge case is emergency operations, where a break-glass integration is needed for incident response. That should be an exception with explicit logging, short TTL, and post-use review rather than a standing permanent exception.

For audit and defensibility, the Ultimate Guide to NHIs — Regulatory and Audit Perspectives helps frame evidence collection around ownership, approvals, and revocation. The Top 10 NHI Issues is also relevant when teams need to explain why visibility gaps and weak rotation are not minor hygiene issues but core control failures. For many Salesforce programs, the hardest problem is not policy design but proving that every active token still belongs to a real business need.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern non-human identities in cloud environments?