At Salesforce, Trust is our #1 value. It’s the foundation of every architectural decision on the platform. For architects, trust is achieved via a unique partnership: Salesforce provides a secure, compliant platform—the infrastructure, metadata, and tools to make it your own—while you design secure solutions that rely upon that foundation.

This partnership operates through the Shared Responsibility Model, which is a framework that clearly divides security responsibilities:

• Salesforce is responsible for security of the platform, including infrastructure, patching, and compliance certifications.
• You are responsible for security on the platform, including configuration, access controls, custom code, and data governance.

This division is essential because it defines architectural accountability. Salesforce operates a multi-tenant architecture where thousands of organizations share infrastructure. The platform provides strong security protections at the infrastructure level. Your architectural decisions determine whether your specific solutions earn stakeholder confidence.

The Shared Responsibility Model puts you in charge of designing secure solutions while physical security, network protection, platform patching, and infrastructure encryption are handled for you. This lets you focus on designing secure solutions that are built upon that foundation (for example, identity and access management, data protection, integration security, secure development practices, compliance and regulatory adherence, and incident response capabilities).

Neglecting trust during design compounds technical debt. A missing encryption strategy becomes a costly retrofit when regulations change. An ungoverned integration becomes a vulnerability when credentials are compromised. Building trust in from the beginning is consistently less expensive than retrofitting it later.

Trust spans four architectural dimensions that work together cohesively:

• Security controls protect systems and data
• Identity management governs access
• Privacy practices respect user agency
• Compliance frameworks satisfy regulatory obligations

Architects who design for all four dimensions create solutions that earn and sustain trust through transparency, control, and resilience.

In the Agentic Era, trust extends to the trusted context that agents operate within. Trusted context means that agents access governed, verified data with clear identity and permission boundaries, which enables AI systems to reason and act on behalf of users while also maintaining security, auditability, and compliance. Designing trusted context is foundational to Agentic Enterprise architecture.

This pillar establishes the platform security baseline that every Salesforce solution depends on. The Agentic Trust pillar builds upon that baseline to address risks that are unique to autonomous agents, including prompt injection, action governance, and the data that agents can access during reasoning times. It’s important to design the baseline first, then layer agent-specific controls using the Agentic Trust guidelines.

This pillar connects deeply with other framework concerns.

• Reliability depends on infrastructure that resists attacks and recovers from breaches.
• Operational Excellence requires secure deployment pipelines and incident response capabilities.
• Fairness demands the transparent, ethical handling of data and algorithmic decisions.

Together, these pillars form a unified, solution-focused approach that organizations can trust with their most sensitive operations.

In the Shared Responsibility Model, Salesforce and architects must fulfill their respective responsibilities to maintain trust. Let’s take a closer look at what each side must secure.

Salesforce is accountable for securing the platform and its global infrastructure, including:

• Data center access controls, surveillance, and environmental safeguards
• For Hyperforce, the underlying cloud provider (for example, AWS, Azure, or Google Cloud, depending on the instance) handles physical data center security via delegated responsibility. The Salesforce Infrastructure and Sub-processors documentation identifies the provider and sub-processors for each service.

• Network-layer security controls, including DDoS protection and threat detection
• Traffic encryption in transit (TLS 1.2+) and at rest (typically AES-256)

• Vulnerability response and platform patch deployment via Salesforce (for more information on security advisories, visit security.salesforce.com)
• Operating system and infrastructure security management

• Certifications and attestations: Salesforce maintains SOC 1/2/3, ISO 27001/27017/27018, FedRAMP authorization (scoped to Government Cloud Plus and MuleSoft Government Cloud, not the commercial multi-tenant platform) and PCI DSS Level 1 validation.
• Regulatory support: This applies to HIPAA-eligible services with Business Associate Agreements (BAAs) or GDPR compliance programs.
• For more information, visit trust.salesforce.com and compliance.salesforce.com.

• Tenant isolation architecture: A shared, metadata-driven kernel partitions every org's data and metadata by organization ID, so one org can’t reach another org's records even though they’re both running on shared infrastructure. The kernel enforces separation on every query, not through a configuration that you must maintain.
• Infrastructure-level encryption at rest and backup infrastructure: Base platform licenses include Classic Encryption (AES-128 provides custom text fields only). Shield Platform Encryption requires a separate license (AES-256 allows you to bring your own key and provides standard and custom fields, files, and attachments).

These controls ensure that the platform remains secure, reliable, and compliant.

You're responsible for securing your data, configurations, and operational processes.

• Identity and federation: For single sign-on (SSO) and multi-factor authentication (MFA), you must verify the identity of the user.
• Access restriction: Technically, IP ranges and login hours constrain how and when identities connect.
• Principle of Least Privilege (PoLP): Use the PoLP to only grant access for roles, profiles, and permission sets that are necessary to perform individual job duties.
• Lifecycle management: Practice user lifecycle management and access recertification guidelines.

• Use data classification, masking, and object/field/record-level security.
• Enforce CRUD permissions and sharing rules.
• Own, test, and deploy a proven strategy to restore your org's data, ensuring that data loss or corruption recovery stays within your control.

• Use API authentication (for example, OAuth 2.0 or JWT) and named credentials.
• Enable dedicated integration users with PoLP permission sets so that each integration's access is scoped and separately auditable from human users.
• Secure endpoints and external system validation.

• Use Event Monitoring, audit trails, and Security Information and Event Management (SIEM) integration.
• Follow incident response procedures and security reviews.

• Use secure custom code (for example, Apex or Lightning) and input validation.
• Run Apex in user mode so object, field, and sharing permissions are enforced in code.
• Follow injection prevention and secure development practices.

• Maintain solutions compliance posture.
• Follow privacy/consent management and data retention policies.

Some responsibilities require collaboration:

• Security incident response: Both parties participate in detection and response activities.
• Vulnerability management: Salesforce patches the platform, architects patch custom code.
• Security monitoring: Combine platform-generated security signals with architect analysis.
• Compliance certifications: Salesforce certifies the platform (for example, SOC, ISO, and FedRAMP for Government Cloud); architects own what’s built upon it—custom objects, code, integrations, and configuration—within the certified posture to provide evidence of compliance for audits.
• Identity federation: Salesforce trusts the assertions that the architect identity provider issues; architects maintain securing the provider and the trust relationship between the provider and Salesforce.
• Key management: Using bring-your-own-key encryption, Salesforce operates the encryption service while architects generate, rotate, and revoke the key material that protects the data.

Every design principle, topic section, and checklist item in this document represents your responsibility as an architect. The Shared Responsibility Model frames what you must design and configure to achieve trust on the Salesforce platform.

The boundary extends to regulatory obligations. Salesforce maintains the platform's certifications and attestations and secures the infrastructure against breaches. Architects are responsible for the obligations that are attached to your data and jurisdiction (for example, which laws apply, how data is classified, what retention and consent rules govern it, and how you detect and report breaches of the data under your control). Architects must determine the specific figures behind those obligations (for example, retention periods and notification deadlines) from the governing regulations for their deployments, because they may vary by jurisdiction and change over time.

Use these principles to guide your architectural decisions for security on the platform.

