Last technically reviewed: July 2026

The Salesforce security model is the layered set of controls that determines who can log in to your org and what they can see and change once inside. It operates at four levels: organization, object, field, and record. Each level answers a different question, and they stack, so a user only reaches a piece of data when every layer allows it.

That layering matters because Salesforce environments hold the data that drives revenue: customer records, deal pipelines, and proprietary processes. A single configuration error or compromised credential can expose that data, disrupt workflows, and trigger costly regulatory investigations. Most breaches happen not through platform vulnerabilities but through misconfiguration of these four layers.

This guide explains each level, the Salesforce tools that control it, and the practical mistakes that create exposure, followed by a best-practices list and an audit checklist you can work through against your own org.

Salesforce Security and the Shared Responsibility Model

Salesforce operates on a shared responsibility model that divides security duties between the platform and you.

Salesforce handles security of the cloud: physically secured data centers, network segmentation between tenants, intrusion detection, encrypted communications, simultaneous patching of all production instances when vulnerabilities emerge, and disk-level encryption at rest. These controls are independently audited through SOC 2 Type II, ISO 27001, and FedRAMP authorizations, which reduces the compliance burden for enterprise customers.

This infrastructure layer is the foundation the rest of the model sits on, but it is not one of the four levels you configure. Salesforce owns it, and no amount of platform hardening prevents data exposure through a misconfigured permission set or an over-scoped integration.

What remains yours is security in the cloud: user provisioning, permissions, sharing, custom code, integrations, and ongoing monitoring. Missteps here, like an over-permissive profile, an unmanaged API token, or insecure Apex, are the gaps attackers exploit most often. For DevOps teams, this means security has to be embedded throughout the deployment pipeline, from static analysis before Apex is pushed through to automated compliance checks and secure backup strategies that protect both metadata and records.

Salesforce Security Model: 4 Layers

Before configuring anything, it helps to see all four levels side by side. Each one answers a distinct question, uses a distinct set of Salesforce tools, and fails in a distinct way.

The Four Layers of the Salesforce Security Model

Access is evaluated from the outside in. Organization-level settings decide whether a user gets through the door at all. Object-level permissions decide which kinds of records they can work with. Field-level security decides which pieces of each record they can see. Record-level sharing decides which specific records they can reach.

One scenario runs through all four sections below. A sales rep at a company where Finance tracks commission data on the Opportunity object needs to work their own deals. They should not see other reps' pipelines, and nobody outside Finance should see commission rates. Watch how each layer contributes a different part of that outcome.

Layer 1: Organization-Level Security

Organization-level security answers: who can log in, from where, and when. It is the perimeter, and it applies before any data permission is evaluated.

The main controls are:

• Multi-factor authentication, now a baseline requirement rather than an optional hardening step.
• Password policies, setting complexity, expiration, reuse, and lockout thresholds.
• Login hours and login IP ranges, set per profile, restricting when and from where users can authenticate.
• Trusted IP ranges, configured under Setup, then Network Access, which let known networks skip identity verification challenges.
• Session settings, controlling session timeout, session security level, and whether sessions lock to the originating IP.
• User provisioning and deactivation, including prompt offboarding, which is the control most often skipped.

Salesforce supports several authentication methods at this layer: username and password paired with MFA, single sign-on through SAML or OpenID Connect, OAuth 2.0 for connected apps and API access, JWT bearer flow for server-to-server integrations with no interactive login, and certificate-based authentication. Consolidating users under SSO reduces password fatigue and brings credentials under corporate policy, which usually improves both security and experience at once.

In our scenario, this layer is what requires the sales rep to complete MFA, restricts their login to business hours, and blocks authentication attempts from outside the corporate IP range. None of it says anything yet about which data they see.

Layer 2: Object-Level Security

Object-level security answers: which types of records can this user work with at all? It governs whether a user can read, create, edit, or delete records of a given object, along with the broader View All and Modify All permissions.

