Why integrations are a blind spot in Salesforce security

Most organizations have user access reasonably well organized. MFA is enabled, profiles are configured and there has been thought given to who can see what. But as soon as the conversation turns to integrations, the connections between Salesforce and other systems, that diligence often disappears.

Integrations communicate through APIs, authenticate via tokens and OAuth flows, and often run on service accounts with broad rights that are never reviewed. They are rarely visible in day-to-day operations, but they have continuous access to your most sensitive data.

That makes integrations one of the largest and most underestimated attack vectors in a Salesforce environment.

How Salesforce integrations are typically set up

In many organizations, integrations have grown historically. A connection to an ERP system, a marketing platform, a data warehouse or an external application: each with its own authentication method, its own service account and its own rights structure.

The problem is that these connections are rarely built from a security perspective. They are built from functionality: the connection has to work, the data has to flow. Security is an afterthought, or is added later.

The result is an integration landscape in which:

• Service accounts have system administrator privileges because that “was the easiest way”
• Tokens never expire or get rotated
• No one has a complete overview of which external systems have access to Salesforce
• Outdated connections are still active, even though the application on the other side is no longer in use

The three pillars of secure Salesforce integrations

A secure integration landscape is built on three pillars: the right authentication method, least privilege per integration and active token management.

Pillar 1: OAuth as the standard authentication method

The foundation of every secure Salesforce integration is OAuth 2.0. OAuth prevents integrations from storing and exchanging direct user credentials: instead, they work with tokens that grant limited access for a specific period.

The most commonly used OAuth flows for Salesforce integrations are:

• JWT Bearer Token flow: the recommended method for server-to-server integrations without user interaction. The integration authenticates with a digital certificate instead of a password
• OAuth 2.0 Client Credentials flow: suitable for automated processes that act on their own behalf, not on behalf of a specific user
• Web Server flow: for integrations in which a user explicitly grants permission to an external application

Avoid the Username-Password OAuth flow. This method stores credentials inside the integration itself and offers no advantage over direct authentication: it is the least secure option and should no longer be used.

Pillar 2: Least privilege per integration

Every integration should only have access to the data and functionality strictly necessary for its task. In practice this means:

• Create a dedicated service account for every integration, never a shared account
• Assign the service account a minimal profile, supplemented with a specific permission set that contains only the required objects and fields
• Use the API Only User permission for service accounts so that interactive login is not possible
• Document per integration which objects, fields and actions are accessible, and why

Using a system administrator account as a service account is one of the most common and most dangerous mistakes in Salesforce integrations. If that account is compromised, the attacker has full access to your entire environment.

Pillar 3: Token governance

Tokens are the keys with which integrations gain access to Salesforce. If tokens are not actively managed, they become a risk:

• Set token expiration: access tokens should have a limited validity, refresh tokens should be rotated periodically
• Monitor token usage for unusual activity, such as many requests outside office hours, unfamiliar IP addresses or unexpected data volumes: that is a signal that something is wrong
• Revoke tokens when an employee leaves or when an integration is decommissioned: a token that is no longer needed but still valid is an open door
• Manage tokens centrally: where possible, use a secrets manager or a vault solution rather than storing tokens hard-coded in configuration files

The impact of Spring '26 on your integration landscape

The Spring '26 release has direct consequences for existing integrations. Two changes are particularly relevant:

The deprecation of SOAP login() means that integrations still using direct credential authentication via SOAP must be migrated to OAuth. This is not optional but mandatory: in Summer '27, SOAP login() will no longer work.

The replacement of Connected Apps with External Client Apps affects how integrations are registered in Salesforce. New integrations must be set up as External Client Apps. For existing Connected Apps, migration is necessary in due course.

This is a good moment to evaluate your integration landscape as a whole. Which connections are active? Which are outdated? Which authentication methods are in use? An integration audit gives you that overview.

How do you carry out an integration audit?

An integration audit starts with an inventory:

• Go to Setup > Connected Apps OAuth Usage in Salesforce for an overview of all active OAuth connections and their usage
• Check which service accounts are active and which rights they hold
• Review the Event Monitoring logs for API activity: which external systems are communicating with Salesforce, how often and with what data volumes?
• Compare the integrations you find against the list of officially approved systems: anything not on that list deserves further investigation

Based on that inventory, you can set priorities: shut down outdated integrations, replace insecure authentication methods and bring service accounts back to least privilege.

Conclusion

Integrations are not a peripheral concern in your Salesforce security: they are a fully fledged attack vector that deserves as much attention as user access. The combination of OAuth as the standard, least privilege per service account and active token management forms the basis of a secure integration landscape.

In a world where Salesforce becomes ever more deeply intertwined with the rest of your IT environment, the question is not whether you should secure your integrations: but when you start.

Want to know how your current integration landscape stands? Schedule a no-obligation conversation