• Apply zero trust across all layers. Never assume trust based on network location, user familiarity, or system origin. Verify every access request explicitly with authentication, authorization, and encryption at the data, application, integration, and infrastructure layers. Multi-tenant architecture means you share infrastructure with thousands of organizations, so the network that your solution runs on isn’t a perimeter you can treat as trusted. Verify each request on its own merits—identity, authorization, and context—rather than trusting it for where it originated.
• Grant least privilege by default. Grant the minimum level of access that’s necessary for each user, integration, and automated process to accomplish its purpose. Start with the most restrictive settings—Private organization-wide defaults (OWDs) and minimal permissions—and expand deliberately based on documented business requirements. Use the four-layer access model (organization → object → field → record) so that each layer further restricts the layers above.
• Implement defense in depth. Layer multiple security controls so that failure of one control doesn't compromise the entire system. Combine preventive controls (for example, CRUD/FLS enforcement and Transaction Security policies that block operations), detective controls (for example, Event Monitoring), and responsive controls (for example, Transaction Security step-up authentication and notification). Design each layer as if the adjacent layers might fail. Remember, Field-level security protects data even when sharing rules are too permissive.
• Integrate security by design. Integrate threat modeling, security requirements, and control validation into every architecture phase from the initial concept through ongoing evolution. Conduct Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege (STRIDE) threat modeling before build begins. Security shapes technology selection and design decisions.
• Embed security in automation. Build security controls into automated pipelines, configuration templates, and platform defaults. Salesforce Code Analyzer in CI/CD catches vulnerabilities before deployment. Configuration-as-code enforces security baselines. Embedded security ensures consistency and enables security to scale with solution complexity.
• Design for privacy. Incorporate privacy principles from the initial architecture phase. Design for data minimization (collect necessary data only), purpose limitation (restrict access by job function), consent management (enforce granular, purpose-specific consent), and data subject rights (enable access, rectification, erasure, and portability workflows to complete within regulatory timelines).
• Design for traceability. Make every consequential action attributable and reconstructable after the fact, before relying on detecting anomalies in it. Ensure that changes to data, permissions, and configuration are captured in audit trails, field history, and event logs, and preserve those records in tamper-resistant storage. Traceability is the precondition for detection, forensics, and accountability. Remember—you cannot investigate what was never recorded.
• Design for incident response. Design for detectability through Event Monitoring, and for real-time intervention through Transaction Security policies. Enable rapid response through documented procedures and isolation boundaries. Support recovery through backup capabilities and forensic preservation. Test responses through tabletop exercises and breach simulations.

Architects are responsible for securing solutions on the platform that Salesforce provides.

The workloads that interact with Salesforce increasingly run outside the core platform—integration services, custom applications, and headless clients frequently call Salesforce APIs, frequently on behalf of a user. To accelerate this pattern, Salesforce exposes the platform's capabilities as APIs, tools, and commands (for example, AIforce). No matter who operates these applications, the architect owns the trust boundary where they meet Salesforce to determine how they authenticate, what identity and permissions they carry, what secrets they hold, and what data crosses the boundary.

The principles below apply to any containerized integration platform (for example, MuleSoft CloudHub).

When an external client authenticates as a named user, the Salesforce platform security model applies automatically—object permissions, field-level security, and sharing rules are enforced exactly as they are in the browser. Per-user authentication scopes every call to that individual's permissions and preserves the audit trail, which means revoking a user's token immediately removes the client's ability to act on their behalf. Prefer this over a shared service account wherever the work is done for a specific user.

Design the boundary defensively, because a client that holds tokens for many users concentrates trust and becomes a high-value proxy for an attacker: one single stolen OAuth token can reach data across every user the client serves. This isn’t hypothetical. The 2025 Salesloft Drift incident saw attackers steal OAuth tokens and use them to reach Salesforce data across hundreds of organizations.

• Propagate user identity, don't pool it. Use per-user authentication, or OAuth 2.0 Token Exchange to carry a user's identity across service hops, so that compromises are scoped to one user's context rather than all of them.
• Treat OAuth client credentials and refresh tokens as the primary target. Store them in a managed secrets store, rotate them frequently, and maintain designs for immediate revocation. Monitor API usage for the anomalous patterns that signal a proxied attacker.
• Minimize the scope on both sides. Constrain the External Client App's (ECA) OAuth scopes and the integration user's Salesforce permissions to the minimum the function requires, so that a compromised client cannot pivot to unrelated data.
• Govern the boundary through External Client Apps. ECAs define how an external application authenticates, which flows are permitted, and what scopes apply. Design new integrations against them.

Exercise caution where a client runs as an Agent User or Integration User: those identities can operate in an elevated context—often against external systems that don't respect Salesforce's access controls—so using the permission and monitoring discipline outlined above is what keeps that power bound.

When integrations run in a containerized platform, container-level isolation is in itself considered a security control: each application runs in a dedicated container with no shared runtime or memory between applications.

This isolation provides:

• Tenant boundary enforcement: Compromised applications cannot access data or resources from neighboring applications sharing the same environment. Each container has an isolated filesystem and process space. Enforce network isolation through firewall and TLS configuration, and explicitly restrict outbound traffic rather than relying on permissive defaults.
• Defense-in-depth: Container isolation adds a security layer beyond application-level controls. Even if the application code has vulnerabilities, container boundaries limit the blast radius.
• Compliance segmentation: Regulated workloads (for example, PCI and HIPAA) can be isolated in dedicated containers, preventing co-mingling with non-compliant workloads.

Architects who are designing multi-application environments must rely on container isolation to enforce separation of duties and security domains. Financial services integrations handling cardholder data must run in separate containers from marketing integrations, even within the same environment.

Inter-container traffic should be encrypted, and mutual TLS (mTLS) should be applied where a regulatory framework requires authentication on both sides:

How it works:

• Configure TLS contexts to enable optional mutual TLS (mTLS) for inbound connections when required.
• Use Platform-level SSL with client-certificate authentication to secure communication between platform services and replicas.
• Configure TLS contexts to enable mTLS when required by regulatory frameworks.
• Manage certificates through the platform's certificate store so that lifecycle and revocation stay centralized.
• Enforce network isolation boundaries that prevent unauthorized traffic between containers.

Encrypting traffic at the platform layer provides defense-in-depth for data-in-transit. Even if the application-layer HTTPS is misconfigured, the container traffic remains encrypted.

Containers connecting to on-premises systems via VPN must architect for data-in-transit protection:

• Tunnel encryption: Route all traffic between containers and on-premises systems through encrypted VPN tunnels. This applies regardless of the application-layer TLS. Defense-in-depth ensures that there’s double encryption for sensitive data.
• Network segmentation enforcement: VPN tunnel policies restrict which on-premises networks containers can reach. Compromised containers can't pivot to unauthorized internal systems beyond VPN-allowed networks.
• Compliance evidence: VPN encryption is one of the accepted mechanisms for protecting data-in-transit to and from cloud environments. Auditors reviewing HIPAA, PCI-DSS, or SOX controls expect documented encryption in transit for hybrid integrations.

Architects must design VPN policies that enforce least-privilege network access. Marketing integration containers shouldn't route to internal financial systems even if both are reachable via VPN.

Vanity domains (for example, custom URLs for integration APIs) require architects to manage TLS certificates as trust anchors.

• Certificate lifecycle automation: Implement automated certificate renewal and deployment. Expired certificates break integration trust; clients reject connections with certificate validation errors.
• Certificate revocation planning: Design certificate rotation procedures for security incidents. Compromised private keys require rapid certificate reissuance and deployment across all regions.
• Cipher suite configuration: Older TLS configurations (TLS 1.0/1.1 and weak ciphers) fail compliance audits. Enforce TLS 1.2+ (minimum requirement), and align certificate and client configurations with organizational security policies.
• Certificate transparency logging: Modern TLS certificates are submitted to public Certificate Transparency (CT) logs by Certificate Authorities (CAs). Each CT log returns a Signed Certificate Timestamp (SCT), a cryptographic proof of logging, which the CA embeds in the certificate via an X.509v3 extension. Architects should monitor CT logs for unauthorized certificate issuance against their domains, using services such as crt.sh or automated alerting.

Certificate mismanagement directly impacts trust posture:

• Expired certificates: Cause authentication failures that appear as outages. Monitoring must include sending alerts within 30+ days before expiration to allow renewal workflows to commence.
• Self-signed certificates: Break trust chains for external clients. Production integrations require certificates that are signed by trusted Certificate Authorities (CAs).
• Wildcard certificate sprawl: Refers to overly broad wildcard certificates (for example, *.company.com) that create a large blast radius if they’re compromised. Narrow-scope certificates are preferred per integration domain.

Container deployment regions must align with data residency and compliance requirements.

