How to Secure Your Salesforce Environment

Why Salesforce Security Is Your Job

Salesforce holds some of the most sensitive data a company owns: customer records, pipeline and pricing, support cases, and the notes reps type after every call. When an org is misconfigured, that data walks out the door, and customer trust leaves with it.

Plenty of companies assume the platform handles security for them. Salesforce secures the infrastructure. Under the shared responsibility model for cloud security, what you configure on top of it (who gets access, and which apps you let connect) decides whether the data stays protected. A default Salesforce deployment is not a secure one.

What the 2025 Salesforce Breaches Showed

The largest Salesforce data thefts of 2025 ran on access that customers had granted themselves. Salesforce reported no platform vulnerability behind them.

Google Threat Intelligence tracked a group it calls UNC6040 that phoned employees while posing as IT support and talked them into authorizing a modified version of Salesforce’s Data Loader app. Once approved, the app pulled data in bulk, and extortion demands followed. Google later disclosed that one of its own corporate Salesforce instances was hit in the same campaign.

A second group, UNC6395, skipped the phone call. Between August 8 and 18, 2025, it used OAuth tokens stolen from the Salesloft Drift integration to query customer Salesforce instances directly, then searched the exported records for secrets like AWS keys and Snowflake tokens. The FBI followed with a FLASH alert covering both groups.

Neither attack needed a stolen password. One got a user to click Allow. The other reused a token the org already trusted. That pattern reaches well beyond Salesforce: the 2025 Verizon Data Breach Investigations Report found third-party involvement in breaches doubled to 30%. The bill is real too, with IBM’s 2025 Cost of a Data Breach report putting the global average breach at $4.44 million.

Which Controls Stop Which Attacks

No single setting covers Salesforce. Here is how the main controls line up against what attackers actually did in 2025, including what each one misses.

Implement the Principle of Least Privilege

The most common Salesforce mistake we find is users holding more access than their job needs. Sales reps do not need financial records. Marketing does not need support case details. Every user gets the minimum, and nothing more.

Start by auditing permission sets and profiles. Salesforce lets you control access down to individual fields and records, so use that granularity. Replace broad profiles with targeted permission sets and permission set groups. Remove Modify All Data and View All Data from any profile that does not absolutely require them, because those two permissions bypass every other access control. In both 2025 campaigns, the damage scaled with whatever the compromised user or integration could read.

Review sharing rules every quarter. As teams grow and reorganize, rules pile up and grant broader access than anyone intended.

Enforce Strong Authentication

Passwords alone will not protect Salesforce. MFA should be mandatory for every user, and Salesforce contractually requires it for direct logins. CISA calls MFA one of the most effective controls against account compromise, and its guidance on phishing-resistant MFA is blunt that push prompts and SMS codes can be phished while FIDO2 security keys resist it. Salesforce supports security keys alongside Salesforce Authenticator. Put admins on keys first.

Set session timeouts that match your risk tolerance, shorter for administrators than for standard users. An idle session on an unlocked laptop is an open door.

Restrict login IP ranges where you can. If your team works from known offices or through a corporate VPN, limit Salesforce access to those ranges so stolen credentials fail from anywhere else.

MFA has a limit, and 2025 exposed it. The employees who approved UNC6040’s fake app were already logged in, so their second factor never came into play. That is why connected app control now matters as much as authentication.

Control API Access and Connected Apps

Every connected app with API access can read, write, or delete data at machine speed. In 2025 this became the main route attackers used to get Salesforce data out.

Audit every connected app in your org and remove the ones nobody uses. For the rest, confirm each app requests only the scopes it needs. An integration that syncs contact names and emails has no business touching financial objects.

Then close the door the vishing campaign walked through. Limit the Approve Uninstalled Connected Apps permission to a small group of admins, so a regular user on the phone with a fake help desk cannot authorize a new app alone. Where your edition supports it, turn on API Access Control so only allowlisted apps can call the API at all.

Give each integration its own dedicated user, scoped to the objects it syncs and restricted to the vendor’s IP ranges. Authenticate with OAuth 2.0 instead of stored passwords, and know how to revoke a vendor’s tokens in minutes. Salesloft and Salesforce revoked the Drift tokens once the theft surfaced, but your org should not wait on a vendor to pull the plug. Watch API volume per integration too. A sudden spike from a sync job that normally runs quietly deserves a look the same day.

Scope AI Agents Like Any Other Integration

Agentforce and other AI agents now read and act on CRM data inside Salesforce. An agent runs under an identity with permissions, the same as an integration, and it will do whatever those permissions allow when a prompt or a poisoned record steers it somewhere unexpected.