Two mechanisms grant these permissions. Profiles are mandatory and each user has exactly one, so a profile sets the baseline. Permission sets are additive and a user can hold many, which makes them the right place for anything role-specific or temporary. Permission set groups bundle several permission sets into a single assignable unit that maps to a job function.

Current Salesforce guidance is to assign the Minimum Access - Salesforce profile as the baseline and grant everything else through permission sets and permission set groups. This is a meaningful change from older practice, which built elaborate profiles per role. The permission set approach is easier to audit, easier to revoke, and avoids the profile sprawl that makes access reviews painful.

Object permissions are configured under Setup, then Permission Sets, then Object Settings, or under the profile for baseline access.

In our scenario, the rep receives Read, Create, and Edit on Opportunity but not Delete, and no access at all to the object where Finance stores commission calculations. They can work deals; they cannot remove them or open Finance's records.

Layer 3: Field-Level Security

Field-level security answers: which fields within a record can this user see or edit? It operates independently of object permissions, so a user can have full Edit access to Opportunity while specific fields on that object stay hidden or read-only.

Field permissions are set per field, per profile or permission set, with two settings: read access and edit access. Configure them under Setup, then Object Manager, then the object, then Fields & Relationships, then the field, then Set Field-Level Security. You can also set them from the field permissions section of a permission set.

One clarification matters more than any other at this layer: removing a field from a page layout is not a security control. A field hidden only by page layout is still reachable through reports, list views, search, the API, and export. Only field-level security actually prevents access. Teams that rely on layouts to hide sensitive data are usually surprised by what a report builder or a Data Loader export reveals.

In our scenario, the Commission Rate field on Opportunity is hidden from the sales rep's permission set and visible to Finance. The rep can open their own opportunity records in full and still never see that value, anywhere.

Layer 4: Record-Level Security

Record-level security answers: which specific records of an object can this user reach? This is where most real-world access design happens, and it is the layer with the most moving parts.

The controls stack in a specific order:

• Organization-wide defaults (OWD) set the baseline for each object: Private, Public Read Only, Public Read/Write, or Controlled by Parent. Set these restrictively, then open access deliberately.
• Role hierarchy grants users visibility into records owned by people below them in the hierarchy, when Grant Access Using Hierarchies is enabled for the object.
• Sharing rules open records to roles, public groups, or territories, based either on the record owner or on record criteria.
• Manual sharing grants access to one specific record for one specific user or group, for exceptions that don't warrant a rule.
• Teams and territory management provide structured collaboration on accounts, opportunities, and cases without loosening the underlying OWD.
• Apex managed sharing handles programmatic cases that declarative sharing can't express.

The key property to internalize is that sharing is additive. Every mechanism above can only grant access beyond the OWD baseline; none of them can restrict access below it. That is why a permissive OWD is so difficult to walk back later, and why starting Private is the safer default.

Sharing settings live under Setup, then Sharing Settings.

In our scenario, the Opportunity OWD is Private, so the rep sees only the deals they own. The role hierarchy gives their manager and the VP visibility into the team's pipeline automatically. A criteria-based sharing rule opens a specific segment of deals to a partner team without changing anything else.

Encryption and Advanced Protection

Shield Platform Encryption adds another protection layer for regulated fields, encrypting data at rest with customer-controlled keys through Bring Your Own Key. It requires a separate Shield license, and it changes how some queries, filters, and deployments behave, so it is worth testing against your automation before enabling it broadly.

Least privilege is the principle that ties the four layers together. Start every user at minimum access and grant only what the role genuinely requires, using permission sets rather than broad profiles. Treat Modify All Data and View All Data as exceptional, not convenient. Review entitlements on a schedule and after every role change, because permissions accumulate quietly and rarely get removed on their own.

Development Security

Every line of custom code and every integration point represents a potential security vulnerability. This layer covers the custom development that extends Salesforce, from Apex classes and Lightning Web Components to external integrations and API connections. The recurring challenge is that developers often prioritize functionality over security under deadline pressure, creating gaps that bypass even carefully configured platform controls.

