Notifications
Clear all
Topic starter
06/07/2026 9:46 am
TL;DR: Salesforce connected apps turn OAuth, SAML, and OpenID Connect into non-human identity pathways that can expand access far beyond the original business intent, especially when multiple integrations share one user context, according to Token Security. The governance problem is not connectivity itself, but the assumption that one identity can safely represent many apps without creating privilege spillover.
NHIMG editorial — based on content published by Token Security: Salesforce Connected Apps: Navigating NHI Security Risks and Best Practices
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Create one integration user per connected app Assign each Salesforce integration a dedicated identity with only the permissions that specific app needs.
- 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.
- Track connected app ownership through offboarding Maintain an inventory of every connected app, its business owner, its user context, and its token revocation path.
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
👉 Read Token Security's analysis of Salesforce connected app NHI risks →
Salesforce connected apps and NHI sprawl: what teams miss?
Explore further
06/07/2026 10:03 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Salesforce connected apps expose NHI governance gaps in access control
