Salesforce Shield: Platform Encryption, Event Monitoring, and Field Audit Trail

Shield Platform Encryption Architecture (Probabilistic vs Deterministic)

Salesforce Shield Platform Encryption provides enterprise-grade data encryption at rest while maintaining critical CRM functionalities. The foundation of this system relies on a two-tier key architecture consisting of a Master Secret managed by Salesforce and a Tenant Secret managed by the customer. When these secrets are combined, the application server generates a unique Data Encryption Key (DEK) locally to encrypt and decrypt fields on the fly using standard AES-256 encryption.

Architects must choose between two encryption schemes: Probabilistic and Deterministic. Probabilistic encryption is the most secure option. It generates completely different, random ciphertext every single time the same plaintext is encrypted. For instance, if you encrypt the word "Vedas" twice, the resulting ciphertexts will not match. While highly secure, this method prevents users from filtering, searching, or grouping by this field in SOQL queries, since the database cannot perform match operations on dynamic ciphertext.

To support standard search and filtering requirements, Salesforce introduced Deterministic encryption. With Deterministic encryption, the same plaintext always yields the identical ciphertext (e.g. "Vedas" always encrypts to "Xy78z"). This allows exact match filtering in WHERE clauses, index structures, and report filters. Within Deterministic encryption, you must choose between Case-Sensitive (requires precise case matching) and Case-Insensitive (converts text to lowercase prior to encryption) schemes.

When designing schemas, probabilistic encryption should be utilised for highly sensitive fields that do not require search filtering (such as Credit Card Numbers or Social Security Numbers). Conversely, deterministic encryption is suited for fields like Email Address or Account Name that are regularly queried.

Secret Management, Rotation, and Key Derivation

Securing and managing encryption keys is a critical governance requirement. Salesforce Shield employs a secure, hardware-based key derivation process. The tenant secret is generated using a secure Hardware Security Module (HSM) on demand. Architects can choose to have Salesforce generate this secret, or they can opt for a "Bring Your Own Key" (BYOK) architecture, where the tenant secret is generated in their own external cloud key manager (such as AWS KMS) and uploaded securely to Salesforce.

To maintain standard compliance, organizations must establish a routine rotation cycle for tenant secrets. Rotating a secret changes the active key used for encrypting new data. Crucially, legacy archived data remains encrypted with the old archived secrets. If you rotate your tenant secret, historical data is not automatically re-encrypted. The legacy keys must remain stored in an archived state within the org to allow decryption on the fly, unless you trigger a full data sync to rewrite and re-encrypt historical records.

Managing tenant secrets programmatically can be achieved via the Tooling API. The following metadata pattern outlines the logical structure of a TenantSecret representation in Salesforce:

// Conceptual representation of querying Tenant Secret metadata for compliance auditing
public class TenantKeyAuditService {
    public static void logActiveSecrets() {
        // Querying the active tenant secret metadata via Tooling API mock/query structure
        List<TenantSecretInfo> secrets = new List<TenantSecretInfo>();
        // Standard compliance mandates that we check for active, archived, and destroyed key states
        for (TenantSecretInfo secret : secrets) {
            System.debug('Secret Id: ' + secret.Id + ' Status: ' + secret.Status + ' Type: ' + secret.Type);
        }
    }
    
    private class TenantSecretInfo {
        public String Id;
        public String Status; // Active, Archived, Destroyed
        public String Type;   // DataTemplate, SearchIndex, Analytics
    }
}

Archiving a key makes it read-only, which is necessary for historical decryption. Under no circumstances should you destroy an archived tenant secret unless you are absolutely certain that no data in the database remains encrypted with that specific key. Destroying an archived secret without re-encrypting the associated data will lead to permanent, unrecoverable data loss.

Real-Time Event Monitoring and Threat Detection

Salesforce Shield Event Monitoring exposes deep behavioural analytics by tracking user activity across more than 50 different event types, including logins, report exports, API queries, and page views. While legacy Event Monitoring relies on daily log files stored in the EventLogFile object, Real-Time Event Monitoring leverages the Salesforce Event Bus to broadcast events as they occur, enabling instant threat mitigation.

Using Transaction Security Policies (built on the enhanced policy framework), architects can write Apex classes that continuously evaluate user behaviour against risk thresholds. If a user attempts to export more than a specific limit of Contact records, the system can dynamically block the transaction, log the threat, and prompt the user to complete Multi-Factor Authentication (MFA).

The following Apex pattern illustrates how to construct an enhanced Transaction Security policy to intercept and block high-volume report exports:

global class HighVolumeExportBlocker implements TxnSecurity.EventCondition {
    public boolean evaluate(SObject event) {
        if (event instanceof ReportEvent) {
            ReportEvent repEvent = (ReportEvent) event;
            // Intercept report exports where the row count exceeds 1000 records
            if (repEvent.Operation == 'Export' && repEvent.RowsProcessed > 1000) {
                return true; // Trigger policy action (e.g. block or enforce MFA)
            }
        }
        return false;
    }
}

Deploying this automated defensive logic directly onto the Salesforce Event Bus secures the perimeter of the CRM, ensuring that external threats or malicious insider behaviours are instantly blocked before data leakage can occur.

Field Audit Trail (FAT) and Historical Data Archival

Standard Field History Tracking is limited to 20 fields per object and retains history records for up to 18 months. In highly regulated sectors like banking, healthcare, and insurance, standard compliance rules require changes to be audited for up to a decade. Field Audit Trail (FAT) elevates this limit, allowing organizations to track up to 60 fields per object and store history records for up to 10 years.

FAT achieves this long-term storage capacity by offloading history records into high-scale big tables (Big Objects). Managing the retention lifecycle of these histories is configured via the Metadata API using the HistoryRetentionPolicy component. This XML-based policy specifies how long history records remain in standard active storage before being automatically archived into big tables.

Below is an example of a HistoryRetentionPolicy metadata configuration for a custom object:

<?xml version="1.0" encoding="UTF-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
    <historyRetentionPolicy>
        <archiveAfterMonths>6</archiveAfterMonths>
        <archiveRetentionYears>10</archiveRetentionYears>
        <gracePeriodDays>30</gracePeriodDays>
    </historyRetentionPolicy>
</CustomObject>

Once archived into big tables, these histories can be queried using standard SOQL (provided you filter exactly on the primary key fields of the Big Object) or by using Async SOQL for complex reporting. This architecture ensures that historical changes remain queryable for audits without degrading the performance of active CRM databases.

Performance Optimisation and Technical Limitations of Shield

While Shield Platform Encryption is essential for security compliance, it introduces specific technical limitations and performance impacts that must be carefully managed. When encryption is active, the database must decrypt fields on the fly, which can introduce processing latency during high-volume data loads.

The most significant impact is on database indexing. Standard custom indexes cannot be built directly on probabilistically encrypted fields because the index cannot match random ciphertexts. Consequently, using a probabilistically encrypted field in a SOQL WHERE clause will trigger a full table scan, degrading query performance and potentially resulting in query timeouts on large tables.

To optimise performance and maintain scalability, architects should adhere to the following best practices:

• Prefer Deterministic encryption for fields that must be used in search forms, filters, or SOQL queries.
• Use custom indexes specifically derived for deterministic fields by coordinating with Salesforce Support.
• Avoid encrypting system fields, formula fields, or fields used in active workflow rules and validation rules.
• Optimise search layouts and restrict wildcard searches, as standard searching behaves differently with encrypted strings.

By systematically addressing indexing challenges, managing key lifecycles, and writing precise real-time transaction guards, you can design a secure, compliant Salesforce org that scales effortlessly under extreme workloads.