Licensing optimisation focuses on cost and feature usage, while access governance focuses on whether the right people still have the right access. They overlap, but they are not the same control. A licence can be financially wasteful without being risky, and access can be risky even when the licence is fully used.
Why Licensing Optimisation and Access Governance Are Different Controls
In Salesforce, licensing optimisation asks whether users are assigned the right edition or feature set for what they actually do, so the focus is commercial efficiency and product fit. access governance asks whether those users still should have those permissions at all, so the focus is entitlement, recertification, and least privilege. The two controls often share data, but they answer different questions and trigger different decisions.
That distinction matters because a user can be over-licensed without being over-entitled, or under-licensed while still holding access that no longer matches their role. Licensing is usually about spend and utilisation. Access governance is about control state, evidence of need, and whether access should be removed, changed, or approved again.
Salesforce environments make the separation easy to blur because licence type, permission sets, roles, profiles, and connected app access can all interact. A licence can enable a capability, but governance decides who should keep that capability, when it should be reviewed, and whether the assignment is still justified by job function or business need.
How the Control Boundaries Affect Day-to-Day Salesforce Decisions
Licensing optimisation is usually driven by usage reports, feature adoption, and seat rationalisation. The practical question is whether a lower-cost licence tier would satisfy the user’s actual activity, or whether a dormant licence can be reclaimed. A good optimisation programme can reduce spend without changing the access model at all.
Access governance operates on a different lifecycle. It looks at joiner, mover, and leaver events, access reviews, and privileged or sensitive entitlements. The useful question is not “is this the cheapest licence?” but “does this person still need this access, and can I prove why?” That is why access governance often involves managers, application owners, and audit evidence, not just procurement or platform admin.
For Salesforce specifically, the same user may need a standard licence, a permission set for a business process, and elevated access to a critical object or integration. Optimising the licence does not remove the need to review the permission model, and reviewing access does not tell you whether the user is assigned the most economical licence.
Where Misalignment Creates Cost, Risk, and Audit Noise
The most common mistake is treating licence cleanup as a substitute for access review. That can leave excessive permissions in place even after a user is moved to a cheaper licence, or it can produce the opposite error, where governance teams focus on revocation but never remove wasteful capacity. The result is noisy reporting and a false sense of control.
Another common failure is to infer risk from licence spend alone. A fully utilised licence may be perfectly appropriate, while an expensive licence may still be low risk if the entitlement set is tightly governed. Conversely, a low-cost assignment can still create material exposure if the user retains broad object, field, or admin-style access that is no longer needed.
In practice, the governance question is usually closer to access governance and review discipline than to cost control alone. If the licensing model is detached from entitlement ownership, teams tend to miss stale access, permission creep, and unreviewed exceptions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organisational Context | Salesforce licensing and access decisions must reflect business role and system context. |
| ID.AM-01 — Physical Devices and Systems Inventory | Licence and entitlement governance both depend on accurate inventory of users and access-bearing accounts. | |
| Recommendation — Define Salesforce licence and access ownership against business context and control objectives. Maintain an accurate inventory of Salesforce users, roles, and access-bearing accounts. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Access governance in Salesforce depends on provisioning, review, and revocation of user access. |
| AC-6 — Least Privilege | Licensing may optimise cost, but access governance must still enforce minimum necessary access. | |
| IA-5 — Authenticator Management | Salesforce access often includes credentials and tokens that need lifecycle governance beyond licence choice. | |
| Recommendation — Review and revoke Salesforce accounts and entitlements when business need changes. Limit Salesforce users to the minimum permissions required for their duties. Track and rotate Salesforce authenticators and related access material on a defined lifecycle. | ||
Practitioner Guidance
What to prioritise: Split reporting into two separate views, one for commercial licence utilisation and one for entitlement governance. Use the first to find waste, and the second to find access that no longer matches role or need.
What to verify: Before you call a cleanup successful, verify that every licence reduction was checked against the user’s permission sets, roles, and object-level access. A lower-cost licence is not a control outcome unless the underlying access state still makes sense.
Common mistake: Do not let savings metrics drive revocation decisions by themselves. If the user still has broad access after licence optimisation, you have reduced spend but not reduced exposure.
Practitioner takeaway: Treat licensing as an efficiency control and access governance as a security and assurance control; they should inform each other, but they should never be measured as if they were the same thing.
Related resources from NHI Mgmt Group
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between human IAM controls and NHI governance?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org