Read about our update schedules here.

A secure system protects an organization’s stakeholders and data. Secure architectures verify user identities, restrict data access to only necessary information, and prevent data compromise.

Salesforce prioritizes customer trust and data security. The Salesforce Platform ensures privacy and security. Real-time system performance and security information is available at Salesforce Trust.

Protecting your org and customer data is the foundation of building secure Salesforce solutions. As a Salesforce architect, you are responsible for securing your org and customer data by utilizing Salesforce's built-in security features. Consider geographic distribution, industry, company operating procedures, and customer data types when making these decisions.

You can make your solutions more secure by focusing on three areas: organizational security, session security, and data security.

Organizational security safeguards systems from unauthorized access by ensuring only validated, authorized users can access a system, and only necessary features and data.

Signs that you have problematic organizational security include:

• Ad hoc processes to activate or deactivate users
• Unclear steps to update authorization for user or system role changes
• Reliance on the institutional knowledge of individuals for correct user security assignments
• Failure to align with established security frameworks or industry best practices
• Absence of a structured data governance framework and supporting policies

You can build better organizational security controls for your Salesforce orgs by focusing on authentication and authorization.

Authentication is crucial for security and access management, verifying the identity of users attempting to access your system. This applies to both human users (employees, customers) and automated users (external systems, integrations), with each user type requiring specific authentication schemes. To ensure secure access across all Salesforce entry points in your org, you'll need to set up various authentication methods.

To create secure authentication flows in Salesforce:

• Create Salesforce users based on individuals, not personas. Salesforce’s built-in auditing capabilities are most effective when each user account corresponds to a single individual accessing the platform. The use of shared user accounts compromises the effectiveness of these audits, introduces additional security vulnerabilities, escalates the potential impact of account breaches, and complicates your ability to create effective authorization schemes. This includes user accounts for integration users.
• Secure UI-based access scenarios. Most human users require some kind of UI-based access (often called login access) for a Salesforce org. Salesforce provides several layers of protection for these login scenarios, including:
  • Password policies. Cybercriminals often target usernames and passwords to gain unauthorized access to applications. While configuring password policies is a fundamental step in protecting login access, it’s important to note that this alone isn’t enough, as Salesforce allows for per-user overrides of these policies.
  • Multi-factor authentication (MFA). Salesforce requires MFA for all UI-based user logins. MFA provides an essential defense against credential leaks and brute-force attacks by requiring users to provide an additional form of identification, or factor, after successfully entering their username and password. This additional factor typically takes a physical form, such as a mobile device, security key, or biometric marker.
  • Single-sign on (SSO). In SSO scenarios, users only use one set of credentials across an organization's applications. Access to systems is provisioned and managed from a central location, which improves security. Salesforce can act as a service provider or an identity provider in SSO scenarios. Be sure to allow some or all admins to log in directly to Salesforce so they can address outages or issues with your SSO implementation.
  • Post-login steps. For some use cases, you might require users to complete additional steps before accessing your system. Custom login flows can be implemented to guide users through these extra process steps. Examples include:
    • Accepting terms and conditions
    • Working through login discovery and passwordless login scenarios
    • Limiting the number of simultaneous Salesforce sessions per user to reduce the likelihood of session-based attacks (see session security).
    • Connecting to geofencing services
• Secure API-based access scenarios. Any user can request API-based access for a Salesforce org. Salesforce provides several layers of protection for API-based scenarios, including:
  • API Access Control. Without API access control, anyone with a valid set of credentials can leverage any app to connect with your org — even if the connected app is not deployed in the org. Data access controls will still be enforced, but users could access information in uncontrolled ways. For example, an app could be used to download large volumes of data, or even upload corrupted information, without a system administrator’s approval.
  • API Only permissions. You can configure API Only user permissions in Salesforce. Assign this as part of a permission set to any automated or integration user personas to block UI-based access entirely.
  • Certificates and keys. Certificates and keys enable Salesforce to validate that requests originate from authorized businesses or companies. You will need to configure certificates and keys if you want to use SSO with Salesforce.
  • Connected apps. Configuring connected apps in Salesforce enables you to control external system access to Salesforce, including required authentication protocols, authorization scope, and session behavior in a single definition.
  • Named credentials. Named credentials enable you to control external access points and authentication protocols in a single definition within Salesforce. Use them to securely define and manage authentication for callouts from Apex, external services, and Salesforce Connect data sources.
