What breaks when third-party Salesforce connections are left unchecked?

Why This Matters for Security Teams

Third-party Salesforce connections are not just convenience layers. They are non-human identities with delegated reach into customer records, files, cases, and automation. When those connections are left unchecked, organisations often inherit standing access that outlives the business need, and that creates a durable path for abuse. The risk is amplified because Salesforce data is frequently connected to downstream workflow tools, analytics platforms, and ticketing systems, so one weak integration can become a pivot point.

NHI Management Group research shows that 92% of organisations expose NHIs to third parties, which makes third-party app governance a common blind spot rather than an edge case. That pattern is consistent with guidance from the OWASP Non-Human Identity Top 10, which treats excessive privilege, weak lifecycle control, and missing ownership as recurring failure modes. The practical issue is not only initial authorisation, but whether anyone is continuously reviewing what the app can still do.

In practice, many security teams discover Salesforce integration risk only after a stalled offboarding, a vendor incident, or a suspicious data export has already created exposure.

How It Works in Practice

A Salesforce connection typically authenticates through OAuth, API tokens, connected apps, or service accounts, and those credentials can remain active long after the original business purpose has changed. If approval is broad, the app may be able to read contacts, modify objects, trigger flows, pull reports, or call other systems on behalf of the org. The challenge is that this is delegated machine access, so classic user reviews often miss it.

Good control design starts with inventory and ownership. Each connection should have a named business owner, a technical owner, a defined purpose, and a review date. Scope should be narrowed to the minimum object and API access required, and where possible, consent should be segmented so an app cannot inherit more rights than the workflow needs. This aligns with the Ultimate Guide to NHI Management, which emphasises lifecycle visibility, rotation, and offboarding for non-human identities.

• Review connected apps, OAuth scopes, and API usage on a fixed cadence.
• Remove unused integrations and revoke tokens when a vendor, project, or workflow ends.
• Limit admin-level consent to explicit break-glass or approved deployment paths.
• Log calls, token grants, and privilege changes so activity can be tied back to a specific app.

For implementation detail, the Klue OAuth Supply Chain Breach and the 52 NHI Breaches Analysis show how delegated access can become a supply chain problem when app trust is not continuously revalidated. A practical control stack also benefits from the OWASP Non-Human Identity Top 10 because it frames these connections as identities, not just software plugins. These controls tend to break down when integrations are granted broad org-wide scopes and no one can reliably map tokens to a current owner or business purpose.

Common Variations and Edge Cases

Tighter integration control often increases operational overhead, requiring organisations to balance agility against review burden and vendor friction. That tradeoff is especially visible in Salesforce environments with many low-code automations, managed packages, and department-owned apps. Current guidance suggests that these environments need more frequent recertification, but there is no universal standard for how often every connection should be reviewed.

Edge cases include sandboxes mirrored into production, emergency integrations created for a single campaign, and vendor apps that request broad permissions during setup but use only a fraction of them in steady state. Another common exception is where a single integration supports multiple business processes, which makes simple disablement risky. In those cases, security teams should separate the app’s technical identity from the business function it serves, then decide whether access should be split, reduced, or replaced.

The 52 NHI Breaches Analysis and Ultimate Guide to NHI Management both reinforce the same operational lesson: unchecked machine access rarely fails loudly. It usually persists through orphaned tokens, broad scopes, and weak ownership until a routine integration becomes an incident path.

Related resources from NHI Mgmt Group

• What breaks when an AI-integrated service uses one shared credential for many third-party connections?
• What breaks when organisations cannot see all third-party app connections?
• What breaks when third-party access is left open too long?
• What breaks when cloud permissions are left broad across third-party pipelines and automation?