Encryption in Salesforce: Classic vs Shield — When Do You Need It?

1. The Cryptographic Foundations: Classic vs Shield Encryption

In the contemporary enterprise landscape, data protection is not merely a technical preference; it is a fundamental regulatory mandate. Within the Salesforce ecosystem, architects and security officers are frequently confronted with the critical decision of implementing data encryption at rest. To execute this decision correctly, one must understand the distinct cryptographic foundations of Classic Encryption and Salesforce Shield Platform Encryption. These two technologies operate at completely different tiers of the platform architecture, offering varied levels of security, administrative control, and functional impact.

Classic Encryption is a native, free feature of the Salesforce platform. It operates strictly at the application tier. When a field is designated as Classic Encrypted (using the custom field type Text (Encrypted)), Salesforce encrypts the data using a shared 128-bit Advanced Encryption Standard (AES) key. This key is entirely managed by Salesforce; the subscriber organisation has no visibility into, nor control over, its lifecycle, rotation, or composition. The primary objective of Classic Encryption is not database-level threat mitigation, but rather user-interface level data masking. It is designed to prevent standard users from seeing sensitive values in plain text on their screens while allowing authorised administrators (with the "View Encrypted Data" permission) to view the actual data. This is a critical distinction: the data is encrypted at the application layer before being written to the database, but it shares a key infrastructure with other customers and offers no granular key governance.

In contrast, Salesforce Shield Platform Encryption is a premium, enterprise-grade offering that integrates deeply with the database tier. Shield does not merely mask data at the UI layer; it encrypts the underlying data at rest across the entire Salesforce multi-tenant infrastructure. It employs a much more robust cryptographic standard, utilizing 256-bit AES encryption in Cipher Block Chaining (CBC) mode. More importantly, Shield introduces a split-key architecture that empowers organisations with Bring Your Own Key (BYOK) capabilities. The final encryption key is derived dynamically by a secure key derivation function (KDF) using two distinct components: a master secret generated by Salesforce's Hardware Security Modules (HSMs) and a tenant secret generated and managed solely by the subscriber organisation. This means that even Salesforce personnel cannot decrypt the customer's data, as they lack access to the customer's tenant secret. Shield Platform Encryption provides comprehensive coverage, allowing architects to encrypt standard fields, custom fields, files, attachments, search indexes, and even platform events, thereby meeting stringent compliance frameworks like GDPR, HIPAA, and PCI-DSS.

2. Classic Encryption: Capabilities, Use Cases, and Major Limitations

Classic Encryption represents a legacy approach to field-level security that remains highly useful for specific, low-complexity scenarios. Its implementation is straightforward: an administrator creates a custom field of type Text (Encrypted), defines a masking character (such as an asterisk) and a masking schema (such as masking all characters or exposing only the last four digits), and establishes the field length. Because it operates at the application tier, the data is stored in the database in a formatted ciphertext structure. Only users whose profiles or permission sets contain the "View Encrypted Data" system permission can see the decrypted value in the user interface. For all other users, the value remains obscured by the designated masking pattern.

While this UI masking is highly effective for basic use cases like storing credit card numbers or government identity numbers that only a select payroll or billing team should see, the functional limitations of Classic Encryption are severe and far-reaching. First and foremost, Classic Encrypted fields cannot be indexed by the Salesforce database engine. This lack of indexing means that these fields cannot be used in search filters, list view filters, lookup filters, or report criteria. If a business process requires users to locate a record by searching for a Classic Encrypted value, the platform will return an error or fail to locate the record entirely. Furthermore, Classic Encrypted fields cannot be designated as Unique or as External IDs, preventing them from being used as target keys in upsert operations or integration mapping.

