Salesforce connected apps expose NHI governance gaps in access control

At a glance

What this is: This is an analysis of Salesforce connected apps as a non-human identity governance problem, with a focus on how shared integration users and overbroad permissions create privilege spillover.

Why it matters: It matters because IAM teams, IGA leads, and security architects often inherit Salesforce access patterns that look operationally convenient but quietly weaken least privilege across both human and non-human identity programmes.

By the numbers:

• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.

👉 Read Token Security's analysis of Salesforce connected app NHI risks

Context

Salesforce connected apps become an NHI governance issue the moment a single user context is reused across multiple integrations. The core problem is not just authentication, but entitlement design: OAuth tokens, permission sets, and shared integration users can combine into broader access than any one app actually needs.

That creates a familiar identity pattern with a different surface area. Human admin convenience, business-unit ownership, and machine-to-machine access all meet inside one platform, which means IAM and IGA teams need to treat Salesforce integrations as governed identities rather than informal app connections.

For teams already standardising NHI lifecycle controls, Salesforce is a useful test case for whether ownership, scope, and offboarding are genuinely enforced or only documented.

Key questions

Q: How should security teams govern Salesforce connected apps as non-human identities?

A: Treat every connected app as a governed non-human identity with ownership, scope, lifecycle, and offboarding requirements. Give each app a dedicated integration user, keep the baseline profile minimal, and recertify access whenever the app, business owner, or data scope changes. Shared users and broad profiles are the main reason connected apps become difficult to contain.

Q: Why do shared Salesforce integration users increase security risk?

A: Shared integration users increase risk because they aggregate permissions across multiple apps, which expands the blast radius of any compromise. If one app or token is abused, the attacker can inherit the full access of that shared user, including rights needed by other integrations. The result is usually broader access than any individual workflow actually requires.

Q: What do teams get wrong about OAuth tokens in Salesforce?

A: Teams often treat OAuth tokens as a login convenience rather than as live identity artifacts that must be scoped, monitored, and revoked. That mistake leaves long-lived access in place after an integration changes purpose or ownership. Good governance ties token review to lifecycle management, not to ad hoc application maintenance.

Q: Who should own Salesforce connected app access reviews?

A: Ownership should sit with identity governance, app owners, and the business function that depends on the integration, not with a single admin team alone. That split is important because connected apps combine technical access with business use. Reviews should confirm that the app still exists, still needs the same scope, and still uses a dedicated identity.

Technical breakdown

How Salesforce connected apps inherit identity context

Connected apps in Salesforce use federation and delegated authorisation to let external systems act inside the org. OAuth is the clearest example: the app does not become a separate service account by default, but operates within the scope of the authorising user. SAML and OpenID Connect simplify login, but they do not remove the need to govern who can connect, what scopes are approved, and how long the resulting access remains valid. The technical risk is that one identity can become the enforcement point for many downstream actions.

Practical implication: inventory every connected app as a governed identity pathway, not just an application integration.

Why shared integration users create privilege aggregation

A shared Salesforce integration user accumulates the permissions needed by every app that uses it. That is a privilege aggregation pattern, not a least-privilege pattern, because the effective access becomes the sum of profile rights plus every assigned permission set. If one app needs reporting and another needs lead management, the shared account often ends up able to do both, even when no single integration requires that combination. The problem intensifies when the underlying profile is cloned from an administrative baseline.

Practical implication: separate integration users by business function and remove any inherited admin-like baseline before granting app-specific rights.

Why OAuth token governance matters more than login convenience

OAuth reduces credential sharing, but it also creates a new control plane around token scope, revocation, and monitoring. A token that is never rotated or revoked after an integration changes ownership can preserve access long after the original business need is gone. That is why token governance belongs with identity lifecycle management, not just application support. If logs are not reviewed and app ownership is not tracked, the organisation loses visibility into which non-human identities still have live access.

Practical implication: couple token review, app ownership, and offboarding into the same lifecycle process.

Threat narrative

Attacker objective: The attacker wants persistent access to Salesforce data and the ability to move laterally through an over-entitled integration identity.

1. Entry occurs when a connected app is authorised through OAuth, SAML, or OpenID Connect, giving the external system an identity context inside Salesforce.
2. Escalation happens when multiple apps share one integration user and its permissions accumulate across profiles and permission sets.
3. Impact follows when a compromised or overused connected app can access Salesforce data at a broader scope than the original business case justified.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Salesforce connected apps are an NHI lifecycle problem before they are an application problem. The moment an integration user, token, or app grant is shared across business functions, lifecycle ownership becomes blurred and privilege becomes cumulative. That is not merely a tooling issue. It means offboarding, recertification, and entitlement review must follow the integration, not the team that created it.