• Agentforce Agent Users Authentication. Agentforce agents, built on Salesforce, use agent-user objects with manageable permissions just like those of real users. When setting up an agent, carefully align access with the role the agent plays, limiting data access to only what’s required to serve the end users. Just as important, agents can be configured with both public and private actions. For private actions, validate and authenticate end users, mapping them to agent context. This allows the Agent to impersonate and operate within the end user’s access controls, maintaining security and trust.

The list of patterns and anti-patterns below shows what proper (and poor) authentication architecture looks like in a Salesforce org. Use these to validate your designs before you build, or identify opportunities for further improvements.

To learn more about authentication tools available from Salesforce, see Tools Relevant to Secure.

Authorization defines what features, functionality, and data a user can access, as well as the actions they can perform with those resources, after they’ve been authenticated. Authorization controls are not just for human users, they also need to be tailored for Agentforce Agent Users, especially Agents providing services to unauthenticated end users.

While restricting who can authenticate into your org is a crucial first step, it’s equally vital to pair strong authentication with robust authorization. Without adequate authorization controls, users could potentially create, edit, and delete records or access system functionality in ways that are harmful to your business and your stakeholders. Inadequate authorization control can also make systems harder to use. By controlling what users can do within the system, you foster higher levels of trust, safeguarding both your system and your users.

To build secure authorization schemes for Salesforce:

• Follow the principle of least privilege. Embrace the principle of least privilege (PoLP) by assigning users only the necessary permissions for their tasks. To follow this principle, design granular and modular permission sets. This allows for sophisticated access controls through permission set groups, enabling precise management of permissions, including the ability to mute, set expiration dates, and more. Align your systems functional units with business capabilities to define granular permissions and effective permission set groups. Remember that permissions apply to metadata access in Salesforce. For details about configuring PoLP for Salesforce data access, see Sharing and Visibility.
• Think about user access in terms of personas, not individuals. Thinking of authorization (or security in general) in terms of individual users will not set your system up to scale and evolve. Instead, design for and manage personas that represent groups of users. Secure Salesforce solutions use individuals for authentication, and personas for authorization. By defining security configurations for distinct personas, you gain granular control over access and privileges in your security model, which minimizes the need for refactoring in the long run. Include the security personas you define in your design standards and documentation.
• Control user access to metadata using permission sets and permission set groups. Permission sets and permission set groups govern what metadata users can access and what they can do with that metadata. To learn more about Salesforce metadata, see Metadata versus Data. Configure app assignments, feature license activations, managed package access, system permissions, CRUD access, and field-level access via permission sets and permission set groups. Include this access in your design standards and documentation.
• Use organization-wide defaults (OWDs) and sharing to control data access for users. Data and metadata are distinct entities in Salesforce, requiring separate access controls for each. Use OWDs and built-in sharing tools to configure access for Salesforce data (individual records, files, and docs). For more details, see Data Security.
• Use OAuth scopes to control access for connected apps. When configuring a connected app, you define the scope, or access permissions that app users will have to Salesforce resources. For more about managing OAuth tokens, see Session Management.
• Create one Salesforce user for every integration. To adhere to the principle of least privilege, create a unique Salesforce integration user for each integration. This allows you to assign specific data access, improving control over operations, ensuring transaction traceability, and minimizing the impact of potential security breaches.
• Implement unique accounts with the PoLP for all Agent users. Each Agentforce Agent User should be unique and not reused across multiple Agents. Permissions for these accounts must strictly adhere to the principle of least privilege. Keep in mind that Actions executed by an Agent User may operate in an elevated security context within Salesforce or against external systems that do not respect Salesforce access controls. This could lead to Actions accessing or revealing sensitive information to users.
• Minimize the use of profiles and migrate any access controls out of profiles. Profiles provide the ability to limit access to login IP ranges, login hours, and features specific to the legacy Salesforce Classic user interface (specifically default record types and page layout assignments). Any other functionality currently in profiles should be migrated to equivalent functionality in permission sets and permission set groups. Functionality in your profiles tied to Salesforce Classic UI features should be targeted for remediation.

