You should be able to name every machine identity, show who owns it, explain why it exists, and prove when it was last reviewed or rotated. If a credential cannot be tied to a business purpose and a revocation path, governance is incomplete. Visibility and ownership are the clearest signals of control.
Why This Matters for Security Teams
In Salesforce, nhi governance is only real if machine identities are discoverable, attributable, and reversible. That means each connected app, integration user, OAuth token, certificate, or API key needs a named owner, a stated business purpose, and a review cadence that can be audited. Without that, access may look functional while remaining effectively unmanaged. NIST’s NIST Cybersecurity Framework 2.0 is clear that identification, protection, detection, and recovery all depend on asset visibility and accountability, which is exactly where NHI programs tend to fail.
That failure is not theoretical. NHIMG research in the State of Non-Human Identity Security shows that only 1.5 out of 10 organisations are highly confident in securing NHIs, and 85% lack full visibility into third-party vendors connected via OAuth apps. In Salesforce, that matters because many of the riskiest credentials are not owned by the platform team at all. They live in revocable integrations, vendor automations, and stale service accounts that continue to work long after the original business need has faded. Practitioners should also review the Top 10 NHI Issues to benchmark the control gaps that usually show up first.
In practice, many security teams discover poor NHI governance only after an OAuth app, token, or integration user has already been abused, rather than through intentional review.
How It Works in Practice
Working governance in Salesforce starts with an inventory that is specific enough to answer three questions: what is the identity, who owns it, and what does it need to do. That inventory should cover integration users, connected apps, API tokens, certificates, sandbox-to-production links, and any automation that can act without human approval. Best practice is to tie each item to a business service, a technical owner, a renewal or rotation date, and a revocation path. The Ultimate Guide to NHIs explains the lifecycle approach, while the Ultimate Guide to NHIs — Regulatory and Audit Perspectives shows how that lifecycle becomes evidence for audit and accountability.
Operationally, governance improves when reviews are event-driven, not just calendar-driven. A new integration, a permissions change, a team handoff, or a vendor offboarding event should trigger a validation of scope, ownership, and secret freshness. If the credential is long-lived, it should be justified; if it can be short-lived, it should be issued just in time and revoked automatically. That is especially important for Salesforce because connected apps often accumulate delegated permissions that outlive their original use case. NIST CSF 2.0 helps frame this as governance and recovery discipline, but the control plane has to make it concrete: RBAC for administrators, least privilege for service accounts, and a documented path to disable access without breaking the business.
- Map every Salesforce machine identity to a named owner and system purpose.
- Separate human admin access from non-human execution access.
- Rotate secrets on a defined schedule and after every ownership change.
- Review scopes for OAuth apps and remove anything not needed for the current task.
- Test revocation so a compromised credential can actually be cut off.
These controls tend to break down when multiple business units share one integration account because ownership, scope, and revocation become politically unclear.
Common Variations and Edge Cases
Tighter credential control often increases operational overhead, requiring organisations to balance access stability against the speed of Salesforce automations. Some teams accept longer-lived credentials for critical batch jobs, but current guidance suggests that exception should be narrow, documented, and reviewed more often than standard access. There is no universal standard for this yet, especially where vendor-managed apps or legacy middleware cannot support short-lived tokens without rework.
Edge cases usually appear in outsourced integrations, citizen-developed automations, and sandbox pipelines. A vendor may own the software but not the business risk, while a low-code builder may create a credential that works but is never formally registered. The result is a governance blind spot that looks compliant until a review asks for ownership and revocation evidence. NHIMG’s Salesloft OAuth token breach is a practical reminder that delegated access can become the attack path, not just the convenience layer. For broader patterns, the 52 NHI Breaches Analysis is useful when explaining why apparently minor integration sprawl turns into material exposure.
Where Salesforce governance also covers AI-driven workflow agents, the question expands from access review to intent review: the system must prove what it is allowed to do at runtime, not just what it was granted at setup. That is where present-day practice is still evolving.
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 lifecycle control and rotation of non-human credentials. |
| NIST CSF 2.0 | PR.AC-1 | Addresses identity proofing and access governance for managed identities. |
| NIST AI RMF | Supports governance and accountability for autonomous or AI-driven access behavior. |
Use AI RMF governance practices to document intent, oversight, and revocation for automated Salesforce actions.
