Salesforce Security Hardening: User Setup, IP Restrictions, Shield Encryption, and Event Monitoring
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Salesforce orgs start with well-intentioned permission configurations and accumulate years of emergency grants, 'copy this user's profile' setups, and integration accounts with System Administrator profiles because that was the easiest way to make the integration work. The Salesforce Security Health Check is the fastest starting point: it scores your current configuration and surfaces the specific settings that need remediation.
Authentication: MFA and SSO Enforcement
Salesforce has required MFA for direct logins since February 2022. Organizations using SSO (SAML 2.0 via Okta, Entra ID, or another IdP) must enforce MFA at the IdP level.
Configure SSO and delegate MFA to your IdP
In Salesforce Setup: Single Sign-On Settings > Enable SAML. Configure your IdP (Okta, Entra ID) as the SAML identity provider. Assign the Salesforce SAML app in your IdP to all Salesforce users and enforce MFA (phishing-resistant FIDO2/passkeys for privileged users, TOTP minimum for all others) at the IdP policy level before the SAML assertion is issued. This centralizes MFA management in your IdP rather than Salesforce's built-in Authenticator.
Disable Salesforce-local login for SSO users
Users configured with SSO should not be able to log in with a Salesforce username/password as a fallback. In Setup > Users, verify that SSO-configured users have 'Is Single Sign-On Enabled' checked and have no Salesforce password set (or a 64-character random password stored nowhere accessible). The bypass risk: Salesforce allows password login even for SSO-enabled users unless you explicitly require SSO.
Enable Login Flows for risk-based step-up authentication
Salesforce Login Flows allow adding custom authentication logic at login. Create a Login Flow that triggers MFA step-up for: logins from outside trusted IP ranges, logins to admin profiles, logins at unusual hours. Assign the flow to System Administrator profiles and any profiles with 'Modify All Data' permission.
Audit and revoke API-only integration tokens
Connected Apps with long-lived OAuth tokens can access Salesforce data without user interaction or MFA. Audit connected apps: Setup > Connected Apps OAuth Usage. For each connected app, review the scope granted, the last used date, and whether it still has active users. Revoke unused connected apps and restrict active ones to the minimum required OAuth scopes. Integration accounts with System Administrator profiles are the highest-risk finding.
Network Controls: Trusted IP Ranges
Salesforce profile-level trusted IP ranges restrict logins to specified IP ranges per profile. Users outside the trusted range receive an email verification challenge.
Configure trusted IPs on System Administrator profiles
System Administrator and 'Modify All Data' profiles should have the strictest IP restrictions. In Setup > Profiles > System Administrator > Login IP Ranges: add your corporate office IP ranges, your VPN egress IPs, and your PAM system's egress IP. Remove the 0.0.0.0/0 default that allows logins from any IP. This forces admin logins to originate from known locations.
Set org-wide trusted IP ranges for all profiles
Setup > Security Controls > Network Access: add your corporate IP ranges as org-wide trusted IPs. Users logging in from trusted IPs bypass the email verification challenge; users from untrusted IPs receive a one-time email verification code. This is weaker than profile-level IP restrictions but applies universally and provides friction for credential-stuffing attempts from external IPs.
Configure session security levels for API vs. UI access
Setup > Session Settings: set the session security level required for API access higher than standard session (Standard session = password only; High Assurance = MFA-verified). Require High Assurance for report exports and bulk data API access. This forces additional authentication for the highest-risk data access operations even within an authenticated session.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Least Privilege: Profiles, Permission Sets, and FLS
Salesforce profiles control what objects and fields a user can access and what operations (CRUD) they can perform. Permission sets grant additive permissions on top of a profile. Field-Level Security (FLS) controls which fields are visible and editable per profile.
Audit System Administrator profile holders
In Setup > Users: filter by Profile = System Administrator. This role has access to all data, all configuration, and all connected apps. Reduce this list to named individuals with a documented business requirement. Integration accounts should never use the System Administrator profile: create a custom profile with only the specific object and field permissions the integration requires.
Remove Modify All Data and View All Data from non-admin profiles
These two permissions grant object-level access to all records regardless of sharing rules, ownership, or role hierarchy. Search all profiles: use the Permission Set and Profile comparison tool in Setup > Permission Set Groups. Remove both permissions from every profile that is not explicitly a system administration profile. Custom profiles for sales, service, and marketing should never have these permissions.
Enforce FLS on sensitive fields
For fields containing financial data, health information, or PII (SSN, credit card, salary): verify FLS is set to Not Visible for all profiles that do not require it. In Setup > Object Manager > [Object] > Fields > [Field] > Set Field-Level Security: uncheck Visible for all profiles except those with a documented need. FLS applies to both UI and API access: an integration account without FLS visibility on a field cannot read it via REST API either.
Use Permission Set Groups to manage least-privilege bundles
Instead of modifying profiles directly (which affects all users on that profile), create Permission Sets for specific capabilities (view sensitive accounts, bulk export contacts, manage integrations) and group them in Permission Set Groups. Assign the group to individual users who need the capability rather than changing the base profile. This makes least-privilege visible and auditable: a user's effective permissions = profile base + assigned permission set groups.
Salesforce Shield: Encryption and Event Monitoring
Salesforce Shield is an add-on that provides Platform Encryption (field-level encryption with customer-managed keys) and Event Monitoring (detailed activity logs).
Identify fields for Platform Encryption
Platform Encryption encrypts field values at rest in Salesforce's database. Apply to: social security numbers, credit card numbers, bank account numbers, health-related fields, salary and compensation fields. In Setup > Platform Encryption: enable encryption for each field individually. Note: encrypted fields cannot be used in formula fields, workflow rules, or external ID filters: test encryption impact on automations before enabling in production.
Enable Event Monitoring and forward to SIEM
Shield Event Monitoring captures: ReportExport (every report export with the user, record count, and report name: the primary indicator of bulk data extraction), ApiEvent (every API call including endpoint, record count, and user), LoginEvent (authentication details), and LightningInteraction (detailed UI interaction data). Enable event log file download via API: GET /services/data/v58.0/sobjects/EventLogFile/query?q=SELECT+LogFile+FROM+EventLogFile. Forward to Splunk, Sentinel, or QRadar via the Salesforce Shield connector.
Alert on high-volume report exports
An account being exfiltrated will often show a user running report exports across multiple object types in a short time. Build a detection rule: alert when a single user generates more than 5 report exports in 30 minutes, or when a single export contains more than 10,000 records for an account that normally exports fewer than 1,000. This catches both compromised account exfiltration and departing employee data theft.
Security Health Check and Ongoing Governance
The Salesforce Security Health Check provides a scored assessment of your org's security configuration. Run it quarterly and track the score over time.
Run and address the Security Health Check
Setup > Security > Health Check: the tool scores your org on a 0-100 scale across password policies, session settings, network access, and connected app settings. Target a score above 80. Common findings: password never expires for integration users (toggle minimum password age), session timeout longer than 12 hours, inactive session cleanup disabled, and no trusted IP ranges set for admin profiles.
Conduct quarterly permission reviews with Salesforce Optimizer
Run the Salesforce Optimizer report (Setup > Optimizer): it identifies profiles with unused permissions, users who have not logged in for 90+ days, and fields with data quality issues. The Inactive Users report is particularly important: Salesforce licenses are active until explicitly deactivated, and inactive accounts with API tokens remain valid attack vectors.
The bottom line
The Salesforce Security Health Check is the fastest way to find the biggest gaps in a Salesforce org: run it first and address every finding below 80. For most orgs, the two hardest-to-fix findings are System Administrator profile overuse (integration accounts, shared admin accounts, former employees not fully deprovisioned) and FLS on sensitive fields that was never configured because 'everyone in sales needs to see it.' Both require a permissions review conversation with the business, not just a configuration change. Shield Event Monitoring is the detection layer that makes the others matter: without logs on report exports and API activity, you have no way to know if the hardening is working.
Frequently asked questions
What is the Salesforce Security Health Check and what does it test?
The Salesforce Security Health Check (Setup > Security > Health Check) is a built-in tool that scores your org's security configuration from 0 to 100 against Salesforce's Baseline Standard. It tests: password policy strength (minimum length, complexity, expiration, history), session settings (timeout, security level for operations, IP locking), network access (trusted IP ranges, login hour restrictions), and connected app settings (OAuth refresh token policies, IP restrictions). Findings are categorized as High Risk (fails Baseline Standard), Medium Risk (below best practice), and Informational. Start any Salesforce security assessment here.
How do I find and remove inactive Salesforce users?
Query inactive users via Salesforce SOQL: SELECT Id, Name, LastLoginDate, IsActive FROM User WHERE IsActive = TRUE AND LastLoginDate < LAST_N_DAYS:90 OR LastLoginDate = null. This returns licensed users who have not logged in for 90 days. Deactivate (do not delete: Salesforce does not support user deletion, and deactivation preserves data ownership) users who no longer need access: Setup > Users > [user] > Edit > Active = unchecked. Coordinate with HR to run this process as part of the offboarding workflow: departing employees should be deactivated in Salesforce on their last day.
Does Salesforce Shield Platform Encryption work with Salesforce search?
Salesforce Shield Platform Encryption uses probabilistic encryption by default, which means encrypted field values cannot be used in exact-match searches: searching for a specific SSN returns no results. For fields that need to remain searchable, use deterministic encryption instead (configured per field in the encryption policy). Deterministic encryption is searchable but provides weaker encryption guarantees (the same plaintext always produces the same ciphertext, enabling frequency analysis). Most implementations use probabilistic encryption for SSNs and financial data, and deterministic encryption for identifier fields that internal tools query by exact match.
What is the difference between Salesforce Profiles and Permission Sets?
Profiles are mandatory: every Salesforce user has exactly one profile, and the profile defines the baseline: what objects they can see, what operations they can perform (CRUD), which fields are visible, and which apps appear in their navigation. Permission Sets are additive and optional: they grant additional permissions on top of a profile without changing the base. Best practice: profiles should be minimal (minimum required for the role type), and Permission Sets should grant any additional access needed for specific users or tasks. This approach makes permission sprawl visible and auditable, unlike modifying profiles directly which affects all users on that profile.
How do I detect data exfiltration from Salesforce?
Shield Event Monitoring is required for meaningful exfiltration detection. The primary indicators: (1) ReportExport events with unusually high row counts or unusually frequent exports from a single user: alert on more than 5 exports in 30 minutes or exports exceeding your normal maximum row count; (2) ApiEvent events showing bulk SOQL queries against Contact or Lead objects from an API client that does not normally do bulk queries; (3) LoginEvent anomalies: logins from new countries or IPs outside trusted ranges followed immediately by bulk API activity. For organizations without Shield, Salesforce audit trail (Setup > View Setup Audit Trail) captures configuration changes but not data access events.
What Salesforce permissions are most commonly over-provisioned?
Based on common audit findings: (1) Modify All Data and View All Data on non-administrator profiles: often granted to solve a specific record-access problem without understanding the full scope; (2) System Administrator profile on integration accounts: granted because 'it was the easiest way to make it work'; (3) Manage Users permission on non-administrator profiles: grants the ability to create, edit, and reset passwords for all users; (4) Export Reports permission on profiles that should not be exporting bulk data; (5) API Enabled on user profiles for users who only use the UI. The last one is worth reviewing: API Enabled should be restricted to users and integrations that genuinely need API access, as it is the primary vector for automated data extraction.
What Salesforce integrations create the highest security risk?
Marketing automation platforms (HubSpot, Marketo, Pardot) with full Contact and Lead read/write access: these often use integration accounts with broad profiles and rarely have IP restrictions. Data warehouse integrations (Snowflake, BigQuery, Fivetran) that bulk-extract data via the Salesforce Bulk API or Streaming API: these should have View-only CRUD with FLS restricted to the specific fields being synced. Custom built integrations using OAuth client credentials with System Administrator profiles: audit these, replace System Administrator with a least-privilege custom profile, and document the integration's required permission set. Zapier and similar no-code automation tools connected by individual users with their personal Salesforce credentials: these create long-lived tokens with the user's full permissions that persist after the user leaves.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.