Salesforce access drift exposes hidden NHI governance gaps

At a glance

What this is: This analysis shows that Salesforce governance fails when profiles, permission sets, and connected apps combine into access paths that legacy IGA reviews cannot resolve into effective permissions.

Why it matters: It matters because IAM and IGA teams need to govern both human access and connected-app NHI access at the object level, or privilege drift will remain invisible.

Context

Salesforce access is not governed by a single role or profile. It is assembled from profiles, permission sets, permission set groups, role hierarchies, sharing rules, and connected apps, which means effective access often differs from what a static review shows. That gap is the core governance problem for both human users and non-human identities.

When organisations rely on license checks or profile-based reviews alone, they miss who can actually read, edit, delete, or impersonate inside Salesforce. That leaves a blind spot in key NHI security challenges because access can drift through inheritance and integration grants without showing up in the usual access review workflow.

Key questions

Q: What breaks when Salesforce access is built mainly on profiles?

A: Profiles become overloaded with exceptions, which makes least privilege hard to maintain and even harder to audit. Because a single profile change affects every assigned user, control becomes rigid, overexposure spreads quietly, and small role changes turn into broad entitlement changes. The model stops supporting scalable governance and starts preserving legacy access.

Q: Why do connected apps and integration users need separate governance from human users?

A: Because they carry their own credentials, scopes, and API rights. Their access can persist after the human owner changes role or leaves, so human lifecycle controls do not automatically reduce the NHI risk. Governance has to follow the token, the app grant, and the service account lifecycle.

Q: What are the signs that Salesforce access controls are getting out of control?

A: A common warning sign is a mature org where profiles have been cloned and modified repeatedly, leaving old permissions in place and unused profiles behind. Another sign is that access decisions are driven by employee convenience rather than a security design. If teams cannot quickly explain who can access critical objects and fields, governance is already too loose.

Q: How should teams decide between static reviews and continuous Salesforce monitoring?

A: Use continuous monitoring when rights change through inherited groups, connected apps, or recurring permission set additions. Static reviews are too slow for a system where effective access can change without a formal request, so the control should move from periodic certification to ongoing entitlement correlation.

Technical breakdown

Why Salesforce effective access is harder than assigned access

In Salesforce, effective access is the sum of multiple layers, not a single entitlement. Profiles set baseline rights, permission sets add exceptions, permission set groups bundle those exceptions, role hierarchies extend visibility, and sharing rules alter record reach. A governance tool that inspects only the active license or the base profile will understate what a user can actually do. The operational issue is that object-level permissions and record-level exposure live in different parts of the model, so review outputs can look clean while the real access path remains broad. See the Salesforce Security Guide.

Practical implication: Review effective permissions, not just assigned roles, before certifying Salesforce access.

How connected apps and integration users create separate NHI access paths

Connected apps, integration users, and OAuth tokens in Salesforce behave like non-human identities with their own permission footprint. They can accumulate rights independently of the human account that created or owns them, which means human recertification does not automatically govern the integration path. If an integration user has broad API access, the security boundary sits at the token, scope, and app grant level, not at the employee account. That is why dormant integrations and over-privileged API credentials become a separate governance problem rather than a subcase of user access. See the SaaS-to-SaaS and OAuth App Governance Guide.

Practical implication: Treat connected apps and integration users as governed NHI entities with their own lifecycle controls.

Why continuous identity graphing exposes drift that point-in-time reviews miss

A continuous identity security graph correlates profiles, permission sets, group membership, role hierarchy, connected app grants, and audit activity into one access picture. The value is not just visibility, but resolution: it converts many partial assignments into the effective rights behind each identity. That makes dormant accounts, unused privilege, impersonation events, and toxic combinations observable as state changes rather than one-off findings. Without that graph model, periodic certification often reviews stale snapshots instead of the live access shape that determines risk. Read the Ultimate Guide to NHIs: Key Research and Survey Results.

Practical implication: Use continuous graph-based analysis to detect permission drift before the next review cycle.

Threat narrative

Attacker objective: The objective is to reach sensitive Salesforce data and operations through access paths that governance tools fail to reduce to effective permissions.

1. Entry occurs when a user, service account, or connected app gains Salesforce access through profiles, permission sets, or OAuth-based integration credentials.
2. Escalation happens as inherited groups, role hierarchy, and shared-record permissions expand what that identity can reach beyond the original grant.
3. Impact follows when over-privileged human or NHI access exposes customer records, pipeline data, contract terms, or administrative actions that should have been constrained.

Breaches seen in the wild

