How can organisations defend against Salesforce data exfiltration?

How Salesforce data exfiltration usually happens

Salesforce exfiltration is rarely just a “download problem.” It usually comes from excessive access, overpermissive connected apps, stolen sessions, abused OAuth grants, or API-driven bulk export that looks legitimate unless you monitor it closely. The practical question is not only who can log in, but which identities, integrations, and reports can move large amounts of CRM data out of the tenant.

That is why the most effective defences combine access restriction with export control and telemetry. A mature approach starts with tighter profiles and permission sets, then extends to connected-app review, report/export limits, and detection for unusual query volume, bulk downloads, and API patterns that do not match normal sales or service workflows. For Salesforce-specific hardening, see the Salesforce Security Guide.

Which controls reduce the chance of successful exfiltration?

Least privilege is the first control worth getting right because exfiltration depends on who can see records, run reports, export data, and authorize apps. That includes admin roles, delegated support roles, integration users, and guest or external access paths where Salesforce data can be exposed indirectly. If a user does not need export capability, remove it rather than relying on policy alone.

Connected apps deserve the same scrutiny. Review OAuth grants, scopes, refresh-token lifetime, consent flows, and whether an integration truly needs broad read access or offline access. The fastest way to shrink the blast radius is to narrow token scope and remove unused or duplicated integrations. For a deeper pattern view of token and app abuse, compare this with the Salesloft OAuth token breach and the Klue OAuth Supply Chain Breach.

Authentication and session control matter because a stolen account often becomes a data theft event before the breach is obvious. Enforce strong authentication, shorten risky sessions where business use allows it, and make revocation operationally easy so the response team can kill sessions and tokens quickly when compromise is suspected. If a service or integration account is part of the trust chain, treat its credentials as a high-value secret rather than a routine admin artifact.

What to monitor, and what to do after suspected compromise

Monitoring should focus on the behaviours attackers need: unusually large report exports, spikes in API calls, atypical data queries, repeated downloads from a single identity, new connected-app approval, and access from unfamiliar locations or device patterns. If you can only watch one thing, watch for a change in export volume or query shape, because exfiltration often blends in until volume or timing gives it away.

When compromise is suspected, move in this order: revoke sessions and tokens, preserve logs, identify which reports, objects, and integrations were touched, and determine whether the same account was used to stage or automate export. If the incident involves stolen credentials or tokens, review whether other systems trusted the same identity material. The Data Exfiltration Guide is useful for mapping Salesforce-specific theft patterns to broader collection and exfiltration tradecraft.

Risk and Threat Considerations

Salesforce is attractive to attackers because it concentrates customer, pipeline, and support data in one place, and the same controls that make the platform useful can also make bulk theft fast. The main risk is not only direct export, but trust abuse through connected apps, delegated access, and long-lived tokens that continue to work after the original user activity looks normal.

Failure mechanism: Overprivileged users or integrations can query, report on, or export more data than they need, while stolen sessions or OAuth grants let an attacker act through a legitimate identity path. Once that path is available, exfiltration can happen through reports, API calls, or synchronized integrations with little immediate signal.

Impact: Loss of CRM records can expose customer details, account notes, deal data, support content, and embedded secrets, and it can also create follow-on fraud or social engineering risk if the stolen data contains relationship context.

Practitioner Guidance

What to verify: Confirm which personas can export, which connected apps can read customer objects, and whether any integration still has broad offline access that is no longer justified. Also verify that session revocation and token invalidation are tested, not just documented.

Decision rule: If an identity can export production CRM data or authorize an app that can do so, treat it as a tier-one exposure and reduce the privilege before you wait for perfect detection. If an account is already suspected of compromise, prioritise revocation and blast-radius assessment before deeper forensic tuning.

Practitioner takeaway: The core defence is to make Salesforce data movement intentionally narrow, observable, and quickly revocable, because exfiltration usually succeeds when access, tokens, and export paths are easier to keep than to govern.

Related resources from NHI Mgmt Group

• Guide: SaaS Security Guide
• How should organisations defend against account takeover fraud when attackers can automate credential testing with bots and breach data?
• How can organisations support forensic investigation of suspected data exfiltration?
• How can organisations reduce the risk of data exfiltration through AI chat sessions?
• How should organisations defend against attack-as-a-service identity fraud?