Treat Salesforce licences as access entitlements, not just software purchases. Map each licence type to a role, review usage regularly, and revoke or reassign access when users change jobs or leave. That keeps access aligned to business need and reduces both waste and unauthorised exposure.
Why This Matters for Security Teams
Salesforce licences are not just procurement line items. They are access entitlements that can open customer records, cases, reports, automation tools, and connected apps, so poor licence governance becomes an IAM problem fast. Security teams usually miss the risk when licence assignment is handled only by IT or operations, with no control mapping, review cadence, or offboarding trigger. NIST’s Cybersecurity Framework 2.0 treats identity governance as a core operational control, and the same logic applies here.
NHIMG research shows that lifecycle discipline is where identity programs break down most often, which is why the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is so relevant even for human SaaS entitlements: assignment, review, and revocation must be explicit, not implied. The practical question is not whether Salesforce is “software” or “identity,” but whether access still matches business need after role changes, leave events, or project churn. In practice, many security teams discover over-assigned Salesforce access only after an audit finding or a dormant-user cleanup exposes how long licences were left untouched.
How It Works in Practice
Effective governance starts by treating every Salesforce licence tier as a defined access bundle, then mapping each bundle to an approved role or job function. That means building an entitlement catalogue that shows what each licence enables, which groups may receive it, and what evidence is needed for approval. A licence without a business owner or review owner should be treated as an orphaned access path.
Next, align provisioning to joiner, mover, and leaver events. When a user changes teams, the old licence should be re-evaluated immediately rather than left in place “until the next review.” When a user leaves, revoke the entitlement and any connected access at the same time. For organisations using SSO or SCIM, the cleanest pattern is to drive licence assignment from the identity source of truth and let Salesforce reflect that decision automatically. This is also where periodic access recertification matters: licence use should be confirmed against actual activity, not just whether the account still exists.
Security teams should also look at how licences interact with connected applications, API access, and delegated administration. The NIST Cybersecurity Framework 2.0 supports this kind of control layering, while NHIMG’s Top 10 NHI Issues highlights the wider access-governance failures that appear when identities are granted more than they need. For operational prioritisation, NHIMG and CSA report that only 1.5 out of 10 organisations are highly confident in securing non-human identities, underscoring how often entitlement governance lags reality. A practical programme should combine RBAC, exception handling, and automated deprovisioning with regular business-owner review. These controls tend to break down when Salesforce entitlements are bundled into HR onboarding workflows without a corresponding mover process, because access accumulates faster than ownership changes.
Common Variations and Edge Cases
Tighter licence governance often increases administrative overhead, so teams must balance control precision against the cost of false positives and service friction. That tradeoff is especially visible in Salesforce environments with contractors, seasonal staff, and shared business units, where rigid rules can interrupt legitimate work if role data is stale.
Best practice is evolving for teams that manage mixed access patterns. Some organisations use simple role-to-licence mappings, while others add usage-based reviews for dormant accounts and high-risk profiles. There is no universal standard for this yet, but current guidance suggests applying stricter review thresholds to users with admin privileges, API-enabled access, or access to sensitive CRM objects. For regulated environments, the Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful because auditors will usually ask for evidence of entitlement ownership, recertification, and timely revocation, not just licence counts.
One common edge case is licensing tied to a manager’s discretion rather than a formal role model. Another is orgs that use Salesforce as both a business app and a workflow platform, where licence removal may affect automations, dashboards, or case queues. In those environments, access reviews should include dependency checks, not just user lists. For related attack patterns, NHIMG’s Salesloft OAuth token breach shows how adjacent access paths can turn a SaaS entitlement into a broader compromise path.
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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Salesforce licences are access entitlements that need governed assignment and revocation. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Licence sprawl mirrors entitlement sprawl and weak revocation hygiene. |
| NIST SP 800-63 | Identity proofing and session lifecycle help keep access aligned to the right user. |
Map each Salesforce licence to approved access rules and review them on joiner, mover, leaver events.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities in Salesforce?
- How should teams govern SaaS licences as part of identity management?
- How should security teams govern shadow IT that employees adopt outside central IAM?
- How should security teams govern Salesforce access across the employee lifecycle?