Custom Development Security

Apex needs explicit security enforcement. The single most common misunderstanding is what the sharing keywords actually do.

with sharing enforces record-level sharing rules for the running user. It does not enforce object (CRUD) or field-level permissions. A class declared with sharing will still happily read a field the user has no access to. Enforcing object and field permissions requires doing so explicitly, which is what Salesforce now recommends through user-mode database operations.

The WITH USER_MODE clause on a SOQL query enforces object permissions, field-level security, and sharing rules together:

public with sharing class OpportunityService {
    public List<Opportunity> getOpenDeals(String stage) {
        // WITH USER_MODE enforces object and field permissions,
        // in addition to the sharing enforced by "with sharing"
        return [
            SELECT Id, Name, Amount, StageName
            FROM Opportunity
            WHERE StageName = :stage
            WITH USER_MODE
        ];
    }
}

Where you want the operation to degrade gracefully rather than throw on an access violation, use Security.stripInaccessible() instead. It removes fields the user can't access from the result, or from records before a DML operation, and lets you inspect what was stripped:

SObjectAccessDecision decision = Security.stripInaccessible(
    AccessType.READABLE,
    opportunities
);

List<Opportunity> safeRecords = decision.getRecords();
System.debug(decision.getRemovedFields());

Use WITH USER_MODE when an access violation should stop the operation, and stripInaccessible() when you would rather return the safe subset. Salesforce's Apex Security and Sharing Model guide and its Secure Apex Classes guide cover the full set of options. Don't rely on defaults; enforce explicitly.

Beyond the sharing model, validate all inputs, use bind variables rather than string concatenation in queries to prevent SOQL injection, and run peer reviews alongside automated security scans in your CI/CD tools so insecure patterns are caught before they reach production.

Integration Security

Integrations are where credentials and data cross trust boundaries, and they are a favored target precisely because they tend to be over-permissioned and under-reviewed.

• Request only the OAuth scopes the integration actually needs. A connected app that needs to read Opportunities should not hold full access to the org.
• Use a dedicated integration user, never a named employee's account. Give it a minimum access profile plus a narrowly scoped permission set, and mark it API-only so it cannot log in interactively.
• Store secrets properly. Keep client secrets and private keys in named credentials or an encrypted vault, never in code, custom settings, or a shared document.
• Prefer short-lived tokens and the JWT bearer flow for server-to-server connections. Define explicit token expiration and rotation policies rather than issuing long-lived credentials that nobody revisits.
• Apply IP restrictions and API rate limits on connected apps to constrain where calls originate and to blunt bulk-extraction attempts.
• Review connected apps on a schedule, auditing their scopes and revoking anything no longer in active use.
• Monitor event logs for anomalous call patterns, since a compromised integration usually shows up as a change in volume or origin before it shows up anywhere else.

Securing Salesforce DevOps and Deployment Access

Service accounts used by CI/CD pipelines deserve the same scrutiny as any integration, and often get less. Create a dedicated deployment identity with API-only access and no interactive login privileges, so exposed pipeline credentials cannot become an interactive session into production. Keep sandbox and production permission boundaries separate, letting developers test freely without inheriting production-level access.

Separation of duties matters here too: the person who builds a change should not be the person who approves its deployment to production.

A practical starting configuration for a deployment profile:

• API Enabled: yes
• Interactive login: no
• Deploy change sets: yes
• Modify All Data: no
• View Setup and Configuration: read-only

Then authenticate the pipeline using the JWT bearer flow rather than storing a password:

sf org login jwt \
  --username cicd@company.com \
  --jwt-key-file server.key \
  --client-id <connected_app_consumer_key> \
  --instance-url https://login.salesforce.com

Governance and Monitoring

Governance and monitoring is what keeps the other layers from decaying. Even well-configured controls degrade through normal operations: users request extra access for a project and keep it, developers push emergency fixes that bypass review, and integrations accumulate permissions over time. Security incidents rarely announce themselves clearly. They surface as subtle anomalies in login patterns, unusual API usage, or unexpected configuration changes that only look obvious in hindsight.

