Organizations managing Salesforce deployments face a critical vulnerability: OAuth tokens and API credentials enable persistent access that bypasses multi-factor authentication verification. Security incidents have demonstrated this risk when compromised integration tokens enabled unauthorized data access without triggering MFA alerts.

Security teams will learn how to configure Transaction Security Policies, Shield Platform Encryption and OAuth token rotation. These technical controls demonstrate compliance with regulatory monitoring requirements documented in NIST standards.

Regulatory Requirements for Zero Trust in Salesforce

Five regulatory frameworks mandate specific Zero Trust controls for Salesforce environments. This section maps technical controls to compliance requirements, enabling security teams to demonstrate continuous verification and least privilege access to auditors.

• HIPAA Section 164.312: Requires unique user identification and audit controls. Organizations typically apply the 6-year retention requirement from 45 CFR § 164.530(j) (Privacy Rule) to Security Rule audit logs
• GDPR Articles 25 & 32: Mandate data protection by design, encryption and regular security assessment
• SOX Section 404: Requires management assessment of internal control over financial reporting. Per SEC guidance, organizations commonly implement access controls as part of these internal controls
• FedRAMP: Requires continuous monitoring with ongoing authorization and regular security assessments
• NIST SP 800-207A: Provides Zero Trust guidance for cloud applications using authentication and authorization policies

The Five Zero Trust Pillars for Salesforce 

Salesforce requires implementing five Zero Trust pillars: Identity, Device, Data, Application and Network. Each pillar addresses distinct attack vectors while reinforcing the others. Identity controls prevent unauthorized users. Device controls stop compromised endpoints even with valid credentials.

Salesforce officially defines Zero Trust through five overlapping security components. Security teams will learn how to configure specific controls for each pillar and identify gaps in current configurations.

Pillar 1: Identity Security

Scope: This pillar focuses on who is requesting access: authentication, authorization and credential management for users and services. It does not cover device posture validation (Pillar 2) or runtime behavior monitoring (Pillar 4).

Key requirement: Enforce minimum-privilege access for all human and non-human identities accessing Salesforce resources via unique User IDs, Connected App consumer keys and Named Credentials.

Identity security establishes continuous verification for every access request. Dynamic authorization extends beyond initial authentication to ongoing validation throughout each session.

Core Identity Verification Controls

Organizations must assign unique identifiers to every human user and non-human identity. Teams should grant only the minimum privilege levels each function requires.

The platform's API-only integration profile provides the minimum required access for machine-to-machine authentication. The platform prevents integration accounts from accumulating excessive privileges that create backdoor access routes.

Authentication Factors

Identity verification uses multiple authentication methods:

• Physical security keys: FIDO U2F and WebAuthn-compliant hardware tokens that resist phishing attacks
• Built-in authenticators: Push notifications through the Salesforce Authenticator app
• Time-based codes: TOTP generators for software-based verification

Hardware-based verification provides stronger assurance than software-based methods. It resists phishing attacks that compromise passwords.

CI/CD Pipeline Identity Controls

NIST Special Publication 800-204D provides DevSecOps guidance for CI pipelines. Pipelines using external tools should execute only when the trustworthiness of the source code origin is established before deployment. Each deployment agent must authenticate using short-lived tokens rather than stored credentials.

Identity verification requirements for Zero Trust include:

• Unique identifiers for all human and non-human identities 
• Minimum privilege access levels per function
• API-only profiles for machine-to-machine authentication 
• Short-lived tokens replacing long-lived credentials

Pillar 2: Device Security

Scope: This pillar focuses on the endpoint requesting access: device health, posture validation, endpoint protection status and hardware trust. It does not cover user authentication methods (Pillar 1) or network connection context (Pillar 5).

Key requirement: Validate device posture across OS compliance, endpoint protection and MDM enrollment before granting access to Salesforce data.

Device security validates that only authorized and secure devices can access sensitive Salesforce data. This pillar prevents compromised endpoints from becoming attack vectors even when user credentials remain valid.

