How should security teams govern third-party app access in Salesforce environments?

Security teams should inventory every connected app and service, vet non-marketplace integrations before approval, and continuously review the permissions each connection receives. The goal is to remove unused connections, enforce least privilege, and monitor for unusual behavior such as unexpected geolocation, IP, or user-agent changes that can signal compromised access or misuse.

Why This Matters for Security Teams

Salesforce third-party app access is not a simple integration checklist. Each connected app can inherit broad data reach, persist longer than the business need that justified it, and bypass the visibility teams expect from human logins. That makes connected apps a high-value NHI problem, especially when the access comes through OAuth, service principals, or API keys that are difficult to trace after approval. Current guidance from the OWASP Non-Human Identity Top 10 and NHIMG research shows why this matters: the Ultimate Guide to NHIs reports that 92% of organisations expose NHIs to third parties, and 97% of NHIs carry excessive privileges.

The operational risk is not just over-permissioning. Unreviewed integrations can keep working after the owning team changes, the vendor is acquired, or the original use case disappears. In practice, many security teams encounter abuse only after a connected app has already been used for lateral movement, data extraction, or silent persistence rather than through intentional review of the integration lifecycle.

How It Works in Practice

Effective governance starts with an inventory that distinguishes approved marketplace apps from direct, custom, and legacy integrations. Security teams should require a business owner, a technical owner, a documented purpose, and a permissions baseline for every connection. From there, approval should be tied to least privilege, not convenience, and the granted scopes should be revalidated whenever the app changes behavior, vendor, or authentication method.

For Salesforce environments, the practical control points are the connected app policy, OAuth scope review, session and token lifetime settings, and monitoring for anomalous authentication patterns. Security teams should treat third-party app access as an identity lifecycle problem: issue access only when needed, rotate or revoke credentials when use cases end, and review whether the app still needs the data it can reach. That approach aligns with the NIST Cybersecurity Framework 2.0 and the 52 NHI Breaches Analysis, which both reinforce continuous visibility and control over machine-to-machine access.

• Inventory every connected app, including vendor-managed and custom OAuth integrations.
• Map each app to an owner, purpose, data class, and required Salesforce scopes.
• Remove dormant apps and revoke tokens that no longer support an active business process.
• Alert on unexpected geolocation, IP, user-agent, or login-time changes that indicate misuse.
• Require stronger review for non-marketplace integrations, since they bypass the normal trust cues of an app exchange.

NHIMG research shows why this discipline matters: the State of Non-Human Identity Security found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps. These controls tend to break down when Salesforce is integrated into fast-moving revenue operations because admins optimize for deployment speed and security review happens after access has already been granted.

Common Variations and Edge Cases

Tighter app governance often increases admin overhead and can slow sales operations, requiring organisations to balance control against business continuity. That tradeoff is real, especially when a trusted vendor publishes multiple apps, a partner needs temporary API access, or an internal team owns a custom integration that must stay online during a migration.

Best practice is evolving for these edge cases. There is no universal standard for how often third-party Salesforce apps should be recertified, but current guidance suggests more frequent review for apps with write access, broad CRM visibility, or access to regulated data. Some teams rely on vendor attestations; others require technical validation of scopes and logs. Security teams should prefer evidence over assurances, particularly for integrations that can refresh tokens silently or that chain into downstream systems outside Salesforce.

Another common exception is break-glass or emergency access for operations teams. That access should still be time-bound, recorded, and removed automatically after the incident window closes. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because lifecycle discipline matters more than the initial approval. For broader control design, the NIST SP 800-53 Rev 5 Security and Privacy Controls provides a practical reference for access review, monitoring, and revocation expectations.

When Salesforce is part of a larger integration mesh, the hardest failures appear at the boundary between app governance and secrets management, because the app may be approved while the underlying tokens, certificates, or service credentials remain unmanaged.

Related resources from NHI Mgmt Group

• How should security teams govern third-party access to development environments in cloud-native pipelines?
• How should security teams govern third-party access in complex B2B environments?
• How should security teams govern third-party SaaS app consent so access does not outlive the approving user?
• How should security teams govern third-party app access to cloud accounts in a zero trust model?