Continuous Monitoring

Event Monitoring captures logins, API calls, and data exports, while Setup Audit Trail records configuration changes and Login History shows authentication patterns. Run Security Health Check periodically to quantify configuration risk against Salesforce's baseline and surface quick improvements.

A practical starting query against Login History looks for the same user authenticating from different locations in a short window:

SELECT UserId, LoginTime, SourceIp, LoginGeoId, Status
FROM LoginHistory
WHERE LoginTime = LAST_N_DAYS:1
ORDER BY UserId, LoginTime

Review the results for a single user appearing from geographically distant locations within a span that rules out travel, and alert on it. Login History is available without a Shield license, which makes this a reasonable baseline check for any org.

Change Management

Every release should move through approval workflows that separate who builds from who deploys. Track metadata modifications with version control and reconcile them against Setup Audit Trail to surface undocumented changes. When emergency fixes are unavoidable, document the rationale and schedule a retrospective review.

Incident Response

Draft escalation playbooks that define detection thresholds, communication channels, and decision ownership. Include rapid log preservation, impact analysis across environments, and tested rollback plans that restore both data and metadata. Include Salesforce Support in the contact matrix and rehearse the full cycle regularly, because an untested playbook tends to fail at exactly the wrong moment.

Compliance and Risk Management

Salesforce's platform certifications (SOC 2, ISO 27001, FedRAMP) provide the foundation, but specific regulatory requirements demand additional controls on your side:

• SOX: Field Audit Trail and granular permission reviews support traceable change control.
• GDPR: individual objects, automated deletion flows, and field-level security enable data minimization and consent tracking.
• HIPAA and PCI-DSS: Shield encryption, strict access controls, and verifiable audit logs meet healthcare and payment requirements.
• Data residency: Shield Platform Encryption with Bring Your Own Key helps keep regulated data within approved jurisdictions.

Comprehensive documentation drives successful audits. Setup Audit Trail, event logs, and Field Audit Trail create durable records. DevOps pipelines that automatically export these artifacts and archive backups give auditors a single source of truth instead of a scavenger hunt.

Salesforce Security Model Best Practices

These practices apply across all four layers and address the failure modes that show up most often in real orgs:

• Start every user at minimum access and grant up through permission sets and permission set groups rather than building bespoke profiles.
• Set organization-wide defaults restrictively and open access deliberately, remembering that sharing can only add access, never remove it.
• Use field-level security, not page layouts, to hide sensitive fields, because layouts don't restrict reports, search, or the API.
• Require MFA for everyone and constrain login IP ranges, login hours, and session timeouts to match how your teams actually work.
• Give every integration its own API-only user with narrowly scoped OAuth permissions and rotating short-lived credentials.
• Enforce object and field permissions explicitly in Apex with user-mode operations rather than assuming a sharing keyword covers it.
• Review access after every role change and deactivate departing users promptly, since stale entitlements are the most common finding in access audits.
• Run Security Health Check and review Setup Audit Trail on a schedule, not only when preparing for an audit.

Maintain tested backups of both data and metadata, so a misconfiguration or deletion is recoverable. Automated backups remove the dependency on someone remembering to run an export.

Security Audit Checklist

Work through this checklist against your own org. It covers the areas where configuration drift accumulates fastest.

Keep Your Security Model Enforced as Your Org Changes

Configuring the four layers correctly is the starting point. Keeping them correct is the harder problem, because every deployment, permission request, and integration change is an opportunity for the model to drift away from what you designed.

That is where deployment governance matters. Version-controlled, policy-gated deployments make permission and sharing changes reviewable before they reach production, immutable audit trails show who changed what and when, and reliable metadata backups make a bad change reversible. Flosum's DevOps platform runs natively inside Salesforce, so metadata never leaves your security boundary while you gain that control. Request a demo to see how deployment governance keeps a well-designed security model intact over time.

Frequently Asked Questions