Salesforce Security is the set of controls that protects data, users, integrations, and automations inside a Salesforce environment. In practice, it combines IAM, least privilege, MFA, session controls, monitoring, data loss prevention, and governance for human and non-human identities, including connected apps, API access, and privileged configuration changes.
What Salesforce Security Covers
Salesforce Security is not a single control, but a layered security programme for a business platform that stores sensitive records, exposes APIs, and supports workflows, approvals, and integrations. Its scope includes user access, connected apps, session policy, monitoring, and governance for changes that can affect data exposure.
Because Salesforce often becomes a system of record and a system of action at the same time, weaknesses in one layer can quickly affect others. A permissive profile, an overbroad permission set, or a trusted integration can each become a path to data access or unintended actions.
Why Salesforce Environments Become High-Value Targets
Salesforce environments concentrate customer data, support data, sales pipelines, and operational automations, which makes them attractive to both attackers and opportunistic insiders. The most important security issue is rarely the application shell itself, but the trust relationships around it, especially identity, delegated access, and third-party integrations.
Connected apps and OAuth grants are especially important because they can preserve access even when a password is changed. NHIMG’s Salesloft OAuth token breach and Klue OAuth Supply Chain Breach show how token theft and SaaS-to-SaaS trust chains can extend into Salesforce data access.
Identity, Access, and Integration Controls
Salesforce security depends on separating who can log in, what they can see, what they can change, and which automations can act on their behalf. That means treating profiles, permission sets, roles, session settings, MFA, connected app scopes, API users, and admin roles as one control surface rather than isolated features.
When organisations rely on SSO or API-based integrations, they should also account for token lifetime, offboarding, and privilege drift. The practical question is not only whether a user is authenticated, but whether the access path still makes sense after role changes, vendor changes, or account compromise.
For Salesforce-specific hardening patterns, the Salesforce Security Guide covers connected apps, permission sets, Experience Cloud guest access, and Shield monitoring as part of the same governance model.
Monitoring, Data Exposure, and Change Governance
Security in Salesforce also depends on visibility into login activity, data export events, permission changes, and unusual automation behaviour. Event logs, Shield monitoring, and admin audit trails help answer a simple but critical question: did the platform behave as expected after access was granted?
Governance matters because many Salesforce incidents are not caused by a single exploit, but by a chain of ordinary permissions, stale integrations, and weak review discipline. The same applies to AI-assisted functionality, where autonomous actions can create new exposure if the agent boundary is not tightly constrained.
NHIMG’s SalesBleed Salesforce Agentforce 2026 and Securing Salesforce Agentforce Guide show why agent permissions, trusted URLs, and traced actions matter when automation can read or send CRM data.
Risk and Threat Considerations
Salesforce risk usually emerges when broad privileges, long-lived tokens, weak connected-app governance, or guest-facing features create an easier path to data exposure than intended. Attackers often prefer these paths because they blend into normal business activity and can survive password resets, especially when the real trust anchor is an API token or integration grant.
Failure mechanism: Excessive permissions, stale OAuth grants, exposed APIs, and weak monitoring let an attacker or compromised integration read, export, or modify CRM data without triggering immediate suspicion.
Impact: Sensitive customer, sales, and support data can be exfiltrated, automation can be abused to send malicious messages or alter records, and recovery may require revoking tokens, reviewing connected apps, and revalidating privileged changes.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Salesforce security depends on governing user and admin accounts across the org. |
| IA-5 — Authenticator Management | OAuth tokens, session credentials, and other authenticators are central to Salesforce access. | |
| AU-6 — Audit Review, Analysis, and Reporting | Monitoring login activity, exports, and admin actions is essential to Salesforce detection. | |
| Recommendation — Review and remove stale Salesforce accounts, roles, and admin access on a defined cadence. Rotate and revoke Salesforce authenticators and integration secrets when access changes. Analyze Salesforce audit logs for unusual logins, exports, and privileged changes. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Salesforce API and connected-app access rely on strong token and session handling. |
| Recommendation — Harden Salesforce API authentication and invalidate compromised tokens promptly. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Connected apps, API users, and automations in Salesforce can accumulate excessive privilege. |
| Recommendation — Reduce Salesforce integration and automation privileges to the minimum required. | ||
Practitioner Guidance
Why practitioners should care: Salesforce security is really an access-governance problem wrapped around a business platform. The most effective control decisions usually come from reviewing who can act, which integrations are trusted, and where monitoring can prove that access stayed within intended bounds.
Common misunderstanding: Many teams focus on user passwords and miss the larger risk posed by connected apps, API credentials, guest exposure, and overprivileged automation. A strong login policy does not compensate for a weak integration trust model.
Practitioner takeaway: Treat Salesforce as a governed control plane for data and automation, not just as a SaaS application with a few admin settings.