Salesforce threat detection is the monitoring and analysis of activity within Salesforce to spot suspicious behavior, account misuse, data exfiltration, and unauthorized changes. In practice, it correlates login patterns, API use, permission shifts, and object access to identify compromise, insider risk, and abuse of privileged human or non-human identities.
What Salesforce threat detection looks for
Salesforce threat detection focuses on the security signals that distinguish normal business activity from abuse. That includes unusual login location or timing, atypical API patterns, object access spikes, permission changes, data export activity, and administrative actions that do not fit the user or integration’s expected role.
Because Salesforce is both a system of record and a hub for connected apps, the detection problem is broader than simple login monitoring. A compromise can start with stolen credentials, a malicious OAuth token, an over-permissioned integration, or a rogue internal action, then move into record access, export, or configuration change.
Why Salesforce activity is hard to judge
Salesforce is noisy by design. Sales, service, operations, automation, and third-party integrations all create legitimate activity that can resemble abuse if it is viewed in isolation. Effective detection therefore depends on baselining what each profile, integration user, and connected app normally does, then highlighting deviations that matter.
Suspicious behaviour often shows up as a pattern, not a single event. For example, a successful login may be innocuous on its own, but paired with permission drift, API calls against unusual objects, and bulk data access it can indicate compromise or insider misuse.
When you build detection around context, not just alerts, you are better able to separate ordinary CRM usage from sessions that deserve investigation. That is especially important where a single account can touch customer data, case notes, files, custom objects, and downstream SaaS connections.
Common security signals in Salesforce
High-value detection logic usually combines identity, access, and data-use indicators. Salesforce Security Guide is a useful starting point for understanding the platform controls that shape those signals, including connected apps, access review, login activity, and Shield monitoring.
- Login anomalies, such as impossible travel, unfamiliar device patterns, or suspicious session reuse.
- API and integration anomalies, such as unusual request volume, new endpoints, or unexpected token use.
- Privilege changes, including permission set edits, role shifts, or connected app approval changes.
- Data movement indicators, such as mass export, unusual report runs, or access to records outside normal workflow.
- Object and field access out of pattern, especially when it involves sensitive customer or support data.
Threat detection is strongest when these signals are correlated across the same user, integration, or session. One event may be routine, but several together can show account takeover, abuse of delegated access, or quiet exfiltration.
How teams investigate and respond
When a Salesforce alert fires, investigators usually need to answer three questions: who acted, what they touched, and whether the activity extended beyond Salesforce. That often means reviewing login history, session lineage, connected app grants, audit logs, and any related email, identity, or endpoint telemetry.
Post-detection response should also consider business impact. If the activity involved CRM records, support notes, tokens, or privileged automation, the investigation may need to extend to credential rotation, permission review, and checks for changes made after the initial suspicious event.
The State of NHI & AI Agent Breach Report 2026 and Salesloft OAuth token breach both illustrate why token theft and connected-app misuse matter in Salesforce-centric environments.
Detection around Salesforce integrations and privileged access
Many Salesforce compromises are not caused by the core platform alone, but by the trust chain around it. Connected apps, middleware, sync tools, and automation users can create durable access paths that bypass normal human review if they are not monitored carefully.
That is why detection should include privileged human accounts and non-human identities alike. A service account that exports data on schedule may be legitimate, but a change in scope, timing, source IP, or object set can be a strong compromise indicator. In the same way, a human admin’s changes may deserve scrutiny if they occur outside the normal change window or from an unusual session context.
Klue OAuth Supply Chain Breach, Gainsight Salesforce breach 2025, and Palo Alto Networks Salesforce data theft 2025 show how third-party access and long-lived tokens can turn normal SaaS connectivity into a detection challenge.
Risk and Threat Considerations
Salesforce is attractive to attackers because a single compromised identity can expose customer records, support details, attachments, and integration pathways. The biggest risk is often not just login compromise, but quiet misuse of trusted access that blends into normal business activity long enough to exfiltrate data or alter records.
Failure mechanism: An attacker or insider abuses legitimate Salesforce access, then uses API calls, permission changes, or record access patterns that look routine unless they are correlated across identity, session, and data-use telemetry.
Impact: Organisations can lose confidentiality of CRM data, miss unauthorized configuration changes, and fail to notice that trusted integrations or privileged accounts were used as the path into deeper compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Salesforce alerts often hinge on compromised API and token use. |
| API5 — Broken Function Level Authorization | Privilege shifts and admin misuse in Salesforce map to function-level access abuse. | |
| Recommendation — Monitor API authentication anomalies and revoke suspicious tokens promptly. Verify that privileged Salesforce functions are restricted to the intended roles. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Threat detection in Salesforce depends on reviewing and correlating audit trails. |
| AC-6 — Least Privilege | Overprivileged users and integrations are central to Salesforce misuse and detection. | |
| Recommendation — Correlate Salesforce audit records with identity and session telemetry for suspicious patterns. Reduce Salesforce account and integration privilege to the minimum needed for each role. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Salesforce threat detection relies on collecting and reviewing activity logs. |
| Recommendation — Centralize and review Salesforce activity logs for compromise indicators. | ||
Practitioner Guidance
Why practitioners should care: Salesforce threat detection is only useful when it is tuned to the organisation’s actual users, apps, and business workflows. Generic alerting creates noise; context-aware detection identifies the accounts and integrations that would cause real harm if misused.
What to watch for: Treat unusual privilege changes, unexpected API behaviour, and bulk data access as a linked investigation, not separate events. The most valuable detections are usually the ones that connect identity behaviour to data movement and configuration drift.
Practitioner takeaway: Build detection around the trust relationships that make Salesforce valuable in the first place, then monitor for deviations that would matter if a human admin, service account, or connected app were already compromised.