NHI Security in Salesforce is the practice of controlling and monitoring non-human access to Salesforce data, functions, and integrations. It covers service accounts, connected apps, API tokens, OAuth grants, and automation identities, using least privilege, strong authentication, secret rotation, logging, and lifecycle governance to reduce misuse, overreach, and compromise.
What NHI Security in Salesforce Covers
NHI security in Salesforce is not just account hygiene, it is the control of machine-access paths that can read CRM data, invoke objects, trigger workflows, and move through connected apps, APIs, and automation. The core problem is that non-human access often looks legitimate unless ownership, scope, and lifecycle are explicit.
In practice, the subject includes service accounts, integration users, OAuth grants, refresh tokens, API tokens, and connected apps. Those identities can become durable entry points when they are shared, over-scoped, or left in place after the integration or automation they support has changed.
Why Salesforce NHI Access Becomes Risky
Salesforce is attractive because it concentrates customer data, operational workflows, and downstream integrations in one platform. When a non-human identity is compromised or over-privileged, the impact can extend beyond a single object or API call into records, exports, automations, and external systems linked through the same trust relationship.
Service accounts and OAuth-based integrations are especially sensitive because they often bypass interactive user controls. If the same credential or grant is reused across environments, or if consent is granted broadly, the blast radius can include data exposure, unauthorized automation, and difficult-to-trace persistence.
How Organisations Govern and Monitor These Identities
The first step is inventory. Organisations need to know which connected apps, tokens, service accounts, and automation identities exist, who owns them, what data they touch, and whether they are still required. The most common failure is not a sophisticated exploit, but an undocumented integration that nobody actively manages.
Least privilege, short-lived access where possible, secret rotation, and explicit ownership are the practical controls that matter most. Salesforce-specific hardening should also include review of connected app scopes, permission sets, login activity, event monitoring, and any integration path that can export or modify CRM data. For a deeper Salesforce-oriented control view, see Salesforce Security Guide.
Lifecycle Control and Offboarding for Salesforce Non-Human Identities
Lifecycle governance is what prevents stale access from becoming permanent access. Every non-human identity in Salesforce should have a defined owner, a purpose, a renewal or review cycle, and a retirement path when the integration, app, or automation is decommissioned.
That discipline matters because Salesforce environments often accumulate legacy connected apps, old OAuth grants, and long-lived tokens that continue to work long after the business process they support has moved on. The most effective programmes treat non-human identity review as an ongoing operational control, not a one-time cleanup.
Risk and Threat Considerations
Compromised Salesforce non-human identities can be used for silent data extraction, permission abuse, or trust-chain abuse through third-party integrations. Because these identities often authenticate without a human prompt, attackers may gain durable access that survives password resets and is harder to spot in normal user review.
Failure mechanism: Stolen tokens, excessive scopes, shared integration credentials, or abandoned connected apps create a trusted path into CRM data and automation, then let an attacker operate through legitimate API and workflow channels.
Impact: CRM theft, customer-data exposure, fraudulent automation, and lateral movement into other SaaS services or linked business processes can follow, especially when the same grant or secret is reused across environments.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Salesforce NHI access often relies on tokens and shared secrets. |
| NHI-05 — Overprivileged NHI | Connected apps and service accounts commonly exceed their needed Salesforce scope. | |
| NHI-07 — Long-Lived Secrets | OAuth grants and API tokens can persist far longer than the business need they support. | |
| Recommendation — Reduce exposed Salesforce access by protecting and rotating integration secrets. Review Salesforce integration scopes and remove excess permissions from non-human identities. Replace durable Salesforce credentials with shorter-lived or tightly governed access where possible. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Salesforce machine access depends on managing tokens, secrets, and credential lifecycle. |
| Recommendation — Enforce rotation, revocation, and secure storage for Salesforce authenticators and secrets. | ||
Practitioner Guidance
Why practitioners should care: Salesforce NHI security is a governance problem as much as a technical one. If ownership, scope, and expiry are unclear, you cannot reliably tell which machine-to-machine paths are legitimate and which are risk accumulators.
What to watch for: Long-lived OAuth grants, integration accounts with broad read or export permissions, connected apps with little recent use, and service identities that no one can clearly name as the owner or business purpose. Those are usually the signals that review and cleanup are overdue.
Practitioner takeaway: Treat every Salesforce non-human identity as a managed access relationship with an owner, a scope, and an end date, not as a permanent infrastructure convenience.