The list of patterns and anti-patterns below shows what proper (and poor) authorization practices looks like in a Salesforce org. Use these to validate your designs before you build, or identify opportunities for further improvements.

To learn more about authorization tools available from Salesforce, see Tools Relevant to Secure.

This table shows a selection of patterns to look for (or build) in your org and anti-patterns to avoid or target for remediation.

✨ Discover more patterns for organizational security in the Pattern & Anti-Pattern Explorer.

A session is the series of requests and responses associated with a user over a period of time. A session is initiated when a user successfully authenticates into Salesforce. Session security is the practice of configuring your system to prevent unauthorized access and data breaches by thwarting session interference or hijacking.

All user activity in your system occurs within the context of a session, so it’s critical to account for how sessions are initiated, what can take place during a session, what devices users will (and should) employ, and how to detect and respond to suspicious or anomalous session behaviors.

You can build session security in Salesforce by focusing on three keys: session management, device access, and threat detection and response.

Sessions are initiated when a user successfully authenticates and gains access to Salesforce. These sessions enable the platform to associate specific requests and responses with that particular user.

HTTPS protocol facilitates communication between a front-end client and the Salesforce Platform. Clients can include browsers, mobile applications, local applications, and so on. HTTPS is a stateless protocol, which means that every communication is discrete and unrelated to any previous or future communications.

This stateless approach accelerates network communications and eliminates errors caused by broken links between packets. However, web apps still need a way to keep track of each user’s identity and other related information across multiple request and response interactions. Salesforce, like most web applications, accomplishes this using sessions and tokens.

• Sessions enable Salesforce to associate requests and responses with users. After a user is authenticated, the platform sends a session ID back to the client app, which includes this ID with any user requests (such as navigating, searching, and submitting data).
• Tokens enable users and connected applications to verify their identity once and use a unique access token from then on. Tokens have a limited lifespan and only provide access to specific resources (see Authorization for more about configuring access levels). Tokens allow access to authorized resources without requiring users to login.

If sessions and tokens aren't secured properly, bad actors can potentially interfere with them and impersonate users or execute malicious code in your system.

To build secure session management for Salesforce:

• Understand how Salesforce classifies session types. Identify and map approved session types to security user personas, and record these in your documentation.
• Control how sessions can originate and where session traffic can go. Once you've identified the kinds of sessions various user personas are allowed to initiate, configure controls to block sessions that originate from unapproved sources or contexts. Salesforce provides several ways to control session origins and traffic, including:
  • Built-in session protection. Salesforce automatically enables org-wide protections for session-based malicious activity, including cross-site scripting, cross-site request forgery, content sniffing, clickjacking and more. These protections should never be disabled; some cannot be disabled.
  • Domains and IP ranges. All Salesforce orgs have My Domain enabled by default, which creates a company-specific subdomain for Salesforce access. You can customize or change the name associated with an org through My Domain. Further, Salesforce supports additional domain configurations for Experience Cloud sites and other application pages. Note: If your users need to access Salesforce from behind a company firewall, add the required domains to your firewall allowlists. You can set up login IP ranges and trusted IP ranges to control inbound login and session requests to Salesforce.
  • Login hours. If certain user personas have set working hours, you can restrict their ability to access Salesforce outside of defined login hours.