Shared integration users create identity blast radius, not just administrative convenience. A single Salesforce user acting for multiple connected apps turns one compromise into a multi-system access event. The organisation has not just centralised authentication, it has centralised failure. Practitioners should treat this as a blast-radius problem in NHI governance, because the same identity now carries multiple operational meanings and multiple trust relationships.

Least privilege fails when profiles and permission sets are treated as additive afterthoughts. Salesforce's grant-only model can quietly build broad effective access when teams stack permission sets onto a powerful base profile. That is an entitlement design failure, not a configuration typo. The implication is that identity governance must start from the baseline profile and prove that every added permission still matches a single business purpose.

Token governance becomes the control that decides whether connected apps stay bounded. OAuth scope, revocation, and monitoring are not secondary hygiene tasks. They are the mechanism that prevents a connected app from outliving its business purpose or inheriting access from another integration. When the token layer is weak, the rest of the identity model stops being trustworthy.

Connected app risk now sits on the same continuum as agentic access risk, even when the system is not autonomous. The article shows a familiar bridge between machine identity, delegated access, and future AI-driven workflows that will also depend on runtime credentials. Teams that cannot govern Salesforce integrations cleanly will struggle to govern more dynamic non-human identities later. The practical conclusion is to harden the lifecycle model now.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure.
• For a broader control baseline, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for lifecycle handling of non-human identities.

What this signals

Identity blast radius: Salesforce integrations show how quickly a single non-human identity can become an enterprise-wide access multiplier when ownership is vague and entitlements are layered by convenience. Teams should expect their review workload to shift from app inventory to access lineage, especially where business users, admins, and machine credentials overlap.

The practical signal is that token revocation and ownership tracking must become measurable lifecycle controls, not best-effort hygiene. When a connected app changes hands, the old grant must be treated as an expired trust relationship, not a dormant configuration record.

If your programme already covers workload identity, this is a useful warning that delegated enterprise apps can fail in the same way as other machine identities. The governance pattern is the same even when the platform looks like SaaS rather than infrastructure.

For practitioners

• Create one integration user per connected app Assign each Salesforce integration a dedicated identity with only the permissions that specific app needs. Avoid sharing users across apps, because shared identities turn separate business functions into a single compromise path.
• Reset the baseline profile before adding permission sets Start from a minimal Salesforce profile and prove that every permission set added on top is necessary for one app or one task. Do not layer controls onto a System Administrator clone and assume the final access profile is still least privilege.
• Track connected app ownership through offboarding Maintain an inventory of every connected app, its business owner, its user context, and its token revocation path. When a business unit changes tools or a vendor relationship ends, revoke the app grant and confirm the identity is no longer active.
• Review OAuth logs for scope drift Monitor connected app activity for unusual access patterns, broader-than-expected data reads, and tokens that continue to work after the original use case has ended. Treat repeated access outside expected business hours or volumes as a sign that the app scope no longer matches reality.

Key takeaways

• Salesforce connected apps become a governance problem when shared identities and stacked permissions let one integration carry too much trust.
• The scale of the risk comes from lifecycle failure, because tokens and grants often remain active after the business need has changed.
• Practitioners should move connected app control into identity governance, with dedicated users, minimal baselines, and explicit revocation on offboarding.

Key terms

• Connected App: A connected app is an external application that is allowed to authenticate to Salesforce and act within defined scopes. In practice, it becomes an identity and access relationship, not just a software integration, so the permissions, token lifetime, and ownership of that relationship must be governed.
• Integration User: An integration user is a dedicated Salesforce identity used by systems rather than people. It should represent one business purpose and one access pattern. When multiple applications share the same user, privilege tends to accumulate and the blast radius of compromise expands quickly.
• Permission Set: A permission set is an additive collection of Salesforce privileges layered onto a baseline profile. It is useful for task-specific access, but it can also hide entitlement creep when teams stack sets onto already powerful profiles. Governance must verify the final effective access, not only the intended add-on.

What's in the full article

Token Security's full blog covers the operational detail this post intentionally leaves for the source:

• Concrete examples of Salesforce profile and permission set combinations that create excess access
• Detailed guidance on separating integration users for different connected apps and business functions
• Practical steps for reviewing OAuth activity, token persistence, and connected app ownership
• Specific misconfiguration patterns that can cause a shared user to inherit far more access than intended

👉 The full Token Security post covers shared integration users, permission set layering, and OAuth governance detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.