Encrypted Data at Rest
Encrypted Data at Rest is the Salesforce platform capability that stores stored data on disk in an encrypted form, distinguishing it from data in transit (which uses TLS) and data in memory (which is unencrypted while being processed).
Definition
Encrypted Data at Rest is the Salesforce platform capability that stores stored data on disk in an encrypted form, distinguishing it from data in transit (which uses TLS) and data in memory (which is unencrypted while being processed). The platform encrypts all customer data at rest by default using AES-256, with the encryption keys managed by Salesforce as part of the trusted-platform model. Customers who need additional control over the keys can layer Shield Platform Encryption, Bring Your Own Key (BYOK), or Cache-Only Key Service on top of the default encryption.
The distinction matters for compliance audits. Most regulatory frameworks (HIPAA, PCI DSS, GDPR, SOC 2) treat at-rest encryption as a baseline requirement, and Salesforce satisfies the baseline through its built-in encryption without any customer action. Customers seeking stronger guarantees, like the ability to revoke access to their data by destroying their own key, need the Shield-tier options that provide customer-managed key material.
How Salesforce encrypts your data at rest
The default encryption layer
Every Salesforce production org encrypts customer data at rest with AES-256, using Salesforce-managed keys stored in tenant-isolated key management systems. This applies to the production database, file storage, and backup archives. The encryption is transparent: applications, queries, and reports work identically regardless of encryption status. The keys rotate on a schedule managed by Salesforce; customers cannot see or control them. The encryption is included with the base license and requires no configuration.
Shield Platform Encryption (deterministic and probabilistic)
Shield Platform Encryption adds a customer-controlled layer on top of the platform default. It encrypts data with keys generated and managed under customer policy, with two scheme options. Probabilistic encryption uses a random IV per record, providing stronger security but breaking SOQL filters and sorting on encrypted fields. Deterministic encryption uses a fixed IV so the same plaintext always produces the same ciphertext, allowing equality matches in SOQL but providing weaker security. Choose based on whether the field needs to be searchable.
Bring Your Own Key (BYOK)
BYOK lets a customer generate the tenant secret outside Salesforce and upload it, replacing the Salesforce-generated key material. The customer can destroy the key material at any time, which renders all data encrypted with that key permanently inaccessible (including to Salesforce). This is the strongest customer-control option: a compliance auditor can see proof that Salesforce cannot decrypt the data without the customer key.
Cache-Only Key Service
Cache-Only Key Service goes further than BYOK by keeping the key material outside Salesforce entirely. The customer hosts the key in their own key management system; Salesforce fetches the key on demand to decrypt requested data, holds it in memory briefly, and discards it. The key never persists on Salesforce infrastructure. This satisfies the most restrictive compliance requirements (some defense and regulated industries) but adds latency to every encrypted-field operation.
Fields, files, and search
Shield Platform Encryption applies at three levels: standard and custom fields on objects, file content (ContentVersion, Attachment), and search index entries. Field-level encryption is the most common, with the standard fields you can encrypt limited to a published list. File encryption applies to all files in your org once enabled. Search index encryption is needed if compliance requires the indexes themselves be encrypted, not just the source data.
Functional limitations
Encrypted fields lose some functionality. Probabilistic encryption blocks SOQL filters, sorts, GROUP BY, and most formula references on encrypted fields. Deterministic encryption restores equality match (filter by Email = exact value) but still blocks LIKE wildcards. Field history tracking is supported but stores encrypted values. Workflow rules and validation rules cannot directly compare encrypted field values without specific platform support. Audit which features your business logic depends on before encrypting a high-traffic field.
Audit and key rotation
Customers using Shield receive audit logs showing key usage, key rotation events, and access patterns. Keys can be rotated on a customer schedule; rotation is non-disruptive because old keys remain available to decrypt previously encrypted data while new writes use the new key. Plan key rotation to align with compliance requirements (annual rotation is common). The platform stores the key generation date and rotation history for audit.
Roll out Shield Platform Encryption
Encrypted data at rest is on by default. Configuration only applies when you choose to layer Shield Platform Encryption, BYOK, or Cache-Only Keys on top. The steps below cover that customer-control rollout.
- Confirm Shield license
Check that your org has the Shield Platform Encryption license added. Without the license, Encryption Settings shows only the default platform encryption status.
- Identify fields and files to encrypt
Work with security and business teams to list which fields are sensitive enough to require Shield. PII, financial data, and protected health information are typical candidates.
- Audit downstream impact
For each candidate field, check if SOQL queries filter or sort by it, if validation rules reference it, and if reports group by it. Encryption may break these patterns; refactor before encrypting.
- Generate the tenant secret
Setup > Encryption Settings > Key Management > Generate Tenant Secret. The platform creates a new key under Salesforce-managed mode; for BYOK, upload your own key material instead.
- Enable field-level encryption
For each target field, click Edit in Encryption Settings and check Encrypted. Choose Probabilistic or Deterministic per field based on the query patterns you identified.
- Wait for encryption to apply
The platform encrypts existing data asynchronously. For large orgs this takes hours; query the status from Encryption Statistics to confirm completion before declaring rollout complete.
- Plan key rotation cadence
Add a quarterly or annual key rotation to your security calendar. Rotation is non-disruptive but produces audit log entries that compliance teams expect to see.
Default. Salesforce generates and rotates keys. No customer key access. Baseline compliance.
Customer generates and uploads key material. Customer can destroy the key to revoke all access permanently.
Customer hosts key in external KMS. Salesforce fetches on demand and discards. Strongest control; adds latency.
Per-record random IV. Strongest security; blocks SOQL filters, sorts, GROUP BY on the field.
Fixed IV per field. Allows exact-match SOQL filters; blocks LIKE wildcards and full-text search.
- Probabilistic encryption breaks any SOQL query that filters, sorts, or groups by the encrypted field. Audit query patterns before encrypting; pivots like dashboards may fail.
- BYOK key destruction is irreversible. Destroying the key permanently removes access to all encrypted data, including by Salesforce. Plan key custody and destruction process with extreme care.
- Not every standard field is supported by Shield. The supported field list is published and updated each release; confirm your target fields are on it before promising encryption.
- Cache-Only Keys add latency to every encrypted-field operation. Heavy reports filtering encrypted fields can run noticeably slower; benchmark before production rollout.
- Validation rules and Flow logic that compare encrypted field values may stop working. The platform supports limited operations; complex business logic referencing encrypted fields needs review.
Trust & references
Straight from the source - Salesforce's reference material on Encrypted Data at Rest.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does Encrypted Data at Rest protect?
Q2. What Salesforce feature provides at-rest encryption?
Q3. Why does compliance often require at-rest encryption?
Discussion
Loading discussion…