Securing Your Org: From Reactive to Proactive

Before TDX 2026, the Admin Relations, Security, and Trusted Services teams brought admins together for an Admin Day of Security with a clear goal: to position Salesforce Admins as proactive security leaders in the agentic era. Throughout the day, we aligned on how chief information security officers (CISOs) and admins can work more closely together, explored what’s new and what’s next in Salesforce security, and carved out space for them to ask the Product team direct questions. 

The biggest takeaway? Admins didn’t just leave with insights; they got practical actions to take right away to strengthen their security posture.

We closed the day with roundtable discussions focused on one central shift: moving from a reactive security mindset to a proactive one. Security isn’t just a compliance checkbox. It’s about intentionally building Salesforce environments that are resilient by design, through thoughtful configuration, continuous visibility, and strong foundational practices. We discussed four key areas where this mindset shift shows up in real admin work. Let’s explore the difference between a reactive and proactive strategy for each discussion prompt.

Identity and access: Beyond MFA

In addition to multi-factor authentication (MFA), what other controls are you using to block suspicious authorization attempts?

Reactive strategy

A reactive admin typically relies on baseline MFA protections and deactivates users after they leave the organization. It’s a “respond when needed” approach: effective in the moment, but limited in preventing risk before it happens.

Proactive strategy

A proactive admin takes a much broader view of identity and access. This includes:

• Setting up trusted IP ranges and enforcing them on every request
• Tightening login hours for users and profiles to reduce opportunities for unauthorized access outside of expected business hours
• Working with your IT department to set up phishing-resistant MFA rather than traditional MFA methods
• Setting up conditional access and Just-In-Time (JIT) provisioning with single sign on (SSO)
• Monitoring suspicious login behavior with Salesforce Shield Event Monitoring, including repeated failed logins, impossible travel scenarios, excessive API authentication attempts, or unusual geographic access patterns
• Restricting and regularly reviewing Connected Apps and OAuth scopes to prevent unauthorized third-party applications from gaining excessive access to org data

Salesforce is also pushing this model forward with stronger identity requirements, including enforcement of phishing-resistant MFA for privileged users. This means that all users with the System Administrator profile, Modify All Data, View All Data, Customize Application, or Author Apex permissions will require phishing-resistant MFA verification methods. This is a meaningful shift toward protecting the most sensitive access points in your org by default. 

Permissions

What can we do to limit the number of admins and programmatically ensure that managed package standard permissions don’t over-privilege our users?

Reactive strategy

Reactive admins tend to notice permission issues only after users report access problems or during periodic audits. At that point, cleanup becomes the primary focus, not prevention.

Proactive strategy

A proactive approach is built on design, not cleanup. This starts with:

• Building scheduled audits using reports, flows, or custom monitoring to identify users receiving sensitive permissions
• Incorporating security reviews into release management processes before enabling new features or package updates
• Transitioning to a permission-led security model that leverages the Minimum Access Profile and layers on permission sets and permission set groups to enforce the principle of least privilege (PoLP)
• Using Muting like a filter on permission set groups to deliver the final permissions to your users
• Regularly comparing assigned permissions against approved baselines or personas

Check out the Salesforce Admin’s Guide to Profiles and Permissions to learn more.

Data loss prevention

How can we block users from exporting records and prevent data exfiltration? 

Reactive strategy

A reactive approach usually shows up after the fact, like reviewing export logs or investigating a potential breach once data has already been exposed. A position none of us want to be in!

Proactive strategy

A proactive Salesforce Admin approaches data exfiltration prevention by designing layered controls that reduce both intentional and accidental data exposure before it becomes a problem. Rather than waiting for a security incident or audit finding, admins can build guardrails directly into the platform to limit unnecessary access and monitor risky behavior. Some proactive strategies include:

• Restricting the Export Reports and API Enabled permissions to only users who truly need them (again following the PoLP)
• Using Data Classification to identify sensitive fields such as personally identifiable information (PII), financial information, or confidential business data so security decisions can be prioritized around the most critical data
• Leveraging Salesforce Shield Event Monitoring to track behaviors like report exports, bulk API usage, suspicious logins, or unusually large data downloads, which helps admins and security teams identify risky activity early instead of discovering it after data has left the organization
• Using Transaction Security Policies to automatically block or challenge risky activities in real time, such as mass exports, downloads from unmanaged devices, or exports outside approved geographic locations

Environment integrity

How are you automating the obfuscation of sensitive data? Does your sandbox security mirror production, or is it a “weakest link” backdoor?

Reactive strategy

A reactive mindset assumes sandbox data is “safe enough” and trusts users not to look at or misuse it. That’s where risk tends to accumulate quietly.

Proactive strategy

A proactive approach treats sandboxes and scratch orgs as potential exposure points from the start. Admins might combine or layer several of these approaches:

• Using Data Mask to automatically anonymize PII and sensitive fields immediately after a sandbox refresh
• Defining clear data classification rules so sensitive fields are consistently identified and treated across all environments
• Using user permission controls in sandboxes that mirror production least-privilege access, rather than defaulting to broad access for convenience during testing
• Setting up Scratch Org Security practices for your sandboxes; You don’t have to use scratch orgs to employ set security practices around how your Salesforce orgs are created, configured, and governed in a DevOps model.

The proactive mindset

A reactive security strategy waits for something to go wrong—an alert, a ticket from IT, or a failing Health Check score—before admins take action. A proactive strategy assumes that risk is ongoing and builds systems that reduce exposure by design.

Security isn’t a one-time configuration or a monthly checklist. It’s an ongoing discipline built into how an org operates. Proactive admins don’t just respond to risk; they build environments where risk is continuously minimized, visibility is always on, and security posture improves over time. That’s what it means to build Salesforce orgs that are resilient, self-defending, and ready for what’s next.

Go deeper into security fundamentals with a Security In Action: Data and Access hands-on workshop.

Resources

• The 360 Blog: Strengthening Salesforce Security Against AI-Driven Threats
• Trailhead: Security Basics
• Trailhead: Enhanced Transaction Security
• Trailhead: Security Culture