How should security teams reduce Salesforce access risk when profiles, permission sets, and sharing rules overlap?

Why This Matters for Security Teams

Salesforce access risk rarely comes from a single over-permissioned profile. It emerges when profiles, permission sets, permission set groups, role hierarchy, sharing rules, and delegated admin rights combine into an access path that no one reviewed end to end. That is the same pattern NHIMG sees in other identity-heavy environments: the danger is not the entitlement itself, but the effective access that appears after policy overlap.

For teams trying to reduce exposure, the practical problem is visibility. A user may look constrained on paper while still reaching sensitive objects, fields, reports, or records through inherited access. This is why a control review has to move from assigned permissions to effective access analysis, then to periodic recertification and removal of stale exceptions. The security team should treat that analysis as a standing governance task, not a one-time configuration cleanup.

Industry guidance increasingly points to least privilege, but current guidance suggests that in Salesforce the hardest failures come from cumulative access, not isolated misconfiguration. The State of Non-Human Identity Security shows how often over-privilege and poor visibility coexist, and the same operational lesson applies here. In practice, many teams discover excess Salesforce access only after a business unit has already built around it.

How It Works in Practice

The right approach is to model Salesforce access as a chain of grants. Start with the base profile, then add permission sets and groups, then layer in role hierarchy, sharing rules, manual shares, and delegated administration. The goal is to answer a simple question: what can this user actually do right now, not what did the original configuration intend?

A practical review usually follows four steps:

• Inventory every profile, permission set, and permission set group assigned to the user population.
• Map object, field, and record access separately, because those controls often drift in different directions.
• Identify additive paths that grant access indirectly, especially through role hierarchy and sharing rules.
• Remove duplicate or legacy grants, then recertify the remaining exceptions on a fixed schedule.

This matters because Salesforce is highly customizable, and customisation increases the chance that business owners will accrete access through exceptions. Security teams should prefer role-based structures that are narrow by default, with permission sets used only for truly additive exceptions. Where possible, use automated entitlement review to flag combinations that create effective access beyond the baseline.

For control design, the closest external benchmark is the OWASP Non-Human Identity Top 10 and the NIST SP 800-53 Rev 5 Security and Privacy Controls, both of which reinforce least privilege, access review, and continuous control monitoring. For Salesforce-specific exposure patterns, NHIMG’s Salesloft OAuth token breach is a useful reminder that access paths often matter more than the initial credential. These controls tend to break down when administrators rely on manual exception handling across many custom objects and sharing rules because the effective-access graph changes faster than review cycles.

Common Variations and Edge Cases

Tighter access governance often increases administrative overhead, so teams have to balance reduction of risk against the operational cost of refactoring long-standing Salesforce customisations. That tradeoff is real, especially in organisations that depend on sales, service, and partner portals with different access patterns.

There is no universal standard for every Salesforce model yet, but best practice is evolving toward evidence-based access review rather than rule counting. For example, a user with a limited profile may still need a permission set for a specific workflow, but that exception should be time-bound and reviewed against actual business need. Similarly, shared records may be appropriate for collaboration, but broad sharing rules should not become a substitute for poor role design.

Edge cases also appear in environments with delegated administration or multiple business units. In those settings, local admins can unintentionally reintroduce the same excess access that central controls removed. The security team should therefore test for inherited access after every major role, profile, or sharing change, and not just during annual review. The NIST Cybersecurity Framework 2.0 supports that continuous improvement model. Where access depends on many overlapping exceptions and fast-moving business rules, the review process often fails because no single owner can explain the full effective entitlement chain.

Related resources from NHI Mgmt Group

• How should security teams reduce risk from misconfigured firewall rules in segmented networks?
• How should security teams reduce the risk of cloud secrets repositories being abused for credential access?
• How should security teams reduce breach risk in GitHub when credentials and service accounts have more access than they need?
• How should security teams implement fine-grained authorization in Nuxt apps without hardcoding access rules?