Device Posture Validation

Device verification requires a comprehensive health assessment before granting access. Organizations must evaluate device security posture across multiple dimensions.

Operating System and Patch Compliance:

• Verify operating system version meets minimum security requirements 
• Confirm the device has installed critical security patches within defined timeframes
• Block access from devices running unsupported or end-of-life operating systems

Endpoint Protection Status:

• Validate active endpoint detection and response (EDR) agents
• Confirm antivirus definitions remain current
• Verify the device has enabled and configured its host-based firewall

Mobile Device Management (MDM) Integration: Salesforce Mobile App supports MDM-managed distribution and can enforce app-level policies:

• Require MDM enrollment for mobile devices accessing Salesforce
• Enforce device encryption requirements 
• Validate screen lock and timeout policies
• Enable remote wipe capabilities for lost or stolen devices

Trusted Device Registration

Organizations should implement device registration workflows that establish baseline trust:

• Register corporate-managed devices through certificate-based authentication 
• Maintain inventory of approved devices with unique identifiers 
• Implement device lifecycle management, including decommissioning procedures 
• Block access from jailbroken or rooted mobile devices

Deployment Agent Security

Each deployment agent must prove its health status before accessing production environments, preventing compromised developer workstations from executing unauthorized deployments.

Required validations include:

• Verified endpoint protection status 
• Current operating system patches 
• No indicators of compromise detected 
• Valid device certificate from corporate PKI

Pillar 3: Data Security

Scope: This pillar focuses on protecting information at rest through encryption, classification, field-level access controls and key management. It does not cover runtime access monitoring (Pillar 4) or data in transit (Pillar 5).

Key requirement: Implement Shield Platform Encryption with customer-managed keys for sensitive fields, while recognizing that encryption alone does not satisfy data protection requirements.

Data security protects information regardless of location through encryption, classification and granular access controls. This pillar maintains confidentiality and enforces least privilege access to sensitive information across the platform.

Salesforce Encryption Architecture

Salesforce's encryption framework protects data at rest through multiple technical approaches that address data sovereignty and key management requirements.

Shield Platform Encryption protects database fields, search indexes and file attachments. Organizations can choose native encryption or AWS Key Management Service integration for customer-managed keys. For data sovereignty requirements, organizations can enable External Key Management to maintain direct control over encryption key material.

Shield Platform Encryption Limitations

Salesforce cannot sort encrypted fields in list views, and some custom fields have encryption restrictions. These constraints mean organizations cannot rely solely on encryption for data protection. Runtime access monitoring (covered in Pillar 4) fills gaps where encryption cannot operate.

Comprehensive encryption is one control for data protection. However, overall requirements also demand consent management, data subject rights and retention policies. Breach notification and auditability round out the complete compliance picture.

Deployment Data Security

Organizations that implement CI/CD workflows must protect sensitive data within deployment packages. Encryption for sensitive data fields per compliance requirements should extend to metadata and configuration data in version control systems.

Pillar 4: Application Security

Scope: This pillar focuses on runtime behavior: monitoring active sessions, policy enforcement, dynamic threat responses and security testing during deployments. It does not cover data encryption at rest (Pillar 3) or initial authentication (Pillar 1).

Key requirement: Configure Transaction Security Policies for automated responses to high-risk events. For example, block report exports exceeding a defined record threshold from users in unexpected locations. Embed SAST/DAST testing in CI/CD pipelines.

Application security secures access to cloud applications through workflow security and runtime protection within the Salesforce ecosystem.

Policy-Based Enforcement

Salesforce Transaction Security Policies provide automated security responses based on specific conditions and events.

Transaction Security Policies provide IF-THEN automation for security responses. When specific events occur with defined field values, the platform responds automatically with alerts, blocking actions, ending sessions or requiring MFA.

Event Types to Monitor

Organizations can monitor:

• Report events indicating data exfiltration 
• List view events suggesting bulk downloads
• File events and login events revealing anomalous locations 
• Permission set events indicating privilege escalation attempts

Real-Time Monitoring

Real-Time Event Monitoring provides near-real-time visibility through platform events. Organizations query these events through SOQL or consume them via standard event subscriptions. This capability supports continuous audit controls required by regulatory frameworks.

CI/CD Security Testing

NIST SP 800-204C guides security testing. Organizations should embed security testing at every pipeline stage:

• Static application security testing (SAST) for code analysis
• Dynamic application security testing (DAST) for runtime vulnerabilities 
• Software composition analysis for dependency risks

These platforms generate an immutable deployment history for compliance reporting. Standard Salesforce Change Sets provide basic deployment functionality without built-in risk analysis features that security-conscious organizations require for automated impact assessment.

Pillar 5: Network Security

Scope: This pillar focuses on connection context: validating request origin, microsegmentation, session integrity and data in transit. It does not cover endpoint posture (Pillar 2) or user identity verification (Pillar 1).

Key requirement: Validate every API call regardless of network origin, including requests authenticated via stolen OAuth tokens from any IP address. Implement microsegmentation to prevent lateral movement.

Network security protects access to resources beyond traditional perimeters through microsegmentation and connection-point validation.

Zero Trust Network Architecture

Modern network security eliminates the assumption that internal network position implies trustworthiness. Zero Trust Architecture prevents data breaches by rejecting the premise that network location means trust.

Remote work and cloud operations mean attackers can authenticate via stolen OAuth tokens from any IP address. The process shifts verification requirements from perimeter controls to identity-based validation at every access point.

For Salesforce deployments, teams must validate every API call and metadata access request regardless of whether the request originates from internal networks or federated identity providers.

Microsegmentation Requirements

NIST SP 800-207 defines microsegmentation as a Zero Trust principle that places security enforcement points between workloads. Organizations must be able to put security services between any two workloads, allowing the isolation of workloads and the enforcement of access controls between infrastructure components.

Session Management

Salesforce's session hijacking detection through Real-Time Event Monitoring identifies IP address or user agent changes, suggesting session replay attacks. Organizations can configure automated enforcement actions, including terminating suspicious sessions, requiring MFA, blocking the action or sending alerts.

Deployment Pipeline Network Controls

Deployment pipelines require the same continuous verification controls that govern platform access. Teams must validate every API call and metadata access request from CI/CD systems regardless of network origin. The deployment shifts security left in the development lifecycle, preventing unauthorized changes from reaching production environments.

Phased Implementation: Prioritizing High-Impact Zero Trust Controls

Implement Zero Trust controls in four phases: (1) Identity and Device, (2) Data Protection, (3) Runtime Protection and (4) Network Segmentation. This sequence maximizes security improvements while managing resource constraints.

Organizations should sequence Zero Trust controls based on risk reduction potential and implementation complexity.

Phase 1: Identity and Device Controls Implement Identity (Pillar 1) and Device (Pillar 2) controls first. Go to Setup > Identity > Multi-Factor Authentication to enable MFA. Configure OAuth token expiration under Setup > Apps > Connected Apps.

Phase 2: Data Protection Expand to Data (Pillar 3) controls. Enable Shield Platform Encryption under Setup > Security > Platform Encryption for sensitive fields.

Phase 3: Runtime Protection Deploy Application (Pillar 4) controls. Configure Transaction Security Policies under Setup > Security > Transaction Security for high-risk events.

Phase 4: Network Segmentation Complete implementation with Network (Pillar 5) controls, including microsegmentation and session management under Setup > Security > Session Settings.

Organizations managing deployments need solutions that maintain governance without slowing release operations. Policy-based deployment controls enable continuous verification throughout release cycles, enforce separation of duties and automatically generate immutable audit records.

Automated audit trails satisfy regulatory retention mandates while supporting rapid incident investigation. 

Request a demo to explore how Flosum’s capabilities can support your Zero Trust implementation.