• Control activities that require added session-level security. By default, sessions can have two kinds of security levels: standard and high-assurance. Use these security levels to control how users can and cannot carry out activities such as accessing reports and dashboards, or managing the security configurations in a Salesforce org. Session-level security policies can require users to establish high-assurance sessions to carry out operations or block users from carrying out any sensitive operations at all.
• Control activities that require added session-based permissions. Salesforce supports session-based permission activations to temporarily allow users elevated authorization or access to permissions during a particular session. You can activate and deactivate session-based permissions via Flow or Salesforce APIs.
• Manage inactive user sessions through timeouts. Ending inactive sessions is a key part of managing session security. This helps protect your system when, for example, a user leaves a Salesforce session open in a browser tab but is actively working in another application, or when a user’s mobile device is logged into Salesforce, but is unattended. Salesforce has a default session inactivity timeout of two hours. You can increase or decrease session inactivity timeout levels, but increasing timeouts should only be done with a compelling and well-documented justification.
• Manage connected app sessions through token configuration. When you configure a connected app, you also define the scope, or level of authorization, that will be granted to users accessing Salesforce through the connected app. This scope is enforced at the session level through OAuth tokens, which are issued after a user of a connected app successfully authenticates. You can control how long a token should last through token refresh policies. Org administrators can manually revoke tokens on a per-user and per-org basis, if needed.

The list of patterns and anti-patterns below shows what proper (and poor) session management looks like in a Salesforce org. Use these to validate your designs before you build, or identify opportunities for further improvements.

To learn more about session management tools available from Salesforce, see Tools Relevant to Secure.

In the current context, a device is any piece of electronic equipment that an individual will use to access Salesforce, such as a desktop workstation, laptop, tablet, or mobile phone.

Portable devices offer users the flexibility to access Salesforce from any location. However, this convenience potentially introduces additional attack vectors for malicious actors. These threat vectors range from simple tactics, such as shoulder surfing in a public place to steal credentials, to more sophisticated methods like installing malware on a device or creating a phony public Wi-Fi network to intercept data transmissions. Because of this, securing devices — especially portable devices — is essential to overall system security.

To secure device access for Salesforce:

• Use the mobile app solutions provided by Salesforce. Have users on mobile devices who need to access Salesforce use the official Salesforce apps available for iOS and Android. If business needs require a custom mobile solution, you should use the Salesforce Mobile SDK, which provides methods for secure authentication and authorization.
• Design mobile device usage into your session management. Session security levels, session timeouts, and other session context controls should take into account any anticipated access from users on mobile devices. Consider what devices should and should not be allowed to access Salesforce, and what kinds of users should have access to mobile sessions. Include mobile access standards in your security persona documentation. For more on this topic, see Session Management.
• Supplement device-level security with Mobile Device Management (MDM) technology. The Salesforce apps for iOS and Android are compatible with many popular MDM suites. You can configure additional access controls for the Salesforce app on user devices through your preferred MDM solution.
• Supplement app-level security with Mobile Application Management (MAM) technology. MAM technology supports app-level controls on mobile devices. Salesforce offers a paid MAM add-on for Salesforce mobile apps.

The list of patterns and anti-patterns below shows what proper (and poor) device management looks like in a Salesforce org. Use these to validate your designs before you build, or identify opportunities for further improvements.

To learn more about device management tools available from Salesforce, see Tools Relevant to Secure.

Threat detection is the process of identifying behavior patterns in your system that may indicate malicious activity. This can include larger than average volumes of data being downloaded or a user modifying fields containing sensitive data on several records within a shorter than average period of time. Responses to threats can include automated session expiration, alerting, and other notifications.

The goal of threat detection is to identify and respond to potential issues as quickly as possible. Taking action based on real-time threat detection can stop malicious behavior in its tracks. Salesforce offers real-time event monitoring as an add-on or as part of Salesforce Shield. Use one of these solutions if you have highly sensitive applications or require robust real-time threat detection and response capabilities.

To build an effective threat detection and response strategy for your Salesforce solutions:

