Security Hardening Checklist for Salesforce Enterprise Orgs

1. Establishing a Robust Baseline: Session Security and Network Access Policies

Securing a Salesforce Enterprise instance requires a defense-in-depth strategy that starts at the outer perimeter. The first boundary of this perimeter is user session security and network-level access controls. Misconfigured session settings are a leading cause of session hijacking and unauthorized credential exploitation. Administrators must establish a rigorous security baseline, balancing standard user experience with enterprise-grade defensive parameters.

The foundation of session security is the enforcement of Multi-Factor Authentication (MFA). Since February 2022, Salesforce has contractually required MFA for all UI logins. To ensure compliance and robust security, administrators should configure MFA using High Assurance session settings. Under Session Settings, "Multi-Factor Authentication" must be moved to the High Assurance column, and all critical, high-risk administrative operations (such as managing users, viewing encrypted data, or modifying Apex) should explicitly require a High Assurance session level. Furthermore, administrators must disable session-sharing mechanics: the "Lock sessions to the IP address from which they originated" setting must be enabled. This parameter ensures that if an attacker steals an active session cookie, they cannot use it from a different network or device, rendering the stolen session useless.

Beyond session parameters, hardening the outer perimeter requires a strict configuration of Content Security Policies (CSP) and Clickjacking protection settings. Under Setup, Clickjacking Protection must be set to 'Enforce Clickjacking Protection for customer Visualforce pages' and standard Lightning pages, preventing attackers from embedding your Salesforce instance within malicious iframes to steal user credentials. Additionally, architects must audit CSP Trusted Sites to ensure that no custom components are allowed to execute external scripts or load images from untrusted external domains. By enforcing a strict Content Security Policy, the platform guarantees that even if a developer accidentally introduces a cross-site scripting (XSS) vulnerability in a custom LWC, the browser will refuse to execute the injected code or connect to unauthorized external servers, containing the threat at the client level.

Complementing session controls, architects must implement network-level access policies. Salesforce offers two mechanisms for IP restrictions: global Network Access settings and Profile-level Login IP Ranges. Understanding the architectural difference between these two features is critical. Global Network Access defines "trusted IP ranges." If a user logs in from an IP address within these ranges, they are permitted to log in without receiving an MFA challenge or identity verification email; however, users logging in from outside these ranges are still allowed to access the system, provided they satisfy the MFA requirement. In contrast, Profile-level Login IP Ranges enforce a strict firewall. If a profile contains defined Login IP Ranges, users assigned to that profile are completely blocked from logging in from any IP address outside those ranges, regardless of their credentials, MFA status, or verification codes. For high-privilege profiles—such as System Administrators and integration accounts—architects must enforce strict Profile-level Login IP Ranges restricted to corporate VPNs or static corporate gateways, shutting down internet-based credential attacks.

2. Securing Integration Accounts and API Access Boundaries

Enterprise Salesforce instances rarely exist in isolation; they are deeply integrated with ERPs, billing systems, marketing tools, and customer databases. These integrations represent high-privilege pathways that, if compromised, can expose the entire Salesforce database to bulk data exfiltration. Hardening integration accounts and establishing strict API access boundaries is a critical priority for lead architects.

A legacy, highly insecure practice is provisioning integration accounts using standard Salesforce User licenses assigned to the standard System Administrator profile. This configuration is a massive violation of the Principle of Least Privilege. It grants the integration complete administrative control, including the ability to delete metadata, modify security settings, and read sensitive data outside its business scope. To secure these pathways, organisations must transition to the native Salesforce Integration license type. This licence is specifically designed for machine-to-machine integrations, is cost-effective, and restricts UI logins. Integration accounts must be assigned custom profiles or permission sets that enforce the "API Only User" permission, preventing anyone from logging into the Salesforce UI using the integration credentials.