• Gainsight Salesforce breach 2025: Stolen OAuth tokens for Gainsight's Salesforce app, some eight years old, were used against customer orgs; Google saw 200+ instances at risk.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Salesforce identity governance fails at the level of effective access, not identity count: The issue is not how many users or apps exist, but whether controls can reconstruct what each identity can actually reach. Profiles, permission sets, and sharing rules create composite entitlements that are easy to misread in a spreadsheet or license-based review. The practitioner conclusion is straightforward: if you cannot resolve effective access, you cannot certify Salesforce with confidence.

Connected apps turn Salesforce into an NHI governance problem as much as a human IAM problem: OAuth tokens, integration users, and API credentials create access that persists outside normal employee lifecycle checks. That means a leaver, mover, or role change does not automatically constrain the non-human access path. The implication is that governance must follow the credential and the app grant, not only the person who requested them.

Permission drift is the hidden control failure behind most Salesforce overexposure: Users pick up Permission Sets and Permission Set Groups over time, and those additions often outlive the business need that justified them. The result is standing privilege that looks normal in aggregate but exceeds the original access intent at object level. Teams need to treat drift as a governance state, not a one-time exception.

Continuous correlation creates the only usable Salesforce access truth: A graph model that links entitlement, activity, and connected-app state gives security teams a live view of dormant accounts, unused rights, and impersonation events. That matters because point-in-time review cannot explain whether an entitlement is still active in practice. The practitioner takeaway is to base review on observed access behaviour, not just entitlement inventory.

Vendor-neutral lesson: Salesforce is a composite identity system, not a single application permission set: Any programme that governs it as a flat SaaS app will miss inherited visibility, NHI grants, and record-level exposure. The named concept here is effective access drift: access that remains valid in the system even after the original business rationale has disappeared. Practitioners should govern the live access shape, not the historical approval record.

Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Effective access drift: Salesforce governance should be treated as live entitlement reconstruction, not periodic approval checking. When profiles, permission sets, and connected app grants combine, the security question becomes whether the current access shape still matches the business need that originally justified it.

Continuous certification only works if the review engine can resolve inherited access into observable rights. In Salesforce, that means tying object-level permissions and audit activity together so dormant privilege, impersonation, and over-scoped integration access are visible before the next recertification cycle.

Teams that already run IGA for SaaS should treat Salesforce as a composite identity environment, not a single application. That shift changes the operating model from owner-based review to evidence-based access validation across both human and non-human identities.

For practitioners

• Audit effective Salesforce permissions, not just profiles Reconstruct read, edit, and delete rights from profiles, permission sets, permission set groups, role hierarchies, and sharing rules before recertifying access.
• Separate NHI governance from employee access review Track connected apps, integration users, and OAuth credentials as discrete identities with their own owners, scopes, and offboarding events.
• Flag dormant integration users and unused privilege Compare granted Salesforce rights with recent audit activity to identify service accounts and humans whose access exceeds current operational use. See the Service Account Security Guide.
• Validate impersonation and admin traceability Review login-as usage, setup audit trail events, and session activity so administrative actions remain attributable during investigations and compliance reviews.
• Rebuild SOX reviews around object-level access Use object-level entitlements and actual activity instead of spreadsheet exports when certifying access to customer, deal, and case records.

Key takeaways

• Salesforce access can look compliant at the profile level while still exposing sensitive objects through inherited permissions and sharing rules.
• Connected apps and integration users create non-human access paths that employee-centric reviews do not reliably govern.
• The practical fix is to certify effective access continuously, with object-level evidence and separate lifecycle controls for integrations.

Related NHI Mgmt Group resources: Ultimate Guide to NHIs: Key Challenges and Risks · Salesforce Security Guide · SaaS-to-SaaS and OAuth App Governance Guide · IGA Buyer's Guide

Key terms

• Effective Access: The actual permissions an identity can exercise after inheritance, nested groups, delegation, and object-level controls are evaluated. In Active Directory, effective access is more useful than direct membership because it reveals the true operational reach of a service account.
• Permission Drift: Permission drift is the gradual expansion of access beyond what was originally intended. It happens when roles, tokens, and service accounts accumulate unused rights over time, making cloud identities harder to review and more dangerous to compromise.
• Connected App: A connected app is a third-party integration that is granted access to a SaaS platform through APIs and OAuth permissions. From a governance perspective, it is an identity-bearing access path that needs ownership, scoping, and periodic review like any other non-human identity.
• Object-Level Access: Object-Level Access is permission granted to a specific record, configuration item, or functional object rather than to an entire application area. It is used to narrow access in complex systems where broad roles would expose too much capability. The control becomes useful only when assignments are reviewed and kept aligned to business need.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.