Encryption Settings
Encryption Settings is the Salesforce Setup page where administrators configure Shield Platform Encryption for an org.
Definition
Encryption Settings is the Salesforce Setup page where administrators configure Shield Platform Encryption for an org. From this one page you generate and rotate tenant secrets, choose which standard and custom fields to encrypt, turn on encryption for files and the search index, and check how much of your data is already protected. It is the single control surface for everything Shield Platform Encryption touches.
The page appears only when the Shield Platform Encryption add-on is provisioned. Without that license, Setup still shows a short encryption status summary, but the configuration controls are absent because encryption at rest is handled by Salesforce defaults. Reaching the page requires the View Setup and Configuration permission, and changing key material or encrypting fields requires the higher-stakes Manage Encryption Keys permission.
What you actually do on the Encryption Settings page
Key Management: tenant secrets and rotation
The Key Management tab is where your key material lives. Shield Platform Encryption uses key derivation, so it never stores a finished data encryption key. Instead it combines a tenant secret that you control with a primary secret that Salesforce maintains for each release, and a key management server derives the data encryption key on demand inside a hardware security module. The derived key is held in an encrypted cache, not written to disk. On this tab you generate a new tenant secret, view the full history of active, archived, and destroyed secrets, and rotate to a fresh secret. Rotation creates a new active tenant secret so that new data uses new key material, while older data stays readable under its archived secret until you re-encrypt it. You can also switch the key source here: let Salesforce generate the secret, bring your own key (BYOK) by uploading material you generated on your own hardware, or point at an external key through Cache-Only Key Service. Salesforce recommends requiring multi-factor authentication for key management actions because destroying a secret makes data encrypted under it permanently unreadable.
Encryption Policy: choosing fields, files, and more
The Encryption Policy area is where you pick what gets encrypted. The field list shows every standard and custom field that supports Shield encryption, whether each is currently encrypted, and which scheme it uses. Selecting a checkbox and saving flags the field for encryption right away, but it does not touch existing records on its own. You choose a scheme per field. Probabilistic encryption produces different ciphertext each time the same value is encrypted, which is the strongest option but blocks filtering and exact-match operations on that field. Deterministic encryption produces the same ciphertext for the same value, which lets you filter in reports and list views and use the field in matching rules, at a small cost in randomness. The same policy area holds org-wide toggles for encrypting Salesforce Files and attachments, Chatter, and the search index. These are not per-record selections. Turning on file encryption means every new file is encrypted with the tenant secret, and existing files are picked up by a background process.
Encryption Statistics and Data Sync
Flagging a field as encrypted only encrypts data written after that point. To encrypt the records that already exist, you use the Encryption Statistics and Data Sync page. It reports how many records on each object and field are currently encrypted, so you can confirm coverage, then it lets you trigger the self-service background encryption service to bring older data in line with your current policy and key material. That background service has real limits worth planning around. Self-service synchronization can run once every 7 days, and that single allowance covers syncs you start here, the sync that runs automatically when you turn encryption off for a field, and any sync Salesforce Customer Support runs for you. Some conditions stop the self-service job from running at all, including an object holding more than 10 million records, key material that has been destroyed, or data that is already synchronized. For objects above the self-service ceiling, you log a case and Salesforce runs the encryption for you. Treat 100% on the statistics view, not the moment you checked the box, as the real finish line for a rollout.
Advanced Encryption Settings
The Advanced Encryption Settings tab carries the feature toggles that sit outside basic field encryption. This is where you enable encryption for additional data types as your edition supports them, such as event monitoring data captured by Salesforce Shield. Encrypting that monitoring data matters because login history, API events, and similar records describe user behavior and can be sensitive even when the underlying business records are already encrypted. Some capabilities are gated behind enabling deterministic encryption for the org, which you also do from this area before the deterministic scheme becomes selectable on individual fields. Because the toggles here change how broad swaths of the org behave, treat them as deliberate policy decisions rather than quick experiments. A toggle that encrypts a high-volume data type can kick off a large background job and can change what search and filtering do, so read the considerations for each option before flipping it in production.
Permissions that gate the page
Access splits across two permissions, and the gap between them is the whole security story of this page. View Setup and Configuration lets an admin open Encryption Settings and read the current state: which fields are encrypted, how far a sync has progressed, and the status of the active tenant secret. It does not allow any change to key material. Manage Encryption Keys is the powerful one. It permits generating tenant secrets, rotating them, importing BYOK material, and destroying keys. Destroying a key is irreversible and renders every record encrypted under that key unreadable, with no recovery path, so this permission belongs with a small, named set of people. Salesforce guidance is to require multi-factor authentication for these actions and to review the assignment regularly. An over-broad Manage Encryption Keys assignment is the single largest risk around Shield, far more than any individual field setting, because one mistaken key destruction has no undo.
A typical first rollout, end to end
A first-time setup runs roughly in this order. You confirm the Shield Platform Encryption license is provisioned so the page shows configuration controls. On Key Management you generate a tenant secret, which gives the org active key material to derive data encryption keys from. You then open the Encryption Policy field list and select the fields that hold regulated or sensitive data, choosing deterministic encryption for any field you still need to filter or match on, and probabilistic for the rest. If you want files protected, you turn on the file and attachment toggle in the same policy area. At this point only new data is encrypted, so you move to Encryption Statistics and Data Sync and trigger background encryption to cover existing records, watching the percentage climb to 100%. For objects over 10 million records you open a support case instead. Finally you tighten access: confirm only the right people hold Manage Encryption Keys, require multi-factor authentication for key actions, and back up your tenant secrets in a safe location so a key event is recoverable.
How to set up Shield encryption from the Encryption Settings page
Turning on Shield Platform Encryption from the Encryption Settings page follows a fixed order: create key material first, then choose what to encrypt, then sync existing data. This assumes the Shield Platform Encryption license is provisioned and you hold the Manage Encryption Keys permission.
- Open Encryption Settings
In Setup, use Quick Find to open Encryption Settings (also reachable under Platform Encryption). If the page shows only a read-only status summary, the Shield Platform Encryption license is not provisioned and you cannot configure encryption.
- Generate a tenant secret
On the Key Management tab, generate a tenant secret. This gives the org active key material that the key management server combines with the Salesforce primary secret to derive your data encryption key. Optionally switch the key source to BYOK or Cache-Only Key Service here.
- Select fields and a scheme
In the Encryption Policy field list, check the standard and custom fields to encrypt. Pick deterministic encryption for fields you must filter or match on, and probabilistic for the rest. Save to flag the fields; this encrypts only newly written data.
- Encrypt files and search if needed
Still in Encryption Policy, turn on the org-wide toggles for Salesforce Files and attachments and for the search index if your compliance scope requires them. These apply to all new content, with existing content handled by a background process.
- Sync existing data
Open Encryption Statistics and Data Sync, confirm current coverage, then trigger the self-service background encryption service to encrypt records that predate your policy. Watch each object climb to 100% encrypted before calling the rollout complete.
Per field, choose probabilistic (strongest, no filtering) or deterministic (filterable and usable in matching rules). Deterministic must be enabled for the org before it appears as a per-field choice.
Let Salesforce generate the tenant secret, bring your own key (BYOK) from your own hardware, or use Cache-Only Key Service so the key is fetched from an external store and never stored in Salesforce.
Org-wide toggles for Salesforce Files, attachments, Chatter, and the search index. Encrypting the search index hardens compliance but affects some search behaviors like wildcards and stemming.
- Flagging a field as encrypted does not encrypt existing records. Only the Data Sync background job covers data written before you turned encryption on.
- Self-service background encryption runs at most once every 7 days, and objects over 10 million records cannot use it; those require a Salesforce support case.
- Destroying a tenant secret is irreversible and makes all data encrypted under it permanently unreadable. Back up tenant secrets and limit who holds Manage Encryption Keys.
- Probabilistic encryption blocks filtering and exact-match on that field. Choose the scheme before a large sync, because changing it later means re-encrypting the data.
Prefer this walkthrough as its own page? How to Encryption Settings in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Encryption Settings.
Hands-on resources to go deeper on Encryption Settings.
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 is the Encryption Settings page in Salesforce Setup used to manage?
Q2. After enabling encryption on a high-volume field, where do you confirm existing records are fully protected?
Q3. Which permission should be tightly restricted on the Encryption Settings page?
Discussion
Loading discussion…