From a development perspective, Classic Encrypted fields introduce strict programming constraints. They cannot be referenced in formula fields, workflow rules, validation rules, or process builder criteria. Any attempt to access the field value in an Apex class will return the decrypted plain text if the executing context has the necessary permissions, but will return the masked string otherwise. This unpredictable behaviour can cause silent failures in integration services or Apex triggers if the system context does not align perfectly with user permissions. Furthermore, because Classic Encryption is restricted exclusively to custom text fields, standard fields (such as a Contact's primary email address or a Lead's phone number) cannot be protected using this tool, forcing organisations to create redundant custom fields and complex synchronization routines to secure standard customer details.

3. Salesforce Shield Platform Encryption: Deterministic vs Probabilistic Schemes

To overcome the indexing and functional roadblocks of Classic Encryption while elevating cryptographic strength, Salesforce Shield Platform Encryption offers two distinct encryption schemes: Probabilistic Encryption and Deterministic Encryption. Choosing the correct scheme is one of the most critical architectural decisions during a Shield rollout, as it represents a direct trade-off between cryptographic strength and application functionality.

Probabilistic Encryption is the default and cryptographically strongest scheme. It uses AES-256 in CBC mode with a randomly generated Initialization Vector (IV) for every single encryption transaction. Because the IV is unique each time data is written, the exact same plaintext value (for example, "London") will result in entirely different ciphertexts every time it is saved. This cryptographic high-entropy behaviour ensures absolute protection against pattern analysis and ciphertext-only attacks. However, this high security comes at a significant functional cost. Because the ciphertext for "London" on Record A is different from the ciphertext for "London" on Record B, the database cannot perform any index lookups or equality checks. Consequently, fields encrypted with the probabilistic scheme cannot be filtered in SOQL queries, cannot be used in reports, cannot be sorted, and cannot be used in list view search criteria. It is an absolute barrier to search and filter operations, making it suitable only for unstructured data, notes, attachments, or fields that are accessed purely as read-only values on a known record detail page.

To restore search and filter capabilities, Salesforce introduced Deterministic Encryption. This scheme uses a static or predictable IV derived from the plaintext value and the key, or a specialised Feistel-based format. Under this scheme, the plaintext "London" will always generate the exact same ciphertext whenever it is encrypted within the organisation. Because of this consistency, the database engine can build indexes on the ciphertext values. Consequently, when a user or an Apex class executes a SOQL query using an exact match operator (e.g., WHERE City__c = 'London'), Salesforce can encrypt the query parameter "London" using the same deterministic algorithm, locate the matching ciphertext in the database index, and return the records instantly. Deterministic encryption supports exact-match filtering in SOQL, lookup filters, report filters, and list views. However, architects must remain aware that it does not support range-based filtering (such as WHERE Age__c > 30), fuzzy matching, or wildcard searches using the LIKE operator (such as WHERE City__c LIKE 'Lon%'). The data must be matched exactly, and the field must be configured for deterministic search before the index can be built.

// Example of a valid exact-match SOQL query on a deterministically encrypted custom field
List contacts = [SELECT Id, LastName, National_ID__c FROM Contact WHERE National_ID__c = '123-45-6789'];
System.debug('Found Contact: ' + contacts.size());
        

4. The Architectural and Functional Impact of Shield Encryption

Deploying Salesforce Shield Platform Encryption introduces a profound architectural overlay that impacts almost every subsystem of the platform. Unlike Classic Encryption, which is transparent to the database engine but opaque to UI filters, Shield is transparent to the UI (relying on standard FLS for access control) but alters how the database engine interacts with indexes, search engines, and background processes. When Shield is activated, the application server handles decryption on-the-fly as records are retrieved. If a user has Field-Level Security access to see the field, they will see the plain text; if not, standard FLS restrictions apply. This eliminates the need for the special "View Encrypted Data" permission for everyday business activities, standardising data access control under a single permission model.

However, the downstream impacts on standard Salesforce features can be disruptive if not meticulously analysed during the design phase. For instance, standard search functionality (SOSL) is heavily impacted. When a field is probabilistically encrypted, it is completely excluded from the search index; searching for a keyword will never return records based on that field. When a field is deterministically encrypted, it is indexed, but users must search for the exact, case-sensitive term to retrieve a match. Furthermore, Shield alters the behaviour of skin-deep features like Lead Conversion. If a custom field on the Lead is encrypted, it can only map to a custom field on the Contact or Account that is also encrypted using the exact same scheme and key. Similar restrictions apply to custom formula fields: a formula cannot reference a probabilistically encrypted field, and can only reference a deterministically encrypted field under strict conditions where no text manipulation or range calculation occurs.

For custom development, developers must write Apex triggers and classes with extreme caution. Standard triggers that execute custom validation or data cleansing must be tested to ensure they do not perform unsupported operations on encrypted fields. For example, if a developer attempts to concatenate an encrypted field with a plain-text string, or attempts to execute a dynamic SOQL query with a wildcard filter on an encrypted field, the transaction will fail at runtime. Architects must also evaluate third-party integrations. When external systems fetch data via REST or SOAP APIs, the data is automatically decrypted by Salesforce before being sent across the wire, provided the integration user account has the appropriate FLS permissions. This means that Shield protects data "at rest" within the Salesforce database, but does not secure it "in transit" or once it leaves the platform; integrations must employ transport-layer security (TLS 1.3) and secure endpoints to maintain end-to-end data protection.

// Apex utility method to demonstrate check for field encryption status programmatically
public static void checkFieldEncryption() {
    Schema.DescribeFieldResult dfr = Schema.sObjectType.Contact.fields.National_ID__c.getDescribe();
    System.debug('Is Encrypted at Rest: ' + dfr.isEncrypted());
    // Best practice: Always verify FLS before querying or displaying sensitive data
    if (dfr.isAccessible()) {
        System.debug('Field is accessible for current execution context.');
    } else {
        System.debug('Field access denied: Enforcing least privilege.');
    }
}
        

5. Designing a Risk-Based Encryption Strategy and Governance Model

Because of the functional overhead and potential performance penalties associated with database-level encryption, enterprise organisations must avoid the temptation to "encrypt everything." Instead, lead architects must design a risk-based encryption strategy that aligns with corporate governance models and regulatory requirements. The first step in this strategy is comprehensive data classification. Every custom and standard field must be analysed to determine its sensitivity level and compliance classification. Encryption should be reserved exclusively for fields classified as "High Sensitivity" or "Restricted," such as personally identifiable information (PII), protected health information (PHI), or cardholder data (CHD).

Once the target fields are identified, a structured Key Management Lifecycle must be established. Under Shield Platform Encryption's split-key architecture, managing the tenant secret is a critical administrative responsibility. A tenant secret must be rotated regularly in accordance with the organisation's security policy (e.g., every 90 or 180 days). When a tenant secret is rotated, Salesforce generates a new active key which is used to encrypt all newly created or updated records. However, historically encrypted records remain encrypted using the archived tenant secret. To bring all historical data up to the latest key standard, administrators must trigger a background data sync or contact Salesforce Support to execute an active re-encryption process. Furthermore, tenant secrets must never be destroyed unless the organisation is absolutely certain that no data remains encrypted under that specific archived key; deleting or destroying a tenant secret without careful validation will result in permanent, unrecoverable data corruption for all records encrypted with that key.

A mature governance model also requires robust business continuity and disaster recovery planning. Architects must implement a secure process for exporting and backing up tenant secrets. These backups should be stored in highly secure, off-platform locations, such as an enterprise key vault or a hardware security module, accessible only by authorised security trustees under strict dual-control (four-eyes) protocols. By establishing a rigorous governance framework, automating key rotation routines, and carefully balancing the deployment of probabilistic and deterministic schemes, enterprise organisations can successfully safeguard their most sensitive assets while preserving the functional richness and performance of the Salesforce platform.