• Use built-in audit capabilities. Salesforce offers a variety of built-in tools to help track and audit changes to your org. For example, the Setup Audit Trail allows you to view the audit history of administrative actions. Salesforce tracks field-level changes for a limited period of time by default, but you can activate Field History Tracking to display field changes for up to 18 months in the UI and up to 24 months via the API. Additionally, you can activate Field Audit Trail to retain an audit history for field-level changes indefinitely (until you manually delete the data).
• Establish regular audit reviews. Auditing is crucial for identifying anomalous changes that real-time threat detection might miss. Consider a scenario where a user with legitimate access consistently deletes a small number of records daily over an extended period. Since this user has valid login credentials, proper authorization to delete records, and isn’t deleting a large volume of records at once, the activity is unlikely to be detected as a real-time threat. However, an audit team reviewing user activity reports would clearly identify this trend of excessive record deletion by a single user over time, making it easier to address. As part of your governance policies, establish regular intervals for auditing login history, user session activity, and connected app usage.
• Develop a threat response strategy and include it in your security policies. Create a threat response strategy that covers:
  • Threat response type definitions (for example, alerts and automations) and any stakeholder groups that should be involved. For more on designing messages or alerts, see Errors and Notifications.
  • Specific categories for real-time changes or activities that could be considered threats and the associated response type for each
  • A clear list of all automated threat responses (such as revoking tokens, ending sessions, deactivating user accounts, or blocking access to resources) and automation triggers

Event Monitoring provides the data necessary to enforce this principle by enabling real-time threat detection and response. Transaction Security applies your company’s policy-driven actions, and event types support the monitoring of user and application access over time.

Salesforce's native Threat Detection service uses statistical and machine learning models to identify suspicious behavior. This service generates specific events that guard against cyber attacks and suspicious data access.

Transaction Security takes security a step further since it provides a framework that intercepts key events happening in your org and applies your company’s policy-driven actions. This transforms Event Monitoring from a logging tool into an important component of an automated security defense.

The list of patterns and anti-patterns below shows what proper (and poor) threat detection and response looks like in a Salesforce org. Use these to validate your designs before you build, or identify opportunities for further improvements.

To learn more about threat detection, alerting, and response automation tools available from Salesforce, see Tools Relevant to Secure.

This table shows a selection of patterns to look for (or build) in your org and anti-patterns to avoid or target for remediation.

✨ Discover more patterns for session security in the Pattern & Anti-Pattern Explorer.

Data security is the practice of protecting your data from unauthorized access, corruption, or unintended deletion. Data security involves safeguarding data both in transit and at rest.

Strong data security minimizes the risks and potential damages from unauthorized access to your system. Inadequate data security leaves systems vulnerable to data breaches, which can severely impact customers and your company. Therefore, safeguarding your data is fundamental to building secure architectures.

Improving data security starts with a clear understanding of what is considered data within Salesforce, along with its classification. The individual records, files, and documents stored within a Salesforce org are its data. For more on the distinction between metadata and data, see Salesforce Architecture Basics.

You can build stronger data security in your Salesforce solutions by focusing on sharing and visibility as well as the use of encryption.

Note: When designing for data security, be sure to take into account data privacy as well as archiving and purging, as both of these concepts will affect the overall data security of your solutions.

Identify and classify all data stored within the Salesforce platform based on its sensitivity (e.g., public, internal, confidential, restricted). Define a clear data classification policy that outlines how each data type should be handled and protected. Implement appropriate security controls, such as field-level security, encryption, and data masking, to enforce the policy and protect sensitive data from unauthorized access or exposure. Review and audit these classifications and controls regularly to ensure they remain aligned with business and compliance requirements.

Sharing and visibility involves configuring your system to control how users access data within Salesforce. It is important to note that sharing and visibility control which individual records a user can access, but these settings alone do not ultimately control what a user can do with a particular record, or which specific fields within that record are visible. Permissions to carry out data operations (like CRUD) are assigned to users through metadata access controls, which can be configured for a user at the individual object and field level. For more on this, see Authorization.

Agentforce actions can expose data to both authenticated and anonymous users who typically lack direct access. When building Agentforce Agents, carefully consider and document all Actions assigned to the Agent. For each Action, you must understand:

• What data the Actions can access.
• What security context the Actions run in.
• Whether the Actions have knowledge retrieval or other capabilities that can incorporate sensitive or restricted data into the Agent session.

To configure effective sharing and visibility in Salesforce:

