They should use one governance view for licences, access reviews, configuration drift, and evidence collection. That allows cost, security, and compliance teams to work from the same entitlement reality rather than separate reports. The result is faster remediation and fewer blind spots in audit preparation.
Why This Matters for Security Teams
Salesforce governance fails when IAM and compliance operate from different evidence sets. IAM teams usually see who can authenticate, while compliance teams need proof of licence assignment, privileged access, configuration drift, and control operation over time. Those are not separate problems in practice. They are one entitlement and control-reality problem, especially when service accounts, connected apps, and admin roles change faster than review cycles.
The operational risk is not just over-provisioning. It is also missed audit evidence, delayed remediation, and unclear ownership when a permission set or integration is granted outside the normal workflow. Current guidance suggests treating Salesforce as a governed access surface, not a static application list. NIST Cybersecurity Framework 2.0 reinforces that access governance must connect identification, protection, detection, and continuous improvement rather than live in periodic spreadsheets alone, and NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives frames the same issue through auditability and accountability.
In practice, many security teams encounter Salesforce entitlement drift only after a licence true-up, an audit request, or an account misuse investigation has already exposed it.
How It Works in Practice
The most effective model is a shared governance view that merges identity, entitlement, and compliance signals into one operating picture. IAM owns the authoritative access inventory. Compliance defines the evidence requirements and control mappings. Security operations validates exceptions, while platform owners confirm whether a permission set, profile, connected app, or admin change is still justified.
That shared view should include:
- Licence usage and unused assignment tracking, so compliance can distinguish cost waste from control failure.
- Periodic access review outputs for human admins and non-human integrations, with reviewer attestations tied to business ownership.
- Configuration drift monitoring for high-risk settings such as external sharing, session policies, and privileged permission changes.
- Evidence collection that captures who approved access, when it changed, and whether it was later revoked or remediated.
For non-human access, the same discipline applies to OAuth-connected apps and automation accounts. NHIMG’s Salesloft OAuth token breach illustrates why tokens, scopes, and connected-app trust need review alongside user entitlements. The relevant control question is not only “who has access?” but also “what can this identity do, under which conditions, and how is that proven later?” NIST CSF 2.0 supports this lifecycle view by linking governance and monitoring to risk treatment, not just provisioning.
Where this works best is when access reviews, change management, and audit evidence all reference the same entitlement record. These controls tend to break down in highly federated Salesforce environments with many business units, because ownership splits across teams and exceptions accumulate faster than reviewers can reconcile them.
Common Variations and Edge Cases
Tighter Salesforce governance often increases operational overhead, so organisations must balance audit strength against admin effort and business agility. Best practice is evolving here: there is no universal standard for how often every permission set, connected app, or integration should be reviewed, and the right cadence depends on data sensitivity and change velocity.
One common edge case is delegated administration. It can improve responsiveness, but it also fragments accountability if local admins can create exceptions without central visibility. Another is licence optimization. Reducing unused licences may look like a finance-only exercise, yet it can reveal dormant accounts or orphaned access that compliance should treat as control failures. For environments with heavy automation, governance should also include machine-to-machine access paths, not just named users, because the audit trail needs to show why the integration exists and who owns it.
NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and Top 10 NHI Issues are useful references when compliance teams need to extend governance beyond human users into secrets, tokens, and service identities. The practical test is simple: if a reviewer cannot explain the business purpose, approval path, and revocation trigger for an access item, the control is not complete.
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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Shared governance needs clear oversight, ownership, and accountability. |
| NIST CSF 2.0 | PR.AA-01 | Salesforce access must be authenticated and tied to authoritative identity records. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Tokens and connected apps in Salesforce need rotation and lifecycle control. |
Assign one owner for Salesforce access, drift, and evidence so reviews map to an accountable governance process.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
