How Shield Platform Encryption Works

Important Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained certain terms to avoid any effect on customer implementations.

Note This content relates to Shield Platform Encryption. Read about implementing field-level encryption using Shield Extension in Own from Salesforce.

Encrypting files, fields, and attachments doesn’t affect your org’s storage limits.

Note This page is about Shield Platform Encryption, not Classic Encryption. What's the difference?

Your tenant secrets and root keys are always under your control. You can also supply your own key material through BYOK, EKM, or Cache-only Keys. In all cases we only use the DEKs that were provided or that we derived to encrypt data that your users put into Salesforce. We use them again to decrypt data when your authorized users need it.

• Shield Platform Encryption Terminology
  Encryption has its own specialized vocabulary. To get the most out of your Shield Platform Encryption features, it’s a good idea to familiarize yourself with key terminology.
• Components Involved in Deriving Keys
  Encryption keys are derived with a combination of hardware security modules (HSMs) and key derivation servers.
• Differences Between Classic Encryption and Shield Platform Encryption
  Shield Platform Encryption offers two paths toward encrypting data: Field-Level Encryption and Database Encryption. Both offer control over key material and encrypt a broader range of data than Classic Encryption. Each Shield Platform Encryption option offers different data coverage, key management options, and support for functionality such as filtering and sorting. Use the comparison table in this article to help you decide which option best meets your encryption requirements.
• How Key Material Is Stored
  The critical components of the Security Platform Encryption architecture—the KDF secrets, KDF salt, wrapping keys, and DEKs—are secured using a tiered structure that incorporates wrapped keys, signing, and key derivation.
• Behind the Scenes: The Shield Platform Encryption Process for Tenant Secrets
  With field-level encryption, when users submit data, the application server looks for the org-specific data encryption key (DEK) in its cache. If it isn’t there, the application server gets the encrypted tenant secret from the database and asks the regional key management server (KMS) to derive the key. The Shield Platform Encryption service then encrypts the data on the application server. If you opt out of key derivation or use either the External Key Management Service or the Cache-Only Key Service, the encryption service applies your customer-supplied data encryption key directly to your data.
• Database Encryption Process
  Salesforce's Database Encryption operates at the fragment level, encrypting and decrypting data in chunks, typically 64KB or smaller.
• Behind the Scenes: The Search Index Encryption Process
  Salesforce's search engine, powered by Apache Solr and Apache Lucene, organizes record data in a scalable, partitioned search index. Search Encryption secures org-specific search index files (.fdt, .tim, and .tip file types) using a unique AES-256 bit key. This encryption happens at the segment level, ensuring all index operations in memory are encrypted. Access to the encrypted search index and key cache is strictly via programmatic APIs.
• How Shield Platform Encryption Works in a Sandbox
  Refreshing a sandbox from a production org creates an exact copy of the production org. If Shield Platform Encryption is enabled on the production org, all encryption settings are copied to the sandbox, including tenant secrets created in production. This is true for all Shield Platform Encryption features.
• Why Bring Your Own Key?
  Shield Platform Encryption’s Bring Your Own Key (BYOK) feature gives you an extra layer of protection if there’s unauthorized access to critical data. It can also help you meet the regulatory requirements that come with handling financial, health, or personal data. After you set up your key material, use Shield Platform Encryption as you always do to encrypt data at rest in your Salesforce org.
• Why Isn't My Encrypted Data Masked?
  If the Shield Platform Encryption service isn't available, you can mask data in some types of encrypted fields. Masking data helps you troubleshoot encryption key issues, not control user access to data. If you have data that you don't want some users to see, revisit those users' field-level security settings, record access settings, and object permissions.
• Shield Platform Encryption in Hyperforce
  Shield Platform Encryption operates in parallel with volume-level encryption. By default, Hyperforce provides volume-level encryption for data at rest. Volume-level encryption protects all the data on a disk with one encryption key, which Salesforce owns and manages. With Shield Platform Encryption, you can encrypt your data in Hyperforce with unique keys that you control and manage. Also, if your org is on Hyperforce, you can use Database Encryption to encrypt the entire transactional database.
• Deploy Applications with Shield Platform Encryption Enabled
  As a developer, you can deploy applications to your org by using tools such as Salesforce Extensions for Visual Studio Code, Migration Tool, and Postman. When you deploy your application, the setting of the Encrypted Field attribute is determined by its setting in the target org.