• Design access around meaningful job functions. Create a security matrix that maps your user personas to business functions they are to perform. Use this template as a foundation to design your sharing and visibility. For more on identifying meaningful business functions, see Functional Units.
• Choose the simplest path to applying the principle of least privilege. As you apply the principle of least privilege in designing sharing and visibility schemes, do so in the most straightforward way. Avoid over-engineered data restrictions and sharing schemes, which can cause downstream issues for system maintainability, scalability, and adaptability. Instead, take advantage of the flexible, layered data sharing in Salesforce, to configure fine-grained rules for user access at the data level.
• Set internal organization-wide defaults (OWDs) to Public Read Only, unless your business deals with sensitive data — then use Private. OWDs control the level of "least" privilege users will have at the data level. You cannot restrict access below the level of your OWD. While Private OWDs might seem ideal in every use case, users across the business can often end up inadvertently replicating a more permissive OWD through complex sharing schemes. Additionally, Private OWDs can cause users to create duplicate data. Sharing calculations (and re-calculations) may take a significant amount of time to complete depending on data volume and parent-child or ownership skew — Private OWDs exacerbate this. It’s important to note that OWDs do not control CRUD permissions and field-level visibility. Only choose an OWD of Private when it is justified by business needs — most often, such justifications will be related to compliance.
• Set external organization-wide defaults (OWDs) to Private, unless you have a compelling business reason to allow greater access. External OWDs apply to users accessing Salesforce data from Experience Cloud sites, portals, and so on. This allows you to configure separate OWD baselines for internal and external users, to allow for differing types of “least” privilege. Always set the OWD for external users to Private — exceptions for a more open level must be clearly justified by business needs.

The list of patterns and anti-patterns below shows what proper (and poor) sharing and visibility looks like in a Salesforce org. Use these to validate your designs before you build, or identify opportunities for further improvements.

To learn more about sharing and visibility tools from Salesforce, see Tools Relevant to Secure.

Encryption converts readable data into an indecipherable, encoded format. Encrypted data can be decrypted, or translated back to its original form, via a key. As a result, encryption is among the most effective methods for securing data both at rest and in transit, ensuring that even if unauthorized parties access the data, it will be unreadable.

To design for proper use of encryption in your Salesforce solutions:

• Always adequately encrypt data in transit. Salesforce employs Transport Layer Security (TLS) for all sessions that take place in a Salesforce-supported browser, and requires that outbound calls using HTTPS meet specific security standards. Platform APIs also employ HTTPS by default. Additionally, data sent between a Salesforce Experience Cloud site or a portal and its related Salesforce org is encrypted in transit by default. If you use Salesforce's built-in email services, there are default levels for the Transport Layer Security (TLS) Salesforce uses to send and attempt delivery of email. You should, at a minimum, ensure the org settings are not lower than the default settings, unless you have clear business justification. Based on the classification and sensitivity of your data, consider leveraging a private network connection to Salesforce via AWS Direct Connect or Salesforce Private Connect. This ensures that your data does not traverse the public internet, but instead flows securely over a private network connection for both user access and integrations.
• If the business requires it, encrypt data at rest. Salesforce offers different ways to encrypt data at rest.
  • Hyperforce. Data is encrypted at rest in orgs that use Hyperforce. Encryption is managed for your org by Salesforce. You cannot create (or destroy) your own encryption keys.
  • Salesforce Shield. Salesforce Shield enables you to encrypt data at rest in a Salesforce org at additional layers, including the application and database layers. With Shield, you have full management capabilities for your tenant’s encryption keys, including robust “Bring Your Own Key” (BYOK) options. You can also encrypt unstructured data (including files, attachments, search indexes, and events). Hyperforce-based instances offer the option to use an external key manager, allowing you to bring your own AWS KMS. With this capability, you maintain full control over the encryption keys within your KMS that are used to encrypt and decrypt the data stored in Salesforce—strengthening security and aligning with your organization’s compliance requirements.

The list of patterns and anti-patterns below shows what proper (and poor) use of encryption looks like in a Salesforce org. Use these to validate your designs before you build, or identify opportunities for further improvements.

To learn more about encryption tools available from Salesforce, see Tools Relevant to Secure.

This table shows a selection of patterns to look for (or build) in your org and anti-patterns to avoid or target for remediation.

✨ Discover more patterns for data security in the Pattern & Anti-Pattern Explorer.

Help us keep Salesforce Well-Architected relevant to you; take our survey to provide feedback on this content and tell us what you'd like to see next.