Onboard Database Encryption
Database Encryption will give you sufficient encryption coverage for your org's data in Salesforce's transactional database.
Required Editions
| Available in both Lightning Experience and Salesforce Classic (not available in all orgs). |
| Available in: Enterprise, Performance, and Unlimited Editions using Hyperforce. |
If you work with large files, enable Files and Attachments. And if you are concerned with searches of sensitive data, enable Search Index encryption.
Once you have enabled Database Encryption, it remains in place. There is no option to turn it off at the present time.
Also, you cannot synchronize existing data with the new active tenant secret. While key rotation is supported, Salesforce automatically synchronizes data to the latest key over time. There is no self-service sync option for Database Encryption.
Database Encryption encrypts the entire transactional database. This includes all fields, and any small files that are contained within the database.
Prepare for Database Encryption
To prepare for Database Encryption we recommend these steps:
- Perform a thorough security review to assess your current encryption status and plan your strategy.
- Read about Database Encryption, how it works, and how to set it up.
- Try the feature in a fresh development org.
- Plan to test Database Encryption in a sandbox thoroughly before migrating your production org.
First Use of Database Encryption
When you first enable Database Encryption, Salesforce creates your tenant secret automatically. To ensure the new secret is properly backed up within the Salesforce Key Management Server (KMS), we wait 24 hours before using it. During the first 24 hours, a Salesforce-owned tenant secret unique to your org is used for encrypting data. After 24 hours, the Salesforce-owned tenant secret is archived, and your new tenant secret is used.
Unlike for Field Level Encryption, synchronization is not available for Database Encryption. As users edit existing data, it is reorganized into new immutable encrypted fragments, and encrypted using the current tenant secret. This process is organic and gradual.
Useful Shield Platform Encryption Additions
While Database Encryption enables the widest coverage for standard and custom fields, other Shield Platform Encryption features can widen your protection even further. Check out the section What You Can Encrypt in Help. Your total protection profile can be improved if you also encrypt Files and Attachments, Search Indexes, and Event Bus Data.
You may have standard or custom fields that require compliance documentation. If your compliance policies require traceable encryption for one or more fields, you can use Field Level Encryption (FLE) to encrypt them. Another reason to use FLE is it provides advanced key management. Both External Key management (EKM) and Bring Your Own Key (BYOK) give you more control over your encryption key material.
Overlapping Encryption
Some encryption features, like FLE and Chatter, overlap the encryption provided by Database Encryption. In these cases, the feature encryption happens first using its tenant secret, and then database encryption is applied using the Database Encryption tenant secret. Users do not notice the difference when they access data encrypted twice in this way.
- Onboard Database Encryption after Enabling Field-Level Encryption
If you have been using FLE, and have decided to take advantage of the benefits of Database Encryption, decide whether you still need to use FLE. Database Encryption will cover all standard and custom fields that you can configure with FLE without any issues with filtering and sorting. - Database Encryption Tradeoffs
Database Encryption provides you with a way to secure your entire transactional database. Even so, there are some compromises to accept if you use it.