• GDPR data residency: The GDPR requires adequate protection for personal data leaving the European Union (EU), but not EU deployment as such. Deploying integrations in an EU region keeps container compute and data processing within regulatory boundaries, which is the most direct way to satisfy this requirement. Transfers that occur outside of the EU remain permissible under an adequacy decision, Standard Contractual Clauses (SCCs), or Binding Corporate Rules (BCRs).
• Data localization laws: Countries with data localization requirements include: Russia (Federal Law 152-FZ and mandatory storage) and China (PIPL/CSL for CIIOs), which may require in-country container deployment. India's DPDP Act of 2023 uses a blacklist approach that doesn’t impose a general in-country storage mandate. Data transfers are permitted to any country unless specifically restricted by a government notification. Architects must understand jurisdiction-specific regulations.
• Cross-border data transfer mechanisms: When a multi-regional deployment is required, but the data must cross borders, architects must implement SCCs, BCRs, or other legal transfer mechanisms.
• Compliance certification alignment: Container deployment regions must match Salesforce compliance certifications. FedRAMP-authorized workloads require US-regional deployment. For HITRUST-certified integrations, you must verify that the deployment region falls within an active HITRUST attestation scope.

Regional deployment decisions are architect responsibilities that directly impact regulatory compliance. Finance teams may mandate US-only deployment for SOX-controlled integrations. Healthcare teams may require HITRUST-certified regions for processing personal health information (PHI).

Containers require access to credentials, API keys, and encryption keys. Architects must design secrets management processes that prevent exposure:

• No hardcoded secrets: Never embed credentials in application code or configuration files that are deployed to containers. Use platform-managed secrets stores.
• Platform-managed secret injection: Resolve secrets at runtime from the platform's managed store (rather than persisting them to the filesystem), and mark configuration values holding credentials as protected so that they aren't exposed in logs or on the console.
• Secrets rotation: Design integrations to handle rotated secrets gracefully. OAuth token refresh patterns, API key rotation workflows, and database password changes must not require container redeployment.
• Least-privilege secrets access: Grant containers access only to the secrets that are required for their function. Marketing integrations shouldn't access financial system credentials even when they share the same environment.

Exposed secrets are common integration security incidents. Architects must design secrets handling processes that can survive code reviews, logs, error messages, and monitoring dashboards without leaking credentials.

Applications at the Salesforce boundary generate audit events that satisfy compliance logging requirements:

• Request/response logging: Logs API requests, responses, and routing decisions. Compliance teams use these logs for access audits to determine who accessed what data at what time.
• Error and exception logging: Captures security events (for example, authentication failures, authorization denials, and invalid certificates) in the container's logs. SIEM integration enables real-time security monitoring.
• Log retention policies: Architects must configure retention periods that satisfy regulatory requirements. Those minimums are set by regulation, differ by framework, and change over time, so they must derive them from a well-maintained compliance source that verifies each figure against the governing regulation rather than hardcoding values.
• Log encryption and access controls: Audit logs may contain sensitive metadata. Logs must be encrypted at rest and access-controlled to authorized security/compliance personnel only. Insufficient logging prevents incident investigation and fails compliance audits. Architects must balance logging verbosity (for example, performance impact and storage costs) against compliance and security investigation needs.