When configuring secure OAuth flows, architects must strictly limit the scope of the granted tokens. The 'refresh_token' scope, which allows the client to request new access tokens indefinitely without user re-authentication, must be restricted strictly to trusted offline integrations. For real-time, online integrations, shorter-lived access tokens should be utilized, forcing regular token renewals and preventing long-term credential exploitation if a token is compromised. Additionally, digital certificates used for JWT authentication must follow a strict rotation schedule (e.g., annually), and the private keys must be stored in secure, enterprise-grade key management services, preventing developers from checking private keys directly into git repositories or local build scripts.

Furthermore, the authentication method must be modernized. Subscribing to the legacy Username-Password OAuth flow is highly discouraged and disabled by default in new orgs, as it exposes the password over the wire and bypasses MFA. Integrations must leverage secure OAuth flows, such as the JWT (JSON Web Token) Bearer Flow or the Web Server Flow, using digital certificates and private key pairs. Under this architecture, the integration client signs a JWT with a private key, and Salesforce validates it against the uploaded public certificate, establishing a secure, passwordless authentication boundary. Finally, CRUD and FLS permissions for the integration user must be stripped to the bare minimum. If an integration only syncs Accounts and Opportunities, it must not be granted Read access to Contacts, Cases, or custom payroll objects, containing the blast radius of any external API compromise.

// Best Practice: Programmatic check within custom REST API endpoints to enforce integration user security bounds
@RestResource(urlMapping='/SecureIntegration/v1/*')
global with sharing class SecureIntegrationAPI {
    @HttpGet
    global static void getBillingData() {
        RestResponse res = RestContext.response;
        // Verify that the executing user is restricted strictly to their functional profile
        if (!Schema.sObjectType.Opportunity.fields.Amount.isAccessible()) {
            res.statusCode = 403;
            res.responseBody = Blob.valueOf('Access Denied: Insufficient Field-Level Security privileges.');
            return;
        }
        // Proceed with secure query matching user permissions
    }
}
        

3. Hardening Experience Cloud and Guest User Access Controls

Experience Cloud sites (formerly Communities) provide powerful portals for customers, partners, and public visitors. However, exposing Salesforce data to the public internet introduces high-severity security risks. Historically, guest user misconfigurations have been a primary vector for massive corporate data leaks. Hardening Guest User access control is an absolute requirement for any enterprise security checklist.

The core principle of guest user security is simple: the Guest User Profile must have "No Access" by default to all custom and standard objects. Salesforce has heavily hardened guest user security in recent updates, completely blocking edit or delete permissions for guest users, and forcing all record sharing to occur via Guest User Sharing Rules. Guest User Sharing Rules are unique because they do not rely on record ownership; since guest users cannot own records, these rules share data based on specific criteria (e.g., sharing all records where IsActive__c = true). Architects must rigorously review these rules to ensure they do not accidentally expose private data. A common mistake is using broad criteria that share historical, confidential customer cases or orders with unauthenticated web guests.

Moreover, securing guest user access requires a complete shift in sharing paradigms. Since guest users are unauthenticated, standard sharing mechanics like criteria-based sharing rules must be scrutinized with extreme rigour. Every guest sharing rule must be configured to the absolute minimum required scope. For example, if a guest user needs to view public knowledge articles, the rule must strictly match articles tagged with a 'Public' status and must never expose draft or archived content. Furthermore, architects must disable the 'Secure guest user record access' setting's historical exceptions, forcing all guest sharing to be absolutely private by default (Private OWD). Any public-facing forms (such as Lead-to-Case or Web-to-Lead) must be processed using secure, system-mode Apex classes that perform strict input validation, preventing malicious actors from submitting SQL-injection style parameters or uploading infected files to the organisation's document repository.

Additionally, architects must audit system permissions on the Guest User Profile. Permissions like "View All Users," "Query All Files," and "Run Reports" must be disabled. If "View All Users" is active, a malicious public guest could execute standard API queries to download the names, email addresses, and active profiles of all employees within the company, paving the way for targeted phishing attacks. Similarly, access to the API must be tightly restricted; if the guest profile does not require API access, standard API capabilities must be disabled. Regular SOQL audits must be run in staging environments to identify which objects and records are exposed to the guest user ID.

