Zero-Trust Security in Salesforce: The Modern Approach

The Philosophy of Zero-Trust in CRM Environments

For decades, enterprise security relied on a network-centric "castle-and-moat" paradigm. Access was determined by whether a user was inside the corporate perimeter—such as a specific office building or logged in via a virtual private network (VPN). However, the rise of cloud-native systems, remote working, and dynamic mobile environments has rendered this network-focused security model obsolete. In the modern enterprise, CRM environments hold highly sensitive customer databases, intellectual property, and financial records. Enforcing perimeter-based security alone leaves organisations vulnerable to lateral movement if an attacker breaches the outer network.

The Zero-Trust framework addresses this challenge by operating on three fundamental tenets: "never trust, always verify," "enforce least privilege," and "assume breach." In a Zero-Trust Salesforce architecture, we do not grant access based on a user's location or their corporate network connection. Instead, every single access request is evaluated dynamically. We verify the user's identity, the security state of their device, the time of day, the specific record they are attempting to read, and their recent behaviour before granting access. By removing implicit trust, the organisation dramatically reduces its risk profile.

Context-Aware Access Control and Continuous Authentication

Implementing Zero-Trust starts at the login interface. Salesforce architects must configure Context-Aware Access Control to evaluate the specific risk level of each login request in real time. This requires combining native Salesforce security tools, such as Login IP Ranges, Login Hours, Multi-Factor Authentication (MFA), and Session Security Levels.

To implement context-aware verification, define High Assurance sessions. For example, standard passwords grant "Standard" assurance, while completed MFA challenges upgrade the session to "High Assurance". You can enforce a security policy that allows users to browse general pages with standard assurance, but requires high assurance (MFA) when they access sensitive areas, like viewing reports or exporting records.

Additionally, you can deploy custom Login Flows. These flows allow you to run Apex checks during the login handshake to verify external parameters, such as checking if the user's device is registered in your enterprise mobile device management (MDM) system before granting access:

global class MDMDeviceVerifier implements Auth.LoginFlowHandler {
    global PageReference initiate(Map<String, Object> context) {
        Id userId = (Id) context.get('userId');
        String ipAddress = (String) context.get('ipAddress');
        
        // Custom logic to query MDM inventory API to verify device registration
        Boolean isDeviceValid = checkMDMInventory(userId, ipAddress);
        
        if (!isDeviceValid) {
            // Redirect to custom error page or block session instantiation
            return new PageReference('/apex/MDMDeviceValidationError');
        }
        return null; // Proceed with standard authentication flow
    }
    
    private Boolean checkMDMInventory(Id userId, String ipAddress) {
        // Query external MDM database or local registry mapping (Mock representation)
        return true;
    }
}

Integrating this continuous context-aware check ensures that authentication is treated as a dynamic, ongoing process rather than a one-time boundary event.

Enforcing Least Privilege with Restriction and Scoping Rules

Enforcing least privilege is a core component of Zero-Trust. In traditional Salesforce sharing architectures, permissions were largely additive. Org-Wide Defaults (OWD) established the base-level access, and Sharing Rules, Role Hierarchies, and Permission Sets granted broader access to records. However, this additive model made it difficult to restrict access for specific compliance scenarios, such as preventing support agents from viewing highly confidential VIP customer records.

To address this limitation, Salesforce introduced **Restriction Rules** and **Scoping Rules**. Restriction Rules are subtractive, allowing you to explicitly block record access. If a Restriction Rule is active for a user, Salesforce evaluates their sharing access as usual and then applies the rule's criteria to filter out records, ensuring that only records matching the rule are visible.

Below is an example of a RestrictionRule metadata configuration designed to prevent non-executive users from viewing high-value accounts:

<?xml version="1.0" encoding="UTF-8"?>
<RestrictionRule xmlns="http://soap.sforce.com/2006/04/metadata">
    <active>true</active>
    <description>Restrict high-value account access to executives only</description>
    <enforcementType>Restrict</enforcementType>
    <masterLabel>High_Value_Account_Restriction</masterLabel>
    <targetEntity>Account</targetEntity>
    <userCriteria>{!User.UserRole.DeveloperName != 'Executive_Team'}</userCriteria>
    <recordCriteria>{!Record.AnnualRevenue < 5000000}</recordCriteria>
</RestrictionRule>

By utilising this metadata configuration, any user outside the "Executive_Team" role will be unable to view Account records where Annual Revenue is 5,000,000 or greater, even if their standard profile or sharing rules would otherwise grant access.

Real-Time Threat Mitigation via Transaction Security

Zero-Trust architectures assume that breaches will occur. Therefore, continuous monitoring of user behaviours is critical. Real-Time Event Monitoring enables transaction security policies to act as an automated firewall inside your Salesforce org, blocking threats as they occur.

For example, if a user's credentials are compromised, an attacker might log in and immediately attempt to export a customer contact list. A Transaction Security Policy can intercept this request in real time, evaluate the volume, and block the action.

The following Apex pattern illustrates how to programmatically evaluate and intercept suspicious API query behaviour:

global class SuspiciousQueryBlocker implements TxnSecurity.EventCondition {
    public boolean evaluate(SObject event) {
        if (event instanceof ApiEvent) {
            ApiEvent apiEvt = (ApiEvent) event;
            // Track API queries that pull large amounts of contact data at unusual times
            Integer hour = DateTime.now().hour();
            if (apiEvt.QueriedEntities.contains('Contact') && apiEvt.RowsProcessed > 5000 && (hour < 6 || hour > 20)) {
                return true; // Suspend the API call or trigger security notifications
            }
        }
        return false;
    }
}

This transaction check runs automatically within the Salesforce application framework, providing immediate threat detection that secures data assets without requiring manual intervention from security analysts.

Securing the API Perimeter and External Integrations

In modern architectures, the Salesforce API is a highly targeted entry point. Securing the API perimeter is just as important as securing user-facing login portals. Under a Zero-Trust strategy, standard username and password combinations for API integrations must be completely deactivated.

Instead, secure all integrations using certificate-based authentication and modern OAuth 2.0 flows, specifically the OAuth 2.0 JWT Bearer Flow for server-to-server communications. The JWT flow requires the calling application to sign a JSON Web Token using a private key, which Salesforce verifies against a certificate uploaded to a custom Connected App.

To secure critical APIs, implement Mutual TLS (mTLS). Standard TLS verifies the identity of the Salesforce server to the client. Mutual TLS requires both Salesforce and the calling client to present and verify certificates to establish a secure, encrypted connection.

• Create dedicated integration users with restricted profiles and minimal permissions.
• Deactivate the "API Enabled" permission for users who do not require system integration access.
• Implement IP whitelisting inside Connected Apps to restrict API calls to trusted IP ranges.
• Conduct regular reviews of OAuth tokens and revoke inactive sessions to minimise risk.

Adhering to these integration standards ensures that your Salesforce APIs are highly secured, establishing a robust Zero-Trust posture across your entire enterprise cloud ecosystem.