Threat modeling must be part of designing your solutions, rather than a separate step that occurs before or after it. As soon as you have a candidate design to reason about, you need to model its potential threats—and revisit the model as the design evolves, so security shapes the architecture instead of being retrofitted down the line onto it. While Salesforce manages infrastructure security (for example, network protection, OS hardening, and vulnerability management), you must identify application-layer risks in your configuration, integrations, and custom code. Apply the STRIDE framework (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to the Salesforce-specific threat vectors listed below. Identify trust boundaries where data crosses systems, networks, or privilege levels.

Apply the STRIDE framework to these Salesforce-specific threat modeling considerations:

• Multi-org data flows create additional trust boundaries that require explicit authentication and authorization at each crossing.
• External integrations use APIs and middleware, potentially introducing attack vectors that bypass platform security controls.
• Custom Apex and Lightning components require secure coding analysis for injection, XSS, and access control enforcement.
• Experience Cloud sites expand the attack surface to unauthenticated or lightly authenticated users.
• Third-party and ISV code (for example, managed packages, AgentExchange listings, connected apps, third-party connectors, client-side JavaScript libraries, and the external AI services that your agents call) is a supply chain vector that crosses into your trust boundary, at install time or at runtime.

Third-Party and ISV Code Is Part of Your Trust Boundary

Managed packages or AgentExchange listings run inside your org with the permissions that you grant them, so their security posture becomes your security posture the moment you install them. Salesforce Security Review checks each listed package before it reaches AppExchange or AgentExchange; you own everything after that gate:

• Assessing the package against your own data classification and risk posture
• Granting it the least amount of privileges that its documented functionality requires
• Keeping it current with the publisher's releases
• And monitoring its activity through the same Event Monitoring and audit controls that you apply to your own code.

Apply security controls at every layer of the solution stack. Keep in mind that compromise of one layer must not expose the entire system.

Design each layer as if the layers above and below might fail. Remember, multiple independent controls create resilience.

Zero trust eliminates implicit trust based on network position or prior authentication state. Every request must be authenticated and authorized independently.

Apply zero trust to:

• User access through continuous verification with MFA, session policies, and conditional access based on context (for example, IP, device, time, and behavior)
• Integration connections through OAuth token validation on every call, certificate-based mutual TLS, and IP allowlisting
• Inter-system communication through explicit authentication, which also applies to trusted internal systems
• Data access through CRUD and FLS enforcement on every query and operation regardless of calling context

Security Asset Inventory is a security-design input: you can only threat-model, apply least privilege to, and monitor an attack surface that you have first enumerated, so tracking your security-relevant assets belongs with the design decisions that depend on it. This is distinct from the operational configuration management that Operational Excellence covers (for example, versioning org settings and detecting configuration drift for operational stability). In other words, the concern here is narrower: which assets carry security risks, and why?

Maintain a current inventory of all security-relevant assets, including custom objects storing sensitive data, external system integrations, public-facing APIs, privileged accounts, production access grants, and installed packages with elevated permissions.

Your security asset inventory should include:

• Custom objects and fields containing Confidential or Restricted data
• Integration endpoints and authentication mechanisms
• Users with elevated privileges (for example, Modify All Data, View All Data, and Manage Users)
• API-only integration users and their permission scopes
• External Client Apps (ECA) and their OAuth scopes, along with any legacy Connected Apps that are still present in the org
• Installed AgentExchange packages and their permission grants
• Experience Cloud sites and their authentication and external sharing models
• Custom Apex classes with elevated sharing modes
• Pay particular attention to legacy classes: code compiled at API version 66.0 or earlier, that omits a sharing declaration defaults to "without sharing" (for example, system mode, bypassing the running user's record access). Keep in mind that from API version 67.0 (Summer '26), an omitted declaration instead defaults to "with sharing," and database operations run in user mode. However, existing classes keep the old behavior until they’re recompiled at v67.0 (or later)—so undeclared classes carried forward from earlier versions remain silently elevated.

It’s your responsibility to design and configure identity controls that enforce least privilege.

Let’s take a closer look at how to properly design and configure controls using the PoLP.

Salesforce enforces access control through four distinct layers: organization, object, field, and record. You must design solutions that leverage all four layers deliberately. Core access control is grant-based, which means access is additive, and users need to have it granted at every layer to reach a record. There is no generalized "deny overrides allow" rule in the core platform, so you cannot bolt on a targeted denial to undo access to a broad grant that’s already conferred.

Permissive higher layers don’t cost your ability to restrict, but they increase effort: widening organization-wide defaults or object permissions early means relying on field-level security and sharing configuration to claw back access that should never have been granted.

Restriction rules and muting permissions are two built-in exceptions that subtract access, but each is narrowly scoped—restriction rules to record-level filtering and muting to permissions granted within a permission set group—not a generalized deny layer.

Set OWDs to Private for objects containing sensitive data. Opening OWDs to Public Read Only—let alone Public Read/Write—exposes records broadly and erodes your ability to restrict access later without potentially significant rearchitecture. The most common trust debt in mature orgs stems from permissive OWDs set during initial implementation.

The record layer follows a grant-then-restrict model, often pictured as a sharing pyramid: OWDs set the restrictive baseline, and role hierarchy, sharing rules, and manual sharing open access upward from there. Two controls invert that flow to take access away rather than grant it, and both are worth designing in deliberately.

• Restriction rules filter what users can see within records that they already have access to, so users with broad object access still see only the subset that a rule permits.
• Muting permissions subtract specific permissions inside a permission set group, so you can assemble access from reusable groups, and then remove what a given population shouldn’t have.
• Reach for these rules when grant-based layers alone would force you to either over-provision or fragment access into many narrow permission sets.

Enforce multi-factor authentication (MFA) for all users logging in to production environments through the user interface, which Salesforce mandates as a platform requirement. This requirement doesn’t extend to API-only access: integrations using JWT-bearer or client-credentials flows are exempt, so you need to protect those integrations with certificate management and IP restrictions instead. Extend MFA requirements to privileged operations.

For single sign-on (SSO), SAML 2.0 or OpenID Connect protocols are preferred. Configure session policies to balance security and usability:

• Session timeout: Configure session timeouts appropriate to user privilege levels (shorter timeouts for high-privilege accounts reduce risks from unattended sessions).
• IP restrictions: Enforce restrictions for administrative profiles and integration users.
• Login hours: Restrict service accounts to expected operational windows.
• Device activation: Rely on Salesforce native device activation (identity verification for logins from unrecognized devices), and add MFA and IP restrictions for high-privilege accounts. Native device trust posture is enforced through an external identity provider.
• Session IP locking: Lock sessions to the IP address from which they originated, so that a stolen session ID cannot be replayed from another network location. This tightens security, but adds friction for mobile users and can break automated integrations—where locking isn't viable, enforce Strict Login IP Ranges at the profile level with "Enforce login IP ranges on every request" as the compensating control.
• High-assurance sessions: Require a High Assurance session security level, through Session Security Level Policies and Access Policies, for sensitive operations (such as accessing reports or managing IP ranges), so that a routine login cannot by itself reach high-impact actions. In Lightning Experience, stepping a standard session up to High Assurance by re-prompting for MFA is unsupported, so scope this policy knowing standard-session users are blocked from the gated operation rather than prompted to elevate.
• Session cookie protection: Require the HttpOnly attribute so that scripts cannot read the session-ID cookie, and lock sessions to the domain in which they were first used, to blunt session-hijacking.
• API-only access for integration users: Restrict integration and service accounts to API-only authentication with the API Only User permission, so that they cannot log in through the user interface. For new builds, assign the Minimum Access - API Only Integrations profile with the Salesforce Integration user license; the older Salesforce API Only Systems Integration profile is unavailable in orgs provisioned from Spring '24 onward, so design new integrations against the current profile rather than the deprecated one.

For API authentication, select OAuth 2.0 flows appropriate to the integration pattern:

• JWT Bearer Flow: Use this for server-to-server integrations that run as an integration user (certificate-based, preferred for trusted environments).
• Web Server Flow (authorization code, with PKCE): Use this for web applications requiring user authorization, and for server-to-server integrations that need to maintain specific user context (storing refresh tokens on the server-side to avoid repeated browser prompts).
• Make Authorization-Code Flow Replay-Safe: Enforce PKCE so an intercepted authorization code cannot be redeemed by anyone but the client that requested it, and rotate refresh tokens—issuing a new one on each use and invalidating the prior one—so a stolen refresh token has a narrow validity window. Reuse of a retired token signals compromise.
• Headless Identity Authorization Code and Credentials Flow (with PKCE): Use this for genuinely headless, no-browser clients that must run in a specific user's context—the redirect-based web server flow assumes a browser these clients don't have.
• Device Flow (for headless devices): Note that as of August 28, 2025, Salesforce has permanently blocked OAuth 2.0 Device Flow for the default Salesforce CLI connected app. Use the Web Server Flow (sf org login web) or JWT Bearer Flow (sf org login jwt) instead for CLI and CI/CD tooling.

Do not use the Username-Password Flow. Salesforce blocked it by default for orgs created in Summer '23 or later, and has published retirement plans in place for this flow. Existing integrations that still rely on the Username-Password Flow should migrate to the JWT Bearer Flow or the Client Credentials Flow now, rather than treating migration as deferred technical debt.

These flows are configured on the app registration that represents your integration. As of Spring '26, Salesforce is moving that registration from Connected Apps to External Client Apps (ECA): creating new Connected Apps is disabled by default, and ECA is the construct to design new integrations against. Existing Connected Apps remain installed; however, once an org is migrated they no longer handle authentication, so account for the migration when auditing how integrations authenticate rather than treating Connected Apps as the permanent model.

In addition to choosing an authentication flow, create distinct governance for which apps may connect:

• One registration per integration: Register a dedicated External Client App for each new integration, and a distinct Connected App for each existing one. Scoped to only the OAuth scopes that each integration requires rather than sharing one broad registration across many, a dedicated registration keeps each integration's access independently auditable and revocable.
• Pre-authorize access explicitly (recommended): Set the External Client App's Permitted Users policy to "Admin approved users are pre-authorized," so an administrator grants access through profiles and permission sets instead of letting users self-authorize. Administrators configure this directly in Setup, and it is Salesforce's recommended control for determining who can connect.
• API Access Control (stricter, allowlist-based): For tighter controls, API Access Control limits admin-approved users to allowlisted connected apps only. Enabling it requires a request to Salesforce Customer Support, so plan for that step when designing around it rather than treating it as a self-service setting.

Never embed credentials in code, configuration files, or version control. Use named credentials and external credentials to manage authentication centrally with rotation capabilities.

Unlike traditional user authentication, agents require distinct identity models, and the right model depends on whether the agent serves employees or external users. Designing identity correctly is the foundation of agent security: it determines what data the agent can access and the actions the agent can reach.

Let’s take a closer look at internal and external agents.

• Employee agents (internal): Execute tasks within the context of the user logged in. They inherit that user's licenses, permission sets, field-level security, and sharing rules, so no separate agent identity is provisioned, and the existing security framework governs what the agent can do.
• Customer agents (external): Interact through public channels and run as dedicated Agent Users, specialized integration users—not public-site guest users. Running as dedicated integration users lets the agent perform backend actions and reach data (which unauthenticated guest profiles cannot), while still being bound by explicit, least-privilege permissions. When you create a customer agent, provision a new Agent User with minimal access and grant only the specific permissions its actions require.

Where an agent's work spans multiple services, propagate the user's identity across each service hop rather than falling back to a shared or guest identity. Salesforce OAuth 2.0 Token Exchange flow supports this.

A client presents the user's existing identity-provider token, and an Apex token exchange handler maps it to a Salesforce user and issues a Salesforce access token, so the original user's context follows the request instead of collapsing to a service account. Monitor agent activity through Event Monitoring, using the agent's user identity to detect anomalous behavior.

Choosing the right model depends on who initiates the connection and whose context the work must run in.

Common connection scenarios map to recommended approaches as follows:

Design role hierarchies around data-access needs (which users require access to records owned by others)—not the management reporting chart. Let role-hierarchy depth follow genuine data-access relationships rather than adding levels that grant no additional access, since each level adds sharing-calculation overhead—a consideration that carries more weight in orgs with Private OWD settings and large data volumes.

Permission sets and permission set groups reduce the need for profile proliferation by providing flexible, additive access. Grant functional access through permission sets and permission set groups rather than profiles, which keep access additive and auditable. Profiles still remain necessary: alongside login hours and IP restrictions, they control page layout assignment, record type defaults, and app visibility. Treat profiles as a durable part of the access model, rather than a construct to eliminate.

Transaction Security policies aren’t part of the baseline, they’re an add-on capability that complements the core authorization model: the identity, role, profile, permission-set, and sharing controls above already establish a secure authorization posture on their own, and Transaction Security adds real-time contextual evaluation on top. Configure policies to detect and block anomalous behavior, including bulk data downloads exceeding normal patterns, logins from unexpected geographies, and permission changes outside change windows.

Security controls carry availability trade-offs that are an architectural responsibility. An overly broad IP restriction can lock out legitimate users during a network change, and a Transaction Security policy tuned too aggressively can block valid business activity—so scope these controls to genuine risk, stage them in monitor-only mode before enforcing them, and design a break-glass path for when a control misfires.

Your Responsibility: Design role hierarchy, create permission sets, configure Transaction Security policies.

Traditional role-based access control grants permissions based on a user's role. ABAC (attribute-based access control) makes authorization decisions based on attributes of the data, the user, and the context.

For most requirements, the core sharing model expresses access fully. Reach for dedicated ABAC when access must follow data classification that per-record sharing cannot express: Data 360 ABAC provides this through tags and annotations.

Data 360 ABAC operates through:

• Tag-based policies that define access rules based on tags applied to data objects (for example, Personally Identifiable Information (PII), Financial, Healthcare, and Confidential tags).
• Annotations are applied to data objects to support policy-based authorization decisions.
• Default "Allow All" policy for new and existing orgs that must be explicitly deleted to enable granular governance policies.

Its primary architectural use is enforcing data classification—see Data Classification under Data Protection and Privacy for how classification tiers drive ABAC enforcement.

This level of granularity carries an operational cost. Core sharing answers the question, "Who can see this record, and why?" from a small, inspectable set of rules (OWDs, role hierarchy, and sharing rules), whereas ABAC derives its answers at evaluation time from the combination of data tags, user attributes, and context, so effective access grows harder to reason about and to audit as policies and tags accumulate.

Enforce auditability as a design requirement: apply tags consistently, keep the policy set small and named for the classification it enforces, and preserve the ability to reconstruct why a user reached a given record. Reserve ABAC for classification-driven cases that per-record sharing genuinely cannot express, rather than treating it as a general replacement for the ownership-based model.

Identify and protect accounts with elevated privileges, including system administrators, integration users, and automated process accounts. These accounts are high-value targets for attackers.

Apply enhanced controls to critical impact accounts.

• Require phishing-resistant MFA.
• Restrict login IP ranges to known administrative locations.
• Enable login alerts and permission change notifications.
• Conduct periodic access reviews with documented attestation for high-privilege accounts where the frequency is determined by organizational risk tolerance and compliance requirements.
• Maintain break-glass procedures for emergency access and post-use auditing.

For integration and service accounts:

• Apply OAuth flows; never username-password flows.
• Enforce IP restrictions.
• Implement credential rotation schedules.
• Monitor for anomalous API usage patterns through Event Monitoring.

Your Responsibility: Identify critical accounts, apply enhanced controls, conduct quarterly reviews.

Design automated processes to provision users with the appropriate initial access, adjust permissions as roles evolve, and deprovision promptly when access is no longer required.

Implement a System for Cross-domain Identity Management (SCIM) for automated provisioning from identity providers. SAML or OpenID Connect Just-in-Time provisioning is an alternative that creates a user upon first login, but it doesn’t deprovision users. In other words, SCIM is the backbone of the lifecycle, not a choice against it.

The identity lifecycle includes:

• Provisioning: Create accounts with baseline access that matches job function, which is triggered by HR system events.
• Access adjustments: Grant additional permissions as roles expand, and revoke permissions when roles change.
• Periodic recertification: Review and validate access quarterly.
• Deprovisioning: Revoke access immediately when employment ends or roles no longer require Salesforce access.

Implement access recertification processes when managers periodically review and validate their teams' permissions. Review frequency is based on risk and compliance requirements.

Your Responsibility: Implement SCIM, design provisioning workflows, conduct quarterly recertification.

Separating data into multiple orgs is sometimes viewed as purely a cost or residency decision. Architecturally speaking, it’s a security trade-off, and the governance consequences belong within your access design.

Isolation is the key benefit. Separate orgs provide the strongest possible boundary between data sets. There’s no collective sharing model and no cross-tenant permission bleed, but there is a clear regulatory line for jurisdictions that demand one. That same boundary fragments governance. Every access control that you only need to maintain once within a single org (for example, permission set design, role hierarchy, critical-impact-account hardening, Health Check baselines, Event Monitoring, and SIEM correlation) now multiplies per org, which means that it must maintain consistency across all of them. Drift between orgs creates its own attack surface because a permission that’s tightened in one org and missed in another creates an inconsistency that attackers can find and exploit. Cross-org integrations add authenticated trust boundaries that didn’t exist before. Each cross-org integration is a connection that you need to secure and monitor.

That’s why it’s important to weigh the isolation benefit against the governance multiplier before splitting an org. Reserve multi-org for cases where a hard localization mandate or a customer's contractual isolation requirement genuinely can’t be met within a single org. When you adopt it, you need to design the access model, monitoring, and configuration baselines to be enforced identically across every org from the beginning.

Your Responsibility: Treat a multi-org decision as a security trade-off, not only a cost one. Where multi-org is required, enforce access controls, monitoring, and Health Check baselines consistently across every org and secure each cross-org integration as a trust boundary.

It’s your responsibility to classify data, configure encryption, design privacy controls.

Let’s take a closer look at how to properly protect data and privacy.

To properly classify your data, you need to know your data. The overarching architectural task is to understand your business domain and maintain a data dictionary that catalogs what data you hold, what it means, and where sensitive data lives. You can only classify—or protect—data that you’ve identified first.

Establish a data classification scheme that drives appropriate protection controls. A classification label doesn’t protect anything on its own. It’s the input to the controls that you apply, so every classification that you assign must map to a concrete encryption, access, retention, or monitoring decision. Classification decisions that are made during data modeling directly influence encryption requirements, access controls, retention policies, and compliance obligations.

At Salesforce, we use a four-tier scheme that provides a framework that you can adapt to your organization's regulatory requirements and business needs. Many enterprises use similar models that are aligned to industry standards (for example, ISO 27001 and NIST). Your specific implementation should reflect your compliance obligations (for example, HIPAA, PCI DSS, GDPR, and industry regulations) and business context.

Apply classification at the field level. A single Account record may contain Public fields (for example, company names), Confidential fields (for example, company revenues), and Restricted fields (for example, social security numbers). Field-level security must reflect these distinctions.

Classification becomes enforceable through attribute-based access control, which reads the tags you assign and applies access rules. This is a metadata-driven layer that complements OWD and sharing rules.

Aligning ABAC to your classification scheme lets the platform:

• Restrict access to data that’s tagged Restricted or Confidential from the classification itself, rather than from a sharing rule that’s maintained per object.
• Adapt access as a record's classification changes over time. A record that’s newly tagged as Regulated inherits stricter access without a manual rule change.
• Combine data attributes (for example, classification and sensitivity) with user attributes (for example, department and clearance) and context (for example, time and location) in a single authorization decision.

Design ABAC policies to align with this scheme so that classifying a field as Restricted is the act that drives its access controls and keeps the enforcement anchored to the classification rather than maintaining sharing rules separately.

Your Responsibility: Define classification scheme, train data modelers, classify fields during design, configure controls, and align ABAC policies to the classification tiers so tags drive enforcement.

Start with the information that the platform already provides for every org. Data at rest is encrypted by default. Hyperforce applies volume-level encryption that protects an entire storage volume under a single key that Salesforce owns and manages. This baseline is always on and transparent to your solution, but it operates at the volume level (not per field), so choosing what to encrypt and control within the key lifecycle rests with the platform, not with you.

When that baseline can’t satisfy a compliance, contractual, or data-classification obligation, use Shield Platform Encryption. Specifically, when you need one of the three things that volume-level encryption doesn’t provide:

• Control of the key lifecycle so you can generate, rotate, and revoke the key material yourself
• Selectivity over which standard fields, custom fields, files, and attachments are encrypted at rest
• The ability to render data inaccessible to Salesforce.

Restricted data and data that’s under explicit regulatory key-control mandates (for example, HIPAA, PCI DSS, and GDPR) are the usual triggers. The baseline already covers infrastructure-level protection of everything else.

Shield Platform Encryption encrypts at the field level, and it offers two schemes that trade security for queryability.

Probabilistic encryption is a strong, default scheme, but the fields that are encrypted with it can't be used in filter criteria, sorting, or aggregate functions (for example, MAX(), MIN(), and COUNT_DISTINCT() functions).

Deterministic encryption enables exact-match filtering in reports, list views, and SOQL WHERE clauses—case-sensitive or case-insensitive—at reduced strength because the same plaintext always produces the same ciphertext.

We recommend encrypting with the probabilistic scheme by default, and reserving deterministic encryption for the specific fields that you must filter or sort. Evaluate these trade-offs during data modeling design, including impacts on formula-field references, report aggregation, and SOQL operations.

Customer-controlled keys come in two distinct forms:

• Bring Your Own Key (BYOK) allows you to generate key material outside of Salesforce—using your own crypto libraries, enterprise key management system, or hardware security module—and supply it to the platform.
• Cache-Only Key Service keeps your data encryption key in a key service that you control. Salesforce fetches it on demand rather than storing it.

Both forms let you rotate and destroy key material on your own schedule. Destroying key material renders the data that it protected unrecoverable, which is a powerful, deliberate control instead of a routine. It’s also important to document your key rotation and revocation procedures.

All integrations must use TLS 1.2 or higher (the Salesforce platform enforces this), but you need to implement certificate-based mutual authentication for integrations that handle Restricted data (using your own configuration).

Your Responsibility: Decide where the platform's volume-level baseline suffices and where a compliance, contractual, or classification obligation warrants Shield Platform Encryption, then select encryption schemes, choose and operate a customer-controlled key strategy, and implement certificate-based auth for sensitive integrations.

Protect sensitive data in non-production environments using strategies that prevent Restricted data from entering sandboxes.

• Partial sandbox copying excludes Restricted data from sandbox refreshes.
• Data Masking rules confuse sensitive field values in sandboxes by using patterns that preserve data characteristics.
• Synthetic data generation applies to development environments that never require production data.
• Sandbox templates define which objects and fields to include in each sandbox type.

Designing for compliance testing is an architectural responsibility. Build development and test cycles on synthetic data with realistic characteristics, so that teams can validate against production-like conditions while regulated data stays within its production boundary.

Your Responsibility: Design sandbox strategy, configure Data Mask rules, generate synthetic test data.

Design solutions that respect user privacy via architectural decisions.

• Data minimization: Collect data that’s necessary for stated business purposes only. Challenge every field addition by asking, "What architectural decision requires this data?" Remember, the most secure data is the data that you never collect.
• Purpose limitation: Design data access patterns that enforce purpose limitation technically. Use permission sets and sharing rules to restrict access to data based on a job function’s purpose. For example, marketing users shouldn't access support case details unless their job requires it.
• Consent management: Implement consent tracking at the individual level for marketing, analytics, and optional data processing. Design consent withdrawal workflows that propagate across integrated systems. In other words, consent is granular and purpose specific.
• Data subject rights: Build workflows for access requests (for example, providing data copies), rectification (for example, correcting inaccuracies), erasure (for example, deleting data when it’s legally permissible to do so), and portability (for example, exporting to a machine-readable format). Design these workflows to complete within the response deadline that each governing framework imposes. These deadlines vary by jurisdiction—and they’re amended periodically—so it’s important to parameterize the workflow's SLA from a maintained compliance source and confirm each window against the governing regulation (instead of hardcoding a single value).

Your Responsibility: Design data models with minimization, configure access by purpose, implement consent workflows, build data subject rights automation.

Data residency is an architectural decision choice that you make before provisioning, not a setting that you toggle afterward. Hyperforce offers regional deployment—but a region only exists where Salesforce operates one—and an org's residency is fixed at provisioning. Your responsibility is to establish where each data category must reside, confirm whether a suitable region is available, and design the data-transfer mechanisms that legitimately cross borders.

Instead of defaulting to in-country storage, it’s important to classify your residency obligations before you begin.

• Mandatory localization. A small set of jurisdictions require certain data to stay within national borders (sometimes, this only applies to regulated sectors). When Salesforce doesn’t operate in an in-country region, native storage can’t satisfy the mandate on its own, so you need a data-residency overlay or a separate org for that data. Since this list may shift, it’s important to confirm the specific mandate against the governing regulation.
• Accountability-based frameworks. Most regimes don’t impose a localization mandate. They’re satisfied by a regional hub with an appropriate cross-border transfer mechanism. In these instances, the decision is based on which region minimizes latency and simplifies compliance.

When data crosses a border, the point is awareness before configuration. In other words, you need to know which transfers occur and on what legal basis, and then design access so that the data is governed end to end. Where they exist, adequacy decisions carry the least friction. Binding Corporate Rules (BCRs) and Standard Contractual Clauses (SCCs) cover most remaining transfers. Use explicit consent only as a last resort.

Pair the transfer mechanism with restrictive record access (for example, private OWDs and purpose-scoped sharing) so that a permissible transfer doesn't become overly broad. Document data flow maps to show where each data category originates, transits, and resides. Revisit them when regulations or regional availabilities change.

Your Responsibility: Classify residency obligations per data category, confirm regional availability before provisioning, select transfer mechanisms (adequacy, BCRs/SCCs) for cross-border flows, and document data flow maps.

Note: Multi-org isolation is one way to satisfy localization mandates, but it multiplies operational complexity and increases cost. Before committing to multi-org isolation, it’s important to exhaust single-org options (regional deployments and transfer mechanisms). For more information, check out the multi-org security trade-off note under Identity and Access Management.

It’s your responsibility to design solutions that maintain the compliance posture that the platform provides.

This guidance is directional. Regulatory requirements vary by jurisdiction and change over time. You must always verify specific obligations against the governing regulation (for example, the applicable statute, supervisory authority, or Salesforce compliance documentation) for your deployment.

Salesforce maintains extensive compliance certifications (available at trust.salesforce.com and compliance.salesforce.com): SOC 2 Type II, ISO 27001, FedRAMP (for Government Cloud offerings), HIPAA, PCI DSS, and regional certifications. These certifications cover Salesforce responsibilities for platform infrastructure and shared services.

Platform certifications reduce your compliance burden, but they don't eliminate your architectural responsibility. Your custom objects, Apex code, integrations, and configurations must maintain the compliance posture that the platform provides.

Your Responsibility: Design solutions that maintain compliance posture, document how architecture satisfies regulatory requirements.

• Enable Shield Platform Encryption for all fields that contain protected health information (PHI).
• For HIPAA compliance, enable the Field Audit Trail with retention policies to meet HIPAA's record-keeping requirement. Confirm the current period against the governing regulation.
• Configure Event Monitoring to detect unauthorized PHI access patterns.
• Implement all technical safeguards that are required by the HIPAA Security Rule, including access controls, audit logging, and transmission security.

• Implement segregation of duties (SoD) via permission set designs to prevent single users from creating and approving financial transactions.
• For PCI environments, avoid storing complete primary account numbers (PAN) in Salesforce to minimize the PCI DSS compliance scope.
• When possible, use payment gateway tokenization.

• For GDPR and LGPD, design consent management that captures granular, purpose-specific opt-in consent.
• CCPA/CPRA follows an opt-out model. Provide clear mechanisms to opt out of the sale or sharing of personal information rather than granular purpose-based consent.
• Build data subject rights workflows that complete within each framework's response deadline and are confirmed against the governing regulation.
• Implement data retention automation that purges data when consent expires.

• Use the Salesforce Government Cloud for regulated government workloads.
• Implement NIST 800-53 controls that are mapped to Salesforce configuration.
• Enable continuous monitoring via Event Monitoring that’s routed to government SIEM infrastructure.

Your Responsibility: Configure Shield, Field Audit Trail, segregation of duties, consent management, data retention based on regulatory requirements.

Data-protection and privacy regulations vary significantly across jurisdictions—and specific obligations change quickly—so this level requires decision making rather than a country-by-country table.

The two architectural levers are residency and cross-border transfer, which are covered under Data Protection and Privacy.

To adhere to these regulations, you must:

• Classify where each data category must reside.
• Confirm that a suitable region exists before provisioning.
• Design a legal transfer mechanism for data that crosses a border.

For more information, check out Data Residency and Sovereignty for the decision framework.

Everything outside of this is considered to be a point-in-time figure (for example, which consent model a jurisdiction uses, the deadline for a data-subject request, the window for notifying regulators or affected individuals after a breach, and the minimum retention period for audit records). These figures are set by regulations, they differ per framework, and they’re amended on the regulators' schedules.

Don’t hardcode them here. You need to determine next steps based on the governing regulation for your deployment—or a maintained compliance source that cites one—and size your design to the tightest window in your operating footprint.

Here are the durable architectural consequences that belong in the design.

• A data-subject-request deadline that’s measured in single-digit days can’t be met by an ad-hoc manual process, so you need to automate DSR fulfillment when you operate in any short-deadline jurisdiction. Use Experience Cloud for intake, Service Cloud for case tracking, Privacy Center for discovery, and Flow for fulfillment.
• A breach-notification window is too tight to improvise, so you need to build the breach-response workflow in advance. Determine Event Monitoring anomaly rules, pre-assigned roles, pre-drafted regulator and data-subject notifications, and an escalation path that assumes the tightest deadline within your footprint. Individual notifications are generally triggered by a high-risk determination, so you need to include a risk assessment in the workflow.
• Some jurisdictions require or recommend the in-country retention of audit logs—with minimums spanning several years—so you need to size SIEM retention to the longest minimum within your footprint and confirm whether logs may leave the jurisdiction.

Your Responsibility: Design residency and transfer per Data Protection and Privacy, automate DSR and breach-response workflows to the tightest deadline in your footprint, and confirm every jurisdiction-specific figure against the governing regulation rather than a value written into this guide.

Design for continuous compliance validation rather than point-in-time audit preparation.

• Security Health Check assesses configuration against Salesforce security baselines and provides risk scores. Run checks regularly to monitor compliance with Salesforce security baseline recommendations. Maintain scores of 80% or higher (Very Good or Excellent bands).
• Event Monitoring captures detailed logs for user activity, API calls, authentication events, and data access patterns. Route Event Log Files to external SIEM for long-term retention that exceeds native retention limits.
• Transaction Security evaluates events against policies in real-time, and it can block events, require an increase in MFA, or notify you of policy violations.

It’s important to automate compliance checks in deployment pipelines to validate that deployments don't weaken permission models, disable audit settings, or introduce non-compliant configurations.

Your Responsibility: Run Health Check quarterly, route Event Monitoring to SIEM, configure Transaction Security policies, automate compliance validation in CI/CD.

Design audit trail strategies that are based on compliance requirements, investigation needs, and retention obligations.

For regulated environments, implement Event Monitoring with external SIEM integration for long-term log retention and cross-system correlation. Design Field Audit Trail policies that cover all Restricted and Confidential fields that are subject to regulatory record-keeping requirements.

Your Responsibility: Enable Field Audit Trail for sensitive fields, route Event Monitoring to SIEM, configure Transaction Security policies.

It’s your responsibility to integrate security throughout development, not as an afterthought.

Integrate security practices at the earliest possible development phase. Threat modeling during the architecture phase prevents design-level vulnerabilities. Security requirements captured alongside functional requirements prevent you from treating security like an afterthought.

Security defects cost substantially more to remediate when they’re discovered in production rather than during the design or development phases. A design-level security flaw that’s caught during architecture review may only take one conversation to fix. However, when the same flaw is found in production it requires rearchitecture, data migration, compliance remediation, and potential breach notification.

That’s why we practice shift-left security, which focuses on:

• Threat modeling before design finalization
• Security requirements in user stories
• Secure coding training for developers
• Static analysis that’s integrated into IDEs
• Security-focused code reviews
• Automated security testing in CI/CD
• Security validation before production deployment

Your Responsibility: Conduct threat modeling, train developers, integrate Code Analyzer in CI/CD, require security-aware code reviews.

It’s important to design defenses against common vulnerabilities in a Salesforce context. Let’s take a closer look at how we map to the 2025 OWASP Top 10 at Salesforce.

• A01:2025 - Broken Access Control: Programmatically enforce CRUD and field-level security (FLS) in all Apex data access.
  • In API version 67.0 or later, Apex runs in user context by default, which means that the current user's permissions and FLS are enforced during code execution.
    • WITH SECURITYENFORCED was removed, which causes a compilation error. Replace any existing uses with WITH USER_MODE. The platform enforces access in standard UI.
  • In API version 66.0 or earlier, system mode is the default. Use WITH USERMODE in SOQL queries or Security.stripInaccessible() for DML operations.
• A01:2025 - Client-Side Data APIs: Lightning Data Service and the UI API automatically enforce the running user's FLS, CRUD, and sharing, so a component that’s built upon them inherits least privilege by default.
  • This protection is lost when a component calls a custom Apex. Imperative Apex only enforces access when it runs in user mode, so a class that’s declared without sharing acts as an escape hatch that silently bypasses the model.
  • Use Lightning Data Service and the UI API for data access.
  • You must re-assert CRUD, FLS, and sharing for every imperative Apex call from a component.
• A02:2025 - Security Misconfiguration: Monitor configuration drift from security baselines using Health Check.
  • Disable Guest User access on Experience Cloud sites (unless it’s explicitly required under a documented business justification).
• A05:2025 - Injection: The 2025 Injection category covers SOQL/SOSL injection and cross-site scripting (XSS).
  • For query injection, use bind variables for all dynamic queries. Never concatenate user input directly into query strings. The platform's parameterized query mechanisms eliminate injection risk when they’re used correctly.
  • SOQL or SOSL injections are scoped to a reading that discloses records or fields that the caller shouldn't be able to reach by widening query conditions. Since these languages read data while writes run through separate DML operations, this creates an access-control and confidentiality risk because it compounds when object and field permissions aren't enforced on the query.
  • For XSS, Lightning Web Components provide automatic protection via the LWC rendering engine.
  • For Aura components and Visualforce, you need to apply platform encoding functions (for example, HTMLENCODE, JSENCODE, and URLENCODE) when rendering dynamic content.

Your Responsibility: Enforce CRUD/FLS in custom code, apply encoding functions, use bind variables, monitor configuration drift.

Design CI/CD pipelines with security gates at every stage. Security must be automated to scale with development velocity.

Let’s take a closer look at the pipeline security stages.

• Source control uses branch protection rules with required code reviews. There are no direct commits to main branches or signed commits.
• Static analysis uses the Salesforce Code Analyzer, which incorporates PMD, ESLint, and RetireJS to detect injection, XSS, and insecure patterns.
• Security scanning uses SAST tools and secrets detection to prevent credential commits and dependency vulnerability scanning.
• Permission validation uses automated comparison techniques to review permission changes against security baselines, which sends alerts regarding privilege expansion.
• Deployment gates break deployment on critical security findings that require security team approval for permission-expanding changes.
• Post-deployment monitoring uses Event Monitoring alerts for anomalous behavior following deployments.

Your Responsibility: Integrate Code Analyzer in CI/CD, configure branch protection, implement deployment gates, validate permissions automatically.

Comprehensive security testing includes multiple techniques that address different vulnerability classes. Let’s take a closer look at each strategy.

• Static analysis runs Salesforce Code Analyzer in developer IDEs for immediate feedback, and in CI/CD pipelines as automated gates. Static analysis identifies vulnerabilities in source code without executing the application.
• Penetration Testing conducts penetration testing for custom applications that are exposed to untrusted users, particularly Experience Cloud sites and public-facing APIs.
  • For AppExchange and AgentExchange Security Review, static analysis reports are always required.
  • A dynamic scan report (penetration test) is required when the solution integrates a third-party web application or service.
  • Penetration testing simulates attacker techniques against live applications.
• Security-Focused Unit Tests write Apex tests that validate access control enforcement by running as users with different permission profiles. It’s important to verify that CRUD/FLS enforcement blocks unauthorized access.
• Dependency scanning monitors AgentExchange packages and JavaScript libraries for known vulnerabilities. It’s important to subscribe to security advisories for installed packages.

Your Responsibility: Run Code Analyzer, conduct penetration testing, write security unit tests, scan dependencies.

At Salesforce, security and data incident response focuses on detecting, containing, and recovering from breaches, unauthorized access, and malicious data destruction. Incident response teams work alongside two neighboring pillars that own adjacent responsibilities:

• Operational Excellence covers the operational machinery of incident management (for example, severity tiers, on-call rotation, escalation, and post-incident review)
• Reliability covers availability recovery against RTO and RPO targets, including backup and disaster-recovery strategy.

As an architect, it’s your responsibility to design for security incident detectability, response, and recovery.

Detectability is an architectural quality that you must design for explicitly. Without comprehensive monitoring, security incidents may remain undetected for extended periods of time.

It’s important to implement detection through multiple channels.

• Event Monitoring captures raw event logs that cover logins, report and data exports, permission changes, and API calls. You need to identify which events are anomalous, which requires Transaction Security policies or SIEM correlation on top of the logs that you configure to determine the detection logic.
• Transaction Security policies evaluate events in real time and block suspicious actions. You need to configure these policies.
• Setup Audit Trail tracks the administrative changes that the platform provides, but you need to monitor them.
• Custom application logging captures security-relevant events in Apex that you need to implement.

Route Event Monitoring logs to SIEM platforms for correlation with enterprise security telemetry. Design alert rules that detect suspicious patterns while also minimizing false positives through behavioral baselines.

Your Responsibility: Route Event Monitoring to SIEM, configure Transaction Security policies, implement custom logging, establish behavioral baselines.

It’s important to document architectural decisions that support incident response before incidents occur.

• Isolation boundaries design solutions to isolate compromised components without disrupting critical business functions. You need to configure the permission set revocation, IP restriction changes, and session termination to provide rapid isolation capabilities.
• Forensic preservation uses Event Monitoring to provide detailed activity logs (platform feature). Field Audit Trail preserves data change history based on your configuration. Design logs route to immutable storage so attackers can't modify your architecture.
• Recovery procedures document tested recovery processes for common incident types. It’s important to validate backup integrity regularly. You need to know your Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for security incident scenarios.
• Communication workflows design notification mechanisms that function during incidents (for example, out-of-band communication channels, pre-drafted templates, and escalation procedures that don't depend on potentially compromised systems).
• Vulnerability disclosure channel is for public-facing Experience Cloud sites. It gives external researchers a documented, monitored way to report security issues to you via a disclosure policy that’s published in the RFC 9116 security.txt standard. An external report is often the first signal of an incident, so it’s important to establish this intake path as part of the architecture that you’re responsible for.

Your Responsibility: Document isolation procedures, route logs to immutable external storage, test recovery procedures quarterly, establish out-of-band communication, publish a vulnerability disclosure channel for public-facing sites.

At Salesforce, it’s important to prepare response capabilities for platform-specific scenarios.

• Compromised user accounts are detected via Event Monitoring login anomalies (for example, unexpected geography, unusual times, and new devices). When accounts are compromised, freeze the user, force credential reset, review the Setup Audit Trail and data access logs to determine the compromise period.
• Bulk data exfiltration is detected via Event Monitoring report exports and API data access volume anomalies. When data exfiltration occurs, revoke sessions immediately, restrict permissions, and identify affected records and classification levels.
• Unauthorized code deployment is detected via deployment monitoring and Setup Audit Trail configuration changes. When unauthorized code is deployed, immediately roll-back the deployment, and audit all changes from the compromised deployment credential.
• Privilege escalation is detected via Setup Audit Trail monitoring for permission changes that are outside of approved change windows. When privilege escalation occurs, immediately revoke escalated privileges, and audit activities that were performed with elevated access.

Your Responsibility: Document response procedures for platform-specific scenarios, configure monitoring to detect each scenario, test procedures through tabletop exercises.

After an incident, it’s important to conduct a judgment-free, post-incident review that’s focused on architectural improvements. You need to document what happened, why the existing controls failed to prevent or detect the incident, and what architectural changes are needed to reduce future risks.

Post-incident review objectives:

• Determine the incident timeline and attacker techniques.
• Identify the control failures that enabled the incident.
• Document all architectural weaknesses that the incident revealed.
• Prioritize remediation that’s based on risk reduction.
• Share lessons learned across teams.
• Update detection rules and response procedures.

It’s important to track incident metrics over time to determine the mean time to detect (MTTD), mean time to respond (MTTR), and impact scope.

Your Responsibility: Conduct a timely post-incident review, document improvements in ADRs, track MTTD and MTTR trends, share lessons learned.

Use this checklist during architecture reviews, before production deployment, and periodically for ongoing assessment. Every item represents your responsibilities as a Salesforce architect.

Shared Responsibility

• Document everything that Salesforce secures (for example, infrastructure, platform, and compliance certifications).
• Document everything you must secure (for example, configuration, access, custom code, and data governance).
• Identify areas of shared responsibility (for example, incident response, vulnerability management, and monitoring).
• Communicate responsibilities to stakeholders and implementation teams as clearly and concisely as possible.

Security Architecture

• Complete threat modeling using the STRIDE methodology before you begin to build.
• Apply defense-in-depth controls at data, application, identity, and integration layers.
• Implement zero-trust principles that require explicit verification for every access request.
• Maintain current security asset inventory that covers sensitive data, integrations, APIs, and privileged accounts.
• Document security architecture decisions in ADRs, including threat analysis and control justification.
• Secure headless and on-behalf-of clients at the Salesforce trust boundary by propagating per-user identities rather than pool tokens.
• Store, rotate, and least-privilege-scope OAuth credentials via External Client Apps.
• For containerized integrations, enforce container isolation as a security boundary, encrypt inter-container and hybrid VPN traffic with mTLS (when the framework requires it), and align deployment regions with data residency and compliance certifications

Identity and Access Management

• Set OWDs to Private for objects that contain sensitive data.
• Reserve Public Read Only for objects where broad read access is a documented requirement.
• Enforce MFA for all production UI access, and hardware security keys for privileged accounts. API-only integrations that use JWT Bearer or client credentials are exempt.
• Implement SSO using SAML 2.0 or OpenID Connect with strong IdP authentication.
• Use OAuth 2.0 (JWT Bearer preferred) for all API authentication. Never use OAuth 2.0 for embedded credentials.
• Grant access via permission sets that are based on documented least-privilege requirements.
• Apply enhanced controls to critical impact accounts (for example, IP restriction, login alerts, and periodic access reviews).
• Conduct periodic access reviews using documented attestation for high-privilege accounts where the frequency is determined by organizational risk tolerance and compliance requirements.
• Automate the identity lifecycle via SCIM provisioning and 90-day dormant account detection.
• Run employee agents in the logged-in user's context, and provision dedicated, least-privilege Agent Users for customer agents. Never do this for a public-site guest user.
• Implement JWT for agent authentication using agent instance and bot definition identifiers.
• Define ABAC policies that align with data classification and consistent metadata tagging standards.

Data Protection and Privacy

• Classify all data, and apply protection controls that are appropriate to each classification level.
• Enable Shield Platform Encryption for Restricted data using documented key management.
• Require TLS 1.2+ for all integrations with certificate-based auth for Restricted data.
• Prevent Restricted data from entering non-production environments via masking or exclusion.
• Implement consent management with granular per-purpose tracking and withdrawal workflows.
• Build data subject rights workflows that complete within each governing framework's response deadline. These should be sized to the tightest window in your operating footprint and parameterized per jurisdiction from a maintained compliance source where each figure is confirmed against the governing regulation.
• Document data residency requirements and validate Hyperforce region alignment.

Compliance and Regulatory Adherence

• Validate platform certifications that satisfy regulatory requirements for your industry.
• Enable Event Monitoring with SIEM routing for retention that exceeds native retention limits.
• Configure Field Audit Trail to cover Restricted fields to ensure that retention meets regulatory minimums.
• Maintain Security Health Check scores of 80% or higher (Very Good or Excellent band), and document any exceptions.
• Automate compliance validation for CI/CD pipelines that break during critical violations.
• Implement Transaction Security policies for real-time anomaly detection and response.

Secure Development Lifecycle

• Conduct threat modeling during the design phase (before making significant build investments).
• Enforce CRUD/FLS in all Apex environments.
• Rely on automatic user-mode enforcement for API version 67.0 or later, or use WITH USERMODE or stripInaccessible() for API version 66.0 or earlier.
• Don’t use WITH SECURITYENFORCED, which was removed in API version 67.0.
• Run Salesforce Code Analyzer in CI/CD when critical findings block deployment.
• Require code reviews by security-aware reviewers for all production changes.
• Conduct penetration testing for all public-facing applications and Experience Cloud sites.
• Validate and sanitize all user input that prevents injection across SOQL, SOSL, and HTML contexts.

Security Incident Response

• Design Event Monitoring alert rules to detect suspicious patterns via behavioral baselines.
• Route logs to immutable external storage for forensic preservation.
• Document and test incident response procedures for platform-specific scenarios.
• Conduct blameless post-incident reviews with ADRs to capture architectural improvements.
• Track MTTD and MTTR metrics to identify detection and response gaps.

Share your feedback on the Well-Architected Framework.