How should security teams control privileged access in Salesforce environments?

They should inventory effective access, not just assigned roles, then remove unnecessary combinations of profiles, permission sets, and sharing rules. Privileged accounts should be owned, recertified, and monitored as high-risk identities. For integrations, the same controls should apply to service accounts, OAuth scopes, and offboarding when the business need ends.

Why This Matters for Security Teams

Salesforce privilege is rarely controlled by a single role. In practice, effective access is assembled from profiles, permission sets, public groups, sharing rules, connected apps, OAuth scopes, and service accounts. That makes “who can do what” harder to see than in a conventional RBAC model, and it is exactly why privileged access in CRM platforms becomes a governance problem, not just an admin task. The OWASP Non-Human Identity Top 10 frames this as an identity-risk issue, while NHIMG research shows why the control objective matters: Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, broadening the attack surface. In Salesforce, those “NHIs” include integration users, API-only accounts, and automation identities that often outlive the business process they support. Security teams need to manage the full effective path to data, not only the assigned role name. In practice, many teams discover over-privileged Salesforce access only after an integration account has already been reused, expanded, or left active after the original business need ended.

How It Works in Practice

A workable control model starts by inventorying every access path that can reach Salesforce data, then collapsing it to the minimum set required for each business function. That means recertifying ownership for administrators, sales ops users, and integration identities on the same schedule, but with different evidence. Human privileged users should be tied to named owners and reviewed for approval drift; service accounts should have explicit business sponsors, scoped OAuth grants, and offboarding dates. When possible, pair this with OWASP Non-Human Identity Top 10 style controls: least privilege, secret rotation, visibility into token use, and removal of dormant credentials.

For Salesforce specifically, teams should look beyond role assignments and verify the effective permissions created by combinations of profile, permission sets, permission set groups, sharing rules, and connected app policies. The most important operational question is whether the identity can still reach sensitive objects, fields, or automation endpoints after each control layer is applied. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is clear that visibility gaps are common, and Ultimate Guide to NHIs — Standards reinforces the need for lifecycle control, not one-time hardening. For integrations, token scope should match the narrowest needed API surface, with rotation and revocation tied to business ownership rather than technical convenience.

• Inventory effective access, not just assigned roles.
• Separate human admins from service accounts and treat both as high-risk identities.
• Recertify permission sets, sharing rules, and OAuth scopes together.
• Revoke credentials and connected app access when the business need ends.

These controls tend to break down in heavily customized orgs with many managed packages because permission inheritance and automation paths become difficult to prove end to end.

Common Variations and Edge Cases

Tighter privileged access control often increases administrative overhead, so organisations have to balance review frequency and scope against operational friction. That tradeoff is real in Salesforce environments with multiple sandboxes, outsourced admins, and third-party apps. Current guidance suggests treating external integrations as first-class privileged identities, but there is no universal standard for exactly how much scope a connected app should retain across teams and business units. In higher-risk environments, the safer pattern is to issue separate service principals per function, limit refresh token lifetimes where feasible, and require explicit re-approval when scopes expand.

Edge cases also matter. Break-glass admin accounts need stronger monitoring, but they should not become standing exceptions without expiry and review. Large orgs often rely on permission set groups for speed, yet those same groups can mask privilege creep unless the security team reviews the final effective access path. The 52 NHI Breaches Analysis is useful here because it shows how often identity compromise is really a lifecycle failure, not a single misconfigured role. Salesforce security teams should therefore measure privilege by active reach, not by design intent alone, and align reviews to Ultimate Guide to NHIs principles of visibility, rotation, and offboarding. The practical rule is simple: if an identity can still authenticate after the business case has ended, the access model is not finished.

Related resources from NHI Mgmt Group

• How should security teams govern MCP tool access in enterprise environments?
• How should security teams govern privileged access across service accounts and AI-driven systems?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in Salesforce?