Salesforce security works on a shared model: Salesforce secures the infrastructure and platform, and your team decides who can log in, how they prove who they are, and what each user can see and do. Good Salesforce security is therefore mostly routine admin work, strong authentication, least-privilege access and regular reviews, rather than a one-time project. This guide explains the model and gives a practical checklist.
This post was first published in 2021 as "Importance of Salesforce Security for Your Day-to-Day". It has been rewritten for 2026, including the MFA enforcement and other security changes Salesforce began rolling out in June 2026.
How does Salesforce security work?
Salesforce security works in four levels, organisation, object, field and record, and a user needs access at every level to see a value. Trailhead's Data Security module describes four levels of access, each controlled separately:
| Level | What it controls | Main tools |
|---|---|---|
| Organisation | Who can log in, from where and when | User list, MFA, password policies, login IP ranges, login hours |
| Object | Whether a user can create, read, edit or delete a type of record | Permission sets, permission set groups, profiles |
| Field | Which fields a user can see or edit on records they can access | Field-level security in permission sets |
| Record | Which individual records a user can see | Org-wide defaults, role hierarchy, sharing rules, manual sharing |
At the record level, org-wide defaults set the baseline access users have to each other's records. Trailhead's advice is to start restrictive and then open access selectively: the role hierarchy lets managers see their team's records, sharing rules add automatic exceptions for groups, and manual sharing lets an owner share a single record. Sharing rules only ever add access, and developers can share records from code with Apex managed sharing when the rules can't express the logic. For object and field access, Salesforce recommends permission sets and permission set groups.
The levels combine. To see a contact's phone number, a user must be able to log in (organisation), read contacts (object), see the phone field (field) and have access to that particular contact (record). Our guides to profiles and sharing rules go deeper on the last three.
Authentication: MFA and the 2026 enforcement
As of November 2026, MFA is enforced for every Salesforce login, and admins and other privileged users need phishing-resistant methods. Salesforce has required multi-factor authentication for access to its products since 1 February 2022, according to its MFA page. Supported verification methods include the Salesforce Authenticator app, third-party authenticator apps that generate one-time codes, security keys that support WebAuthn or U2F, and built-in authenticators such as Windows Hello, Touch ID or Face ID.
In 2026 Salesforce moved from requiring MFA to enforcing it. Its security blog post of 12 May 2026, Strengthening Salesforce Security Against AI-Driven Threats, sets out these changes:
- MFA for every login. Beginning June 2026, MFA is enforced for all user logins, direct UI and SSO, in production and sandbox orgs.
- Phishing-resistant MFA for privileged users. Users with the System Administrator profile or permissions such as Modify All Data, View All Data, Customize Application or Author Apex must use phishing-resistant methods, which the post defines as methods cryptographically bound to a specific site, such as security keys.
- Step-up verification for reports. Report actions such as exports get a time-based step-up challenge after a configurable window of 2 to 120 minutes, 120 by default.
- Verified email domains. Email from Salesforce fails to send unless the sending domain is verified, through an active DKIM key or an entry on the authorised email domain list.
- Risky connections blocked. Connections from anonymising VPNs, proxies and high-risk IP addresses are blocked.
If your users still sign in with a password alone, or your admins rely on text-message codes, plan the change now. If you use SSO, make sure your identity provider enforces MFA.
Control where and when people log in
Use trusted IP ranges, profile login IP ranges, login hours and password policies to limit where, when and how users sign in. Trailhead's unit on org-level access explains three controls that are often confused:
- Trusted IP ranges (Setup, Network Access): logins from these ranges skip identity verification; logins from elsewhere are allowed but must verify.
- Login IP ranges on a profile: logins from outside the range are blocked outright.
- Login hours on a profile: users can log in only during the hours you set.
Password policies set minimum length, complexity, expiry and lockout after failed attempts, and a profile's password policy overrides the org-wide one for its users.
Run Health Check regularly
Run Health Check at least monthly: it scores your settings against Salesforce's baseline and shows what to fix. Health Check is a Setup page that compares your security settings with Salesforce's recommended baseline and scores your org from 0 to 100. Trailhead's Health Check unit explains how to use it:
- In Setup, search for Health Check in Quick Find.
- Review the risks, comparing Your Value with the Standard Value for each setting.
- Fix settings one at a time with each row's Edit link. The Fix Risks button changes every flagged setting at once, which can break integrations or remove access, so test in a sandbox first.
- Regulated industries can import a custom baseline from an XML file, agreed with their compliance team.
The May 2026 security post adds that, since Spring '26, Health Check notifies admins when the org's security score changes. Organisations with many orgs can use Security Center, a separate add-on that extends Health Check across orgs and also shows MFA adoption and admin-level users.
When do you need Salesforce Shield?
You need Shield when you must encrypt data at rest, monitor or block risky activity, or keep field history for years. Salesforce Shield is a paid add-on bundle, and its parts can be bought separately:
| Component | What it does | Typical reason to buy |
|---|---|---|
| Platform Encryption | Encrypts data at rest, including fields, files and search indexes, with bring-your-own-key options | Regulatory or contractual encryption requirements |
| Event Monitoring | Tracks user and AI agent activity such as logins, exports and API calls, and can block risky actions | Detecting data exfiltration, feeding a SIEM |
| Field Audit Trail | Keeps field history for up to 10 years (18 months on the standard platform), on up to 200 fields per object | Long audit retention |
| Data Detect | Scans the org for sensitive data such as card numbers or national ID numbers | Knowing where sensitive data lives before you protect it |
For Shield customers, the May 2026 security post also describes a default transaction security policy that requires step-up authentication for report exports of more than 10,000 records from the user interface. Shield doesn't replace the basics. An org with weak sharing and no MFA is not made safe by encryption.
A day-to-day Salesforce security checklist
Day-to-day security is a rhythm: remove leavers daily, check audit trails weekly, run Health Check monthly and review integrations quarterly.
| How often | Task |
|---|---|
| Every day | Deactivate leavers the day they leave; freeze the user first if you can't deactivate them straight away (freezing blocks login but doesn't free the licence) |
| Every day | Grant new access with permission sets for the job, not by cloning an admin |
| Every week | Check the Setup Audit Trail for unexpected configuration changes, and export it regularly if you need long history |
| Every month | Run Health Check and work through new risks |
| Every month | Review users with Modify All Data, View All Data or System Administrator |
| Every quarter | Review connected apps and integration users: remove unused ones, narrow scopes |
| Every quarter | Review sharing rules and public groups that were added "temporarily" |
| Every release | Read the security items in the release notes and test them in a sandbox |
| Every quarter | Test that you can restore data and metadata from your backups, not just that backups run |
Common Salesforce security mistakes
Most of these mistakes come down to access that is broader than the job needs.
- Too many administrators. Every System Administrator is a high-value target and, since June 2026, needs phishing-resistant MFA.
- Public Read/Write org-wide defaults "to make things easier". Start private and open up with sharing rules.
- Shared integration logins. Give each integration its own user with only the permissions it needs.
- Real customer data in every sandbox. Partial Copy and Full sandboxes hold production data, so restrict who can access them and mask sensitive fields.
- Bulk exports nobody notices. Report exports are a common exfiltration route; the new step-up checks help, and Event Monitoring shows who exported what.
- No tested backup. A bad data load or a compromised account can delete or overwrite records; plan backups and practise restores, especially before a data migration.
- Custom code that ignores permissions. Apex and integrations can see more than users can; have custom code reviewed so it respects sharing and field access.
Getting help
Techila is a Salesforce Summit Partner. Our managed services team runs regular security reviews, Health Check remediation and access audits for Salesforce orgs. Talk to us if you want a second pair of eyes on your org's security, or help preparing for the 2026 MFA changes.
Frequently asked questions
Is Salesforce secure?
Salesforce secures the infrastructure and platform, and gives you the controls to secure your org. Most incidents come from the customer side of that line: weak authentication, users with too much access, or connected apps and integrations nobody reviews. Configure and review those controls and Salesforce is a very secure place for data.
Is MFA required for Salesforce?
Yes. Salesforce has required MFA for access to its products since 1 February 2022. Its May 2026 security update says that, from June 2026, MFA is enforced for all user logins, both direct and SSO, in production and sandbox orgs, with phishing-resistant methods required for administrators and other highly privileged users.
What are the levels of security in Salesforce?
Four levels: the organisation (who can log in, from where and when), objects (which types of record a user can create, read, edit or delete), fields (which fields they can see or edit), and records (which individual records they can access, through org-wide defaults, the role hierarchy, sharing rules and manual sharing).
What is Salesforce Health Check?
Health Check is a Setup page that compares your security settings with Salesforce's recommended baseline and gives a score from 0 to 100. You can fix each risk individually or all at once with Fix Risks, though Trailhead recommends changing settings one at a time and testing in a sandbox first.
What is Salesforce Shield?
Shield is a paid add-on bundle of four products: Platform Encryption for data at rest, Event Monitoring for user and agent activity, Field Audit Trail for long-term field history, and Data Detect for finding sensitive data. The components can also be bought separately.