Our Top 6 Salesforce Security Tips for 2026

Back in 2019, we published a list of five basic Salesforce security tips to help organizations minimize breaches caused by employee error or malicious intent. A lot has changed since then: Salesforce has raised the security floor for every customer, the threat surface has expanded well beyond human logins, and significant change emerged that the original list couldn’t have anticipated… AI agents acting inside your org.

Here’s an updated take on Salesforce security, built on the same practical foundation as our original post but revised for where the platform (and the risks) actually stand today.

Table of Contents:

1. Get Multi-Factor Authentication Right, Not Just Turned On
2. Configure Network-Based Security
3. Monitor Login History – and Agent Activity
4. Govern Connected Apps and OAuth Access
5. Use Dedicated Integration and Agent Accounts
6. Govern Your AI Agents (Agentforce)
7. Wrap Up

1. Get Multi-Factor Authentication Right, Not Just Turned On

In 2019, enabling two-factor authentication was itself the recommendation. That’s no longer the case, Salesforce has required MFA for all direct UI logins since 2022, so if your org is live, MFA is already on. The relevant question for 2026 isn’t “should we enable it,” it’s “is our implementation actually strong.”

That means moving users off SMS-based verification, which remains vulnerable to interception and SIM-swapping, and toward the Salesforce Authenticator app or passkeys. It also means extending high-assurance session requirements beyond login to cover sensitive reports and Data Cloud exports, and revisiting any legacy MFA exceptions or bypasses that were granted years ago and never reviewed since.

Pro Tip: Audit your Identity Verification and Session Security Level policies at least annually,  these are often set up once during implementation and never touched again.

2. Configure Network-Based Security

This recommendation from way back in 2019 holds up well, but it’s worth expanding. Trusted IP Ranges are still a simple, effective way to reduce your attack surface; users logging in from outside known office or VPN ranges should still be challenged to verify their identity.

For 2026, pair org-wide Trusted IP Ranges with Login IP Ranges set at the profile level for tighter enforcement on your most sensitive user groups. And make sure Enhanced Domains and My Domain are fully deployed across your org; a growing number of newer Salesforce security features, including several Agentforce and Shield capabilities, depend on them being in place.

3. Monitor Login History – and Agent Activity

Tracking login history is still good practice. Salesforce’s standard “New Login Location Report” remains a fast way to catch a user logging in from somewhere unexpected; a signal that historically has helped organizations catch data exfiltration attempts before an employee departure, for example.

What’s changed is that human logins are no longer the only activity worth watching. If your org runs Agentforce, you now have non-human identities reading and writing records on their own. Extend your monitoring practice to include agent action and reasoning logs through Shield or Event Monitoring, not just human login events. An agent quietly operating outside its intended scope is a much harder problem to notice than a departing employee running a bulk export – which is exactly why it needs its own monitoring discipline.

4. Govern Connected Apps and OAuth Access

The core principle from our original post is unchanged: don’t let end users unknowingly grant third-party applications access to your org. A well-meaning employee connecting a messaging tool to get Opportunity notifications can just as easily create a compliance gap they never intended.

What’s changed is the tooling. “App Whitelisting” is now managed through Connected App OAuth policies, and Salesforce has introduced External Client Apps as a more granular, more secure successor to legacy Connected Apps for many use cases. The bigger addition for 2026 is scrutiny of anything requesting API access with AI in the loop – MCP servers, AI copilots, and third-party agent platforms can carry far broader data-access implications than a typical point integration, and deserve a stricter review before approval.

5. Use Dedicated Integration and Agent Accounts

This tip ages well; it just needs to be widened. The logic that says a human’s personal login shouldn’t be running your marketing automation integration applies just as directly to AI agents. Each integration, and now each AI agent, should run under its own scoped, auditable identity – a dedicated user with a custom profile and permission set, never inheriting a broad admin footprint or a shared service account used for five other things.

This matters more now than it did in 2019, simply because there are more non-human identities operating in a typical org than ever before, each one a potential blast radius if over-permissioned.

6. Govern Your AI Agents (Agentforce)

This is the tip that the original list from 2019 couldn’t have anticipated. But we can’t give you a list of Salesforce tips that completely ignores the Agents. 

Agentforce inherits your org’s existing profiles, permission sets, and sharing rules by design,  which is a strength, since there’s no separate permission system to keep in sync. But it also means that permissions scoped too loosely for a human user become AI-scale problems fast, because agents can act continuously and at a speed no human user does.

Salesforce’s Einstein Trust Layer covers important ground here: it secures data in transit, enforces zero data retention with third-party LLMs, and flags inappropriate outputs. However, it’s important to understand where the job ends. The Trust Layer checks whether a prompt is safe, but it doesn’t check whether an agent should actually be editing a record. That boundary comes down to your Action Layer setup, permission sets, and sharing rules.

Practical steps for 2026:

• Apply least-privilege permission sets scoped to each agent’s specific job, a support agent summarizing case notes has no reason to touch Opportunity or financial records.
• Require human approval for higher-risk actions: anything that creates, modifies, or deletes records, or sends external communications.
• Use Shield to monitor agent reasoning paths and flag anomalies, the same way you’d monitor a privileged human user.
• Treat agent permissions as living controls; reassess them on a regular basis as agents are retrained or connected to new data sources, the same way you’d review access after a role change.

Wrap Up

The fundamentals from 2019 hold: strong authentication, network controls, activity monitoring, and tightly scoped integration accounts are still the backbone of a secure Salesforce org. What’s changed is the scope of what “access” means. Your org now has non-human identities acting inside it, and they need the same rigor you’d apply to your most privileged human users, applied consistently and reviewed often.