-- SOQL query to identify active sharing rules targeting Guest Users on custom objects
SELECT DeveloperName, AccessLevel, RowCause, UserOrGroupId 
FROM Custom_Object__Share 
WHERE RowCause = 'GuestRule'
        

4. Auditing Profiles, Permission Sets, and System Administration Roles

Inside the Salesforce org, access control is governed by Profiles and Permission Sets. Over time, enterprise orgs suffer from "permission creep," where users accumulate high-privilege system rights that they no longer require. Auditing profile configurations, restricting system administrator roles, and transitioning to a modern permission set architecture is essential to securing the internal data layer.

A critical metric in any security audit is the count of active System Administrators. In many organisations, users are granted the System Administrator profile temporarily to troubleshoot a bug or deploy a package, and the privilege is never revoked. Best practice dictates that the number of active system administrators in a production environment should be restricted to a bare minimum—typically between 2 and 5 active accounts, depending on the size of the organisation. For other developers or support staff, delegated administration or highly targeted permission sets should be used. High-risk system permissions—such as "Modify All Data," "View All Data," "Author Apex," and "Customize Application"—must be stripped from all standard profiles and restricted exclusively to audited permission sets assigned to specific users for limited durations.

To implement this model effectively, organisations must transition to the modern "Profile-less" design paradigm. Under this architecture, the standard profile is restricted to a bare minimum baseline, and all functional permissions, CRUD, FLS, and system rights are provisioned via modular Permission Sets grouped within Permission Set Groups. This layout allows for modular, modular access control. Furthermore, architects can implement session-based permission sets, which require users to authenticate via a high-assurance session (such as MFA) or activate a specific role in a custom UI before the high-privilege permission set is dynamically activated for their session, enforcing the principle of just-in-time access.

// Apex utility to audit the number of active users with Modify All Data system privilege
public static void auditSystemAdmins() {
    List adminAssignments = [
        SELECT Assignee.Name, Assignee.Username, PermissionSet.Name 
        FROM PermissionSetAssignment 
        WHERE Assignee.IsActive = true 
        AND (PermissionSet.PermissionsModifyAllData = true OR PermissionSet.Profile.Name = 'System Administrator')
    ];
    System.debug('Total Active High-Privilege Users: ' + adminAssignments.size());
    for (PermissionSetAssignment psa : adminAssignments) {
        System.debug('Admin User: ' + psa.Assignee.Username + ' via ' + psa.PermissionSet.Name);
    }
}
        

5. Automated Threat Mitigation and Continuous Health Check Governance

Deploying a secure baseline is a significant achievement, but maintaining that baseline requires continuous monitoring and automated threat mitigation. Without automated governance, configuration changes made during emergency hotfixes or rapid feature deployments can silently degrade the organisation's security posture, exposing the platform to fresh vulnerabilities.

The primary tool for automated posture assessment is the native Salesforce Security Health Check. This utility evaluates the organisation's security settings against a Salesforce-recommended industry baseline, returning a comprehensive security score from 0% to 100%. The Health Check scans configurations across four core categories: Session Settings, Password Policies, Network Access, and File Protection. High-risk issues—such as permitting weak password complexity, overly long session lifetimes, or disabled clickjacking protection—are flagged instantly. Enterprises must establish a corporate compliance standard: the Security Health Check must be run regularly, with a target score of 90% or higher. Any deployment that causes the score to drop below the established baseline must be blocked or automatically escalated for remediation.

For organisations requiring advanced, multi-org security governance, the Salesforce Security Center provides centralized tracking of security metrics, permission assignments, and configuration changes across production and sandbox environments. Additionally, lead architects can develop custom, lightweight Apex schedulers that programmatically run compliance checks (such as verifying that no new custom object has been deployed without classification, or that guest sharing rules remain configured to secure thresholds) and email daily status reports directly to the Security Operations Center. By combining native automated tooling, continuous policy verification, and rigorous internal administrative audits, enterprise organisations can maintain an unyielding, audit-ready security posture in an ever-evolving digital landscape.