Give each agent a dedicated user with the narrowest permission set that lets it do the job. Keep agents away from objects holding regulated data unless the use case truly requires it, and log agent actions with the same Event Monitoring you use for people. We run AI operations for clients, and the agent permission review is the step we refuse to skip.

Encrypt Sensitive Data

Shield Platform Encryption protects data at rest without breaking most platform features. Identify fields holding sensitive data (Social Security numbers, driver’s license numbers, financial account details, health information) and encrypt them. Shield supports customer-controlled keys and keeps reports and search working on most encrypted fields. NIST SP 800-111 lays out storage encryption principles that apply to data at rest in a platform like Salesforce. Shield is a paid add-on, and for organizations handling regulated data it usually earns its place on compliance grounds alone.

Be clear about what encryption cannot do. Every record taken in the 2025 campaigns left through an authorized app or token, and platform encryption decrypts for anything with permission to read the field. Encryption guards against a different threat. Access control and monitoring guard against this one.

Review exports and backups as well. A CSV sitting on a laptop defeats platform encryption entirely, so any data leaving Salesforce needs equal protection for as long as it exists.

Monitor and Audit User Activity

You cannot protect what you cannot see. Salesforce keeps login history and a setup audit trail by default, and many organizations never read either. Turn on field history tracking for sensitive objects while you are at it.

Event Monitoring, part of Salesforce Shield, goes deeper. It captures report exports, API calls, Bulk API jobs, and login forensics. Transaction Security policies can act on those events in real time, blocking an export or raising an alert when someone pulls more records than a threshold you set.

Establish what normal looks like for each team and alert on deviation. A finance user who opens a few dozen records a day and suddenly exports the entire Account table warrants an investigation that afternoon. The 2025 thefts showed up as large API queries from apps the victim orgs had never seen before. Monitoring surfaces exactly those events, as long as someone reads the alerts.

Manage Data Access at the Record Level

Object and field security control what users can see. Record-level security controls which specific records they can reach. You need both layers.

Set organization-wide defaults to the most restrictive level your business can run on, then open access with sharing rules and the role hierarchy where it is needed. New records then start restricted instead of open.

For your most sensitive records, use restriction rules to block access regardless of other sharing settings. That hard boundary suits data like executive compensation and active legal matters, where only named individuals should ever have a view.

Secure Sandbox and Development Environments

Production security means little if a full sandbox holds a copy of production data with relaxed controls. Developers and testers often have broader access in sandboxes than they would ever get in production.

Mask sandbox data with Salesforce Data Mask or use synthetic data. If you must test with production data, apply production access controls and monitoring to that sandbox. Treat sandbox credentials as seriously as production ones: a compromised sandbox reveals data patterns and integration architecture that will inform the next attack on production.

Refresh or delete stale sandboxes. Old ones carry outdated configurations and accounts belonging to people who left months ago.

Stay Current with Salesforce Security Updates

Salesforce ships seasonal releases plus critical patches as needed, and any release can change security defaults or retire older authentication methods. Read the security sections of the release notes before each update lands, and test authentication and API changes in a sandbox first.

Run Security Health Check after every release. It scores your org’s settings against the Salesforce baseline and flags anything that has drifted. Watch the Salesforce Trust site for platform security advisories, and when Salesforce publishes guidance on an active campaign, as it did more than once in 2025, act on it that week.

Build a Salesforce Security Culture

Technical controls only work when people follow them. Both 2025 campaigns started with a human decision: an employee trusting a caller, or an admin approving an integration without asking what it could reach. Train users to hang up on unsolicited IT support calls and call back through a known number. Train admins on what a permission change actually opens up.

Put security-relevant changes through change management. New integrations, connected app approvals, sharing rule edits, and permission set assignments should all get a security review before they go live. Adding a permission set to a profile looks harmless and can expose sensitive data across the whole org.

Document your Salesforce security architecture so it survives staff turnover: permission structure, integration inventory, encryption settings, and monitoring procedures.

Where to Start

Salesforce security never finishes. Permissions get reviewed quarterly and alerts get read daily, indefinitely. If you are starting today, work in this order: lock down connected app approval and audit every integration, put admins on phishing-resistant MFA, strip View All Data and Modify All Data, then turn on export monitoring. Those four moves map directly to how Salesforce data was stolen in 2025. Encryption and record-level hardening come next.

If you want a second set of eyes on your org, talk to our team. WeSolve runs managed IT and AI operations for companies across Los Angeles, and a connected app and permission review is a standard part of how we onboard Salesforce clients.