How should security teams reduce profile sprawl in Salesforce?

Why This Matters for Security Teams

Profile sprawl in Salesforce is not just a hygiene issue. Every extra profile increases the number of places where access can drift, reviews become inconsistent, and exceptions get baked into the baseline. That matters because profiles are coarse-grained by design, while modern access needs are usually more specific. Current guidance from the NIST Cybersecurity Framework 2.0 still points teams toward least privilege, but Salesforce teams often implement that principle in a way that becomes hard to govern.

In practice, sprawl usually appears after years of copying profiles for new teams, new integrations, and temporary exceptions that never get removed. The result is a permissions model that looks tailored but behaves like a patchwork of legacy access. That creates audit pain, weakens separation of duties, and makes it harder to spot who actually has access to sensitive objects, fields, and system capabilities. The Ultimate Guide to NHIs — Key Challenges and Risks also shows how excessive privilege and poor visibility compound each other across identity estates, and the same pattern shows up in Salesforce entitlement design. In practice, many security teams discover profile sprawl only after an access review exposes dozens of nearly identical profiles.

How It Works in Practice

The practical fix is to make profiles the smallest stable baseline and move variation into permission sets and permission set groups. That shifts Salesforce access from profile cloning to modular entitlement layering, which is easier to review, easier to revoke, and less likely to create unintended side effects. A clean baseline profile should contain only the minimum needed for login, app navigation, and the user’s broad employment category. Everything else should be added explicitly.

For most teams, the workflow looks like this:

• Inventory all profiles and identify near-duplicates by object access, field access, and system permissions.
• Collapse profiles that differ only by a small number of entitlements into one baseline profile.
• Move the differences into permission sets for discrete capabilities such as export rights, object edit rights, or admin-like functions.
• Use permission set groups to package common job functions and reduce one-off assignment sprawl.
• Review assignments periodically so temporary access does not become permanent access.

This approach aligns well with least privilege because it separates identity baseline from functional privilege. It also improves governance because security teams can review a permission set catalogue instead of comparing dozens of profile variants. The Salesloft OAuth token breach is a useful reminder that weak control over Salesforce-adjacent access often becomes a data exposure problem, not just an admin inconvenience. For baseline identity governance, the NIST Cybersecurity Framework 2.0 reinforces the need for access control, asset visibility, and continuous review.

Where this guidance breaks down is in heavily customised orgs with legacy managed packages, because package constraints and inherited permissions can make some profile consolidation unsafe without a staged dependency review.

Common Variations and Edge Cases

Tighter profile design often increases short-term admin effort, requiring organisations to balance simplicity against the cost of redesigning decades of custom access. That tradeoff is real, especially in orgs where business units expect their own profile for every minor variation. Best practice is evolving, but current guidance suggests resisting that pressure unless a profile boundary reflects a genuine security boundary.

One common edge case is the integration user. These accounts often need a distinct baseline profile, but even then, functional privileges should still be externalised into tightly scoped permission sets wherever possible. Another case is delegated administration, where business admins need a limited management role without full system rights. That is usually better handled with targeted permission sets than with a custom admin profile clone.

Security teams should also watch for field-level access that mirrors object access too closely. If a profile exists solely to hide a few fields, the model is probably already too fragmented. The better pattern is to preserve one baseline profile per true user class, then use permission sets for special access and permission set groups for repeatable bundles. Where this becomes difficult is in mergers, acquired orgs, or environments with large numbers of automation and service accounts, because inherited access patterns can be too inconsistent to rationalise quickly.

Related resources from NHI Mgmt Group

• How do security teams reduce risk when authorization servers fetch client metadata?
• How should security teams decide whether JIT access is safe for non-human identities?
• How should teams reduce the risk from exposed NHI secrets?
• How should security teams reduce secret sprawl in machine identities?