Salesforce Shield Platform Encryption

1 What is Shield Platform Encryption?

According to Salesforce official documentation, Shield Platform Encryption is part of the Salesforce Shield suite - a set of security tools that helps administrators and developers build extra levels of trust, compliance, and governance right into business-critical applications.

The Four Components of Salesforce Shield

Salesforce Shield consists of four main components, each addressing different security needs:

• Platform Encryption: Encrypts data at rest (when stored in Salesforce data centers) using 256-bit AES encryption
• Event Monitoring: Tracks user activity and data access patterns for security analysis
• Field Audit Trail: Retains field history data for up to 10 years for compliance requirements, with up to 200 tracked fields per object since Spring '26
• Data Detect: Automatically scans your database to identify sensitive data like credit card numbers, SSNs, and emails. Summer '26 added scheduled scans and the ability to scan encrypted data; Data Detect now runs from the Shield app rather than the legacy managed package

Two Encryption Capabilities: Field-Level Encryption and Database Encryption

Shield Platform Encryption now offers two complementary capabilities:

• Field-Level Encryption (FLE): The official name for the selective field encryption this guide has always covered - you choose which standard and custom fields, files, attachments, and Chatter data to encrypt with AES-256 (CBC mode)
• Database Encryption (GA Spring '26): Encrypts the entire database - all standard and custom fields, metadata, and Apex - with AES-256 GCM, and supports sort, filter, and query operations without the functional tradeoffs of field-level encryption

Most of this guide focuses on Field-Level Encryption, since that's where field selection, encryption schemes, and query considerations come into play. Where behavior differs, Database Encryption is called out explicitly.

Why Platform Encryption Matters

Shield Platform Encryption helps organizations meet legal and contractual obligations while ensuring sensitive customer data is encrypted according to industry best practices. Shield is compliant with or exceeds requirements for GDPR, HIPAA, and SOX standards.

Unlike traditional encryption that might break application functionality, Shield Platform Encryption maintains critical features such as:

• Search functionality (with deterministic encryption)
• Flows and validation rules
• Formula fields
• API access for authorized users

2 Classic Encryption vs Shield Platform Encryption

Understanding the differences between Classic Encryption and Shield Platform Encryption is crucial for making the right security decision. According to the Salesforce Security Implementation Guide, these two approaches serve different purposes and have distinct capabilities.

When to Use Classic Encryption

Classic Encryption is appropriate for basic security needs where:

• You need to mask sensitive data (like SSNs or credit card numbers) from internal users
• You don't have regulatory compliance requirements
• Budget constraints prevent purchasing Shield
• You only need to protect a small number of custom text fields

When to Use Shield Platform Encryption

Shield Platform Encryption is the superior choice when:

• You need to meet compliance requirements (HIPAA, GDPR, SOX, PCI-DSS)
• You require encryption of standard fields (Account Name, Contact Email, etc.)
• You need to encrypt files and attachments
• You want control over your encryption keys (BYOK)
• You need encryption that works with Flows, formulas, and validation rules

The Comparison Is Now Three-Way: Database Encryption (GA Spring '26)

With Database Encryption generally available since Spring '26, the encryption decision is no longer just Classic vs Shield - it's a three-way comparison between Classic Encryption, Field-Level Encryption, and Database Encryption:

3 How Shield Platform Encryption Works

Shield Platform Encryption uses a sophisticated key derivation process to protect your data. According to the Shield Platform Encryption Architecture documentation, the encryption relies on a combination of secrets that work together to secure your data.

Key Architecture

Salesforce combines your tenant secret with the KDF seed (formerly master secret) using PBKDF2 on hardware security modules (HSMs) to derive the data encryption keys. Derived keys are never persisted - they're held in a secure, encrypted cache and re-derived when needed.

Encryption Schemes: Probabilistic vs Deterministic

Field-Level Encryption offers two encryption schemes, each with different security and functionality trade-offs (Database Encryption doesn't need schemes - it has no query tradeoffs):

The Encryption Process

Here's how data flows through Shield Platform Encryption when a user saves sensitive information:

4 Which Fields Can Be Encrypted?

One of the most common questions about Shield Platform Encryption is: "Can I choose which fields to encrypt?" The answer is yes - you have granular control over field encryption. According to the Salesforce Help documentation on standard fields, you can encrypt specific standard and custom fields based on your security requirements.

Supported Custom Field Types

The following custom field types can be encrypted:

• Email
• Phone
• Text
• Text Area
• Text Area (Long)
• Text Area (Rich)
• Date
• Date/Time
• URL

Supported Standard Fields by Object

Files, Attachments, and Chatter

Beyond field-level encryption, Shield supports:

5 Setup & Implementation Guide

Implementing Shield Platform Encryption requires careful planning and execution. According to Salesforce Trailhead's Shield Platform Encryption module, the implementation process involves several critical steps.

Pre-Implementation Checklist

Complete these critical steps before enabling Shield Platform Encryption in your org:

Step-by-Step Setup Process

Assign Encryption Permissions

According to Salesforce Trailhead, Shield Platform Encryption requires only two system permissions:

6 BYOK & Key Management

For organizations requiring complete control over their encryption keys, Shield Platform Encryption offers BYOK (Bring Your Own Key) capabilities. According to the Salesforce BYOK documentation, you can upload your own key material or use the Cache-Only Key Service.

Key Management Options

BYOK coverage has expanded well beyond field encryption: it now spans Field-Level Encryption, Database Encryption, Event Bus, and Search Index. Root-key BYOK is also available for Data 360 and Backup & Recover Next, giving you customer-controlled keys across the wider Salesforce estate.

Setting Up BYOK (Bring Your Own Key)

To enable BYOK, follow these steps based on Salesforce's BYOK setup documentation:

Key Rotation Best Practices

According to Salesforce Trailhead's encryption deployment guidance, disciplined key management is essential:

• Rotation Frequency: Align rotation with your organization's security policies. Salesforce enforces rotation caps: once per 24 hours in production (once per 4 hours in sandboxes) for probabilistic tenant secrets, once per 7 days for deterministic tenant secrets, and once every 3 months for the database tenant secret
• Backup Keys: Securely export and back up every old tenant secret before rotation
• Key Archival: Archived keys are needed to decrypt historical data
• Key Recovery: Destroyed keys can be re-imported from your exported backup, restoring access to data encrypted with them
• Automatic Re-encryption: Newly created and edited data uses the most recent key automatically
• Key Limit: You can have up to 50 active and archived tenant secrets of each type - the limit applies per type, and database tenant secrets don't count against it

7 Limitations & Governor Limits

Understanding the limitations of Shield Platform Encryption is crucial for successful implementation. According to the Salesforce documentation on tradeoffs and limitations and the general considerations guide, there are several important constraints to consider.

SOQL and SOSL Limitations

Fields encrypted with Field-Level Encryption have significant query restrictions - these limits apply to FLE only; Database Encryption filters and sorts freely with no query tradeoffs. For deterministic encryption specifics, see the deterministic encryption considerations:

// This SOQL will FAIL if Account.Name is encrypted with probabilistic scheme
Account[] accts = [SELECT Id, Name FROM Account WHERE Name = 'Acme Corp'];

// This will work with deterministic encryption
Account[] accts = [SELECT Id, Name FROM Account WHERE Name = 'Acme Corp'];

// This will NEVER work (ORDER BY on encrypted field)
Account[] accts = [SELECT Id, Name FROM Account ORDER BY Name];

Field Character Limits

According to the field limits documentation, encrypted content is often longer than its plaintext, which can impose stricter limits:

• Test field limits in longer fields like Address and Subject
• Non-ASCII values (Chinese, Japanese, Korean) may have additional length restrictions
• Character limits on encrypted fields are often lower than standard field lengths

Feature Restrictions

AppExchange Compatibility

Not all AppExchange applications are Shield-compatible:

Storage Impact

Good news: Encrypting files, fields, and attachments does NOT affect your org's storage limits. The encrypted ciphertext storage is handled transparently.

8 Best Practices & Lessons Learned

Drawing from Salesforce's official best practices and real-world implementation experience, here are the key lessons learned.

Strategic Planning

• Define Your Threat Model: Walk through a formal threat-modeling exercise to identify which threats are most likely to affect your organization
• Encrypt Strategically: Don't encrypt everything - focus on PII, financial records, and critical business data
• Start with Data Classification: Use Data Detect first to identify sensitive data before deciding what to encrypt

Implementation Lessons

Security vs Functionality Balance

Understanding when Shield is the right solution:

Key Management Lessons

• Limit Key Permissions: Create a dedicated "Security Admin" profile with very limited users who can manage encryption keys
• Document Key Rotation: Maintain a log of all key rotations with dates and reasons
• Backup Before Rotation: Always export and securely store the current tenant secret before generating a new one
• Test Key Recovery: Periodically verify you can restore encrypted data using archived keys

9 Dos and Don'ts

10 Pricing & Licensing

Salesforce Shield pricing is unique - it's based on a percentage of your total Salesforce spend rather than per-user pricing. According to Salesforce's official Shield pricing page, the cost structure works as follows:

Pricing Structure

Cost Example

Here's how the percentages from Salesforce's official pricing page translate into real numbers:

Edition Availability

11 Common Problems & Solutions

Based on Salesforce's officially documented deployment behaviors and experiences commonly reported by deployment practitioners, here are the most frequently encountered Shield Platform Encryption problems and their solutions.

Problem 1: Deployment Succeeds but Encryption Fails

Root Cause: As commonly reported by deployment practitioners, Salesforce executes the encryption compliance check asynchronously to the Metadata API deployment. The API reports success before the encryption compatibility check completes.

Solution:

• Monitor your email for post-deployment encryption failure notifications
• Review the failure details in the email and address the specific compatibility issues
• Redeploy the CustomObject field after resolving conflicts
• Use Encryption Statistics page to verify encryption was applied

Problem 2: SOQL Tests Fail with Deterministic Encryption

Root Cause: Deployment practitioners commonly report that Salesforce doesn't encrypt the field immediately upon Metadata API deployment. The encryption is applied later after compatibility checks. Meanwhile, your Apex tests run against non-encrypted fields, and queries on encrypted fields fail.

Solution:

Problem 3: Process Builder Conflicts

Root Cause: You cannot use encrypted fields in Process Builder Update Records filters. Even inactive versions in the target org cause conflicts.

Solution:

• Go to the target org and delete all inactive Process Builder versions that reference the to-be-encrypted field in Update Records filters
• Deploy a new version of Process Builder that doesn't use the encrypted field in filters
• Ensure the new version is active before deploying the encrypted field
• Migrate to Flow: Process Builder is retiring, so treat any encryption conflict as the trigger to move that automation to Flow, which has better encryption compatibility

Problem 4: Third-Party App Incompatibility

Root Cause: Not all AppExchange applications are Shield-compatible. Some apps directly query encrypted fields in ways that break with encryption enabled.

Solution:

• Before enabling Shield, audit all installed packages
• Contact each vendor to confirm Shield compatibility
• Request Shield-ready updates from vendors if needed
• Consider alternative apps if vendors cannot support Shield
• Test thoroughly in sandbox with all packages before production

Problem 5: System Propagation Delays

Root Cause: Deployment practitioners commonly report propagation delays in the architecture behind platform encryption when toggling encryption on and off.

Solution:

• Wait several minutes after making encryption changes before testing
• Use the Encryption Statistics page to verify actual encryption status
• Don't rapidly toggle encryption on and off during testing
• Clear browser cache if UI shows stale information

Problem 6: SOQL WHERE Clause Violations

// This code FAILS with probabilistic encryption
List<Contact> contacts = [SELECT Id, Email FROM Contact WHERE Email = :searchEmail];

// Workaround: Use SOSL instead for search scenarios
List<List<SObject>> results = [FIND :searchEmail IN ALL FIELDS RETURNING Contact(Id, Email)];

// Alternative: Use deterministic encryption (if search is required)
// Configure field for deterministic encryption in Encryption Policy

Solution:

• Audit all Apex code for SOQL queries using encrypted fields in WHERE clauses
• Use SOSL FIND statements as a workaround for search scenarios
• Switch to deterministic encryption for fields that must be searchable
• Refactor code to filter results in Apex after querying without WHERE filters

Problem 7: Existing Data Not Encrypted

Root Cause: Shield Platform Encryption only encrypts newly created and modified data. Existing data must be explicitly synchronized.

Solution:

• Use the Encryption Statistics page to sync existing data with your policy
• Use the self-service Background Encryption from the Encryption Statistics page (once every 7 days)
• Programmatically touch records to trigger re-encryption (update with same values)
• Plan for data synchronization during implementation, not as an afterthought

Problem 8: Performance Degradation

Root Cause: Encryption/decryption operations add processing overhead, especially for frequently accessed fields or large data volumes.

Solution:

• Only encrypt fields that truly require protection (PII, financial data, compliance-mandated)
• Avoid encrypting fields used in high-frequency operations
• Use selective field encryption instead of encrypting everything
• Monitor performance before and after enabling encryption
• Consider whether deterministic vs probabilistic impacts your specific use cases

? Frequently Asked Questions

12 Abbreviations & Glossary

Related Reading

Continue your Salesforce security and development learning journey with these related guides from my blog:

• Salesforce Security: The Ultimate Guide to Preventing Hacks and Data Breaches - Comprehensive 15-section guide covering MFA, session management, permission controls, code security, and protection against browser extension vulnerabilities
• 7 Ways to Secure Experience Cloud - Security best practices for Experience Cloud including OWD settings, roles, sharing rules, and MFA implementation
• Apex Design Patterns - Learn design patterns in Apex for building maintainable and scalable Salesforce applications
• 10 Differences Between Salesforce Solution and Technical Architect - Understanding architect roles and responsibilities for Salesforce implementations