Data Encryption
Data Encryption in Salesforce is the umbrella for the platform features that encrypt data at rest and in transit: Shield Platform Encryption (admin-configurable field-level and file-level encryption with customer-managed keys), Classic Encryption (legacy text field encryption), Transport Layer Security (TLS) for all data in transit between client and server, and at-rest encryption Salesforce applies by default at the storage layer.
Definition
Data Encryption in Salesforce is the umbrella for the platform features that encrypt data at rest and in transit: Shield Platform Encryption (admin-configurable field-level and file-level encryption with customer-managed keys), Classic Encryption (legacy text field encryption), Transport Layer Security (TLS) for all data in transit between client and server, and at-rest encryption Salesforce applies by default at the storage layer. Together they form the encryption posture every regulated org needs to understand.
Data Encryption matters because regulated industries (financial services, healthcare, government) commonly require encryption with customer-managed keys for sensitive fields and files. Without it, the org relies on Salesforce-managed at-rest encryption which is invisible to the customer and not configurable per-field. Shield Platform Encryption is the heavyweight option that gives the customer encryption-key control; Classic Encryption is the lightweight legacy option for one or two highly-sensitive text fields. Most regulated orgs run a combination based on data sensitivity and compliance requirements.
Why Data Encryption is a stack of products, not a single feature
Layer 1: TLS in transit (always on)
Every connection to Salesforce (browser, mobile, API) uses TLS 1.2+ encryption in transit by default. The encryption protects data from network interception between the client and Salesforce servers. TLS is non-optional; admins do not configure it. The relevant admin choice is which TLS versions and cipher suites the org permits inbound (TLS Configuration settings in Setup); modern orgs restrict to TLS 1.2 and 1.3, blocking older versions to reduce attack surface.
Layer 2: At-rest encryption (always on)
Salesforce encrypts all data at rest in its storage layer using Salesforce-managed keys. The encryption is invisible to the customer; admins do not configure or see the keys. The default at-rest encryption satisfies many compliance requirements but does not provide customer key control. For requirements that demand customer-held keys (HIPAA HMK, certain financial services regulations, PCI DSS depending on interpretation), Shield Platform Encryption is the next layer up.
Layer 3: Classic Encryption (legacy, narrow scope)
Classic Encryption is the older Salesforce field encryption product. It encrypts a single text field type (Encrypted Text) and only that type. Admins create the field, mark it Encrypted at creation, the data stores encrypted at rest with platform-managed keys. The feature is narrow (one field type) and limited (search and reporting on encrypted values are constrained). Most orgs that need encryption beyond the default at-rest layer skip Classic Encryption for Shield Platform Encryption.
Layer 4: Shield Platform Encryption (customer-controlled)
Shield Platform Encryption is the modern, comprehensive encryption product. It encrypts standard and custom fields, files and attachments, and search index data with customer-managed encryption keys (Bring Your Own Key or Customer-Managed Keys via the Shield Key Management Service). The customer holds and rotates the keys; Salesforce processes data through the keys without holding the key material. Shield is a licensed add-on; most regulated orgs that require customer-held keys end up on Shield.
Trade-offs: encryption vs functionality
Encrypted fields have functional limitations. Some report and dashboard operations on encrypted fields are restricted. SOQL queries that filter on encrypted fields cannot use indexes the same way (slower at scale). Formula fields cannot reference encrypted source fields. List view filters on encrypted fields are limited. The trade-offs are real; encrypting every field "for safety" produces a slow, hard-to-report org. The discipline: encrypt only fields that genuinely require it per compliance policy, accept the functional limitations on those, leave the rest unencrypted.
Key management and rotation
Shield Platform Encryption supports key rotation: the customer rotates the encryption key periodically (annually is typical for HIPAA-grade compliance). Rotation re-encrypts data with the new key over time as records are accessed or via background re-encryption jobs. Old keys remain available for decryption of historical records until all data is migrated; the customer eventually retires old keys. Key rotation is operationally non-trivial; plan as a multi-week project including testing and verification.
Compliance positioning and the auditor question
When auditors ask about encryption, they want to know: are sensitive fields encrypted at rest, who holds the encryption keys, what is the rotation schedule, how is access to keys audited. The default at-rest encryption answers the first question but not the others. Shield Platform Encryption answers all four. Compliance positioning for regulated orgs almost always includes Shield for at least the most sensitive fields (PII, PHI, financial account numbers). The licensing cost is real but the audit pathway is significantly cleaner with Shield than without.
How to design the right Data Encryption stack for your org
The pattern: classify fields by sensitivity (Data Classification feature), encrypt the high-sensitivity fields with Shield, accept default at-rest encryption for everything else, document the encryption posture for auditors. The cost is real (Shield license, key management work, functional trade-offs); the compliance benefit is the audit-defensible answer.
- Classify fields by sensitivity through Data Classification
Use the Data Classification feature to tag each field with Sensitivity Level. The classification drives encryption decisions; without it, encryption decisions are guesses.
- Identify fields requiring customer-managed keys
Confidential and Restricted-classified fields plus regulatory scope (PII, PHI, payment data). The list is the Shield encryption target.
- License Shield Platform Encryption
Shield is a separate SKU. Coordinate procurement; rollout is typically 4 to 8 weeks from purchase to encrypted-in-production.
- Configure Shield in sandbox first
Setup, Platform Encryption, generate or import keys, encrypt the target fields. Test functional impact (reports, list views, formulas).
- Plan the production rollout including re-encryption time
Encrypting a field that already has data requires the platform to re-encrypt historical records; this can take hours to days depending on volume.
- Document the encryption posture
Which fields are Shield-encrypted, who holds the keys, what is the rotation schedule. The document is the compliance evidence.
- Plan annual key rotation
Rotate keys per compliance schedule (annually for most HIPAA-grade contexts). Coordinate; rotation is multi-week.
TLS in transit, default at-rest, Classic Encryption, Shield Platform Encryption. Pick the layer matching the requirement.
Salesforce-managed (default at-rest) or customer-managed (Shield BYOK/CMK). Compliance drives the choice.
Which specific fields and files are Shield-encrypted. Limit to compliance-required ones to minimize functional impact.
Annually for HIPAA-grade, less frequent for lighter compliance. Coordinate with the key management team.
Each encrypted field accepts some report, formula, or filter limitations. Document the accepted trade-offs.
- Encrypting every field produces slow, hard-to-report behavior. Limit Shield encryption to compliance-required fields.
- Formula fields cannot reference Shield-encrypted source fields. Pre-existing formulas break when their source becomes encrypted; audit before encrypting.
- Key rotation is a multi-week operational project. Plan as a project with testing, not as a one-click change.
- Classic Encryption and Shield Platform Encryption are different products. Most modern orgs need Shield; Classic is legacy.
- Default at-rest encryption satisfies basic encryption requirements but does not provide customer key control. Regulated contexts usually need Shield.
Trust & references
Cross-checked against the following references.
- Shield Platform Encryption referenceSalesforce
- Salesforce ShieldSalesforce
Straight from the source - Salesforce's reference material on Data Encryption.
- Shield Platform EncryptionSalesforce Help
- Classic EncryptionSalesforce Help
- Salesforce Security OverviewSalesforce Help
Hands-on resources to go deeper on Data Encryption.
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's the difference between Classic Encryption and Platform Encryption?
Q2. What encrypts data in transit?
Q3. Why does encryption planning matter?
Discussion
Loading discussion…