Encryption Key
An Encryption Key in Salesforce is the cryptographic material used to encrypt and decrypt data stored at rest.
Definition
An Encryption Key in Salesforce is the cryptographic material used to encrypt and decrypt data stored at rest. The platform uses a two-tier key hierarchy: tenant secrets (the customer-specific master keys) and data encryption keys (the per-record or per-field keys actually applied to ciphertext). Tenant secrets are generated under one of three management models depending on the customer license: Salesforce-managed (the default included with every org), Customer-generated through Bring Your Own Key (BYOK), or Customer-hosted through the Cache-Only Key Service.
Keys rotate on a customer-defined schedule with no service interruption: existing data remains decryptable with prior keys while new writes use the current key. The platform stores key generation dates, rotation events, and usage in audit logs available to compliance teams. Destroying a customer-managed key permanently invalidates the data encrypted with it, including for Salesforce itself, which is the strongest guarantee of customer control over data access.
How Salesforce manages encryption keys
The tenant secret and data key hierarchy
The platform separates a long-lived tenant secret from short-lived data encryption keys. The tenant secret is the customer-level master key; data keys are derived per record or per file using the tenant secret plus additional context. This separation means rotating the tenant secret invalidates all derived data keys at once, which is what makes rotation feasible at scale. Without the hierarchy, every record would need to be re-encrypted on key rotation.
Salesforce-Managed Keys (default)
Every Salesforce org has a default Salesforce-managed key. The customer cannot view or download the key material, and rotation is handled by the platform on a Salesforce-determined schedule. This satisfies most regulatory baselines (HIPAA, SOC 2, GDPR) without configuration. Customers who only need the default tier do not configure keys; the platform handles everything.
Bring Your Own Key (BYOK)
BYOK lets the customer generate the tenant secret outside Salesforce and upload it. The customer holds the original key material in their own key management system; Salesforce holds only the working copy needed to derive data keys. Destroying the customer copy is the path to revoking all access to encrypted data. BYOK is the most common Shield key model because it balances control (customer can destroy) with operational simplicity (no real-time external dependency).
Cache-Only Key Service
Cache-Only goes further than BYOK by never persisting the key on Salesforce infrastructure. The key lives in the customer external KMS; Salesforce fetches it on demand to decrypt requested data, holds it in cache briefly, then discards. This satisfies the strictest compliance regimes (some defense, intelligence, and regulated industries) but adds latency because every encrypted-field operation potentially requires a remote KMS round-trip. Network reliability between Salesforce and the customer KMS becomes a production concern.
Key rotation without downtime
Rotating a tenant secret is non-disruptive. The platform generates a new tenant secret and starts using it for new writes, while keeping previous secrets available to decrypt older data. Over time, background processes can re-encrypt older data under the new key (with the Mass Encryption job) so that retiring the old key becomes possible. Most orgs rotate annually; some compliance requirements call for quarterly. Plan rotation as a recurring calendar item, not a one-off task.
Key destruction and the irreversible boundary
Destroying a BYOK or Cache-Only key permanently removes access to all data encrypted with it. Salesforce cannot recover the data; the customer cannot recover it; backup tapes are useless. This is the feature for "the auditor wants proof we can revoke our own data" scenarios. It is also a hazard: an accidental key destruction is a catastrophic data loss event. Key destruction processes must include multi-party approval and timed delays.
Audit logs and compliance
The Encryption Statistics and Setup Audit Trail surface every key operation: generation, rotation, archive, destroy, and access. Compliance auditors look for evidence that keys are rotated on schedule and that destruction events are properly authorized. Configure log exports to your SIEM if compliance requires immutable storage of key events. The logs are kept for a fixed retention window; archive them externally for longer audit horizons.
Set up and rotate encryption keys
Managing encryption keys is the work of setting up tenant secrets, choosing the right key model, scheduling rotation, and planning destruction. The steps below cover the full Shield key lifecycle.
- Confirm Shield license
Check that Shield Platform Encryption is licensed on the org. Without it, key management is limited to viewing the Salesforce-managed key status.
- Choose the key model
Decide between Salesforce-Managed, BYOK, and Cache-Only. The choice depends on compliance requirements, operational complexity tolerance, and whether you need customer-side key destruction.
- Generate the tenant secret
Setup > Encryption Settings > Key Management > Generate Tenant Secret. For BYOK, prepare your externally generated key material first; for Cache-Only, configure the external KMS endpoint.
- Confirm secret activation
The platform takes a few minutes to propagate a new tenant secret. Confirm the secret is Active before proceeding to encrypt fields.
- Plan rotation cadence
Decide rotation frequency: quarterly (strict compliance), annually (common), or longer. Add to security calendar with two-week advance notice for each rotation.
- Run Mass Encryption after rotation
After each rotation, run Mass Encryption Statistics > Encrypt Unencrypted Data to re-encrypt older records under the new key. This is needed before retiring the old key.
- Document destruction process
Write down the multi-party approval and delay process required to destroy a key. Test the process annually in a sandbox to confirm it works.
Default mode. Salesforce generates and rotates keys. No customer key visibility.
Customer generates key material externally and uploads. Customer can destroy by deleting the master copy.
Customer hosts key in their own KMS. Salesforce fetches on demand. Strongest customer control.
How often the tenant secret is rotated. Annual is common; quarterly for strict compliance.
Marks a tenant secret as destroyed. Irreversible. Plan multi-party approval before executing.
- Key destruction is irreversible and unrecoverable. Salesforce cannot recover; the customer cannot recover; backups are useless. Build approval workflows that prevent accidental destruction.
- Cache-Only Key Service makes decryption depend on the customer KMS availability. KMS downtime halts decryption across the org; plan KMS high availability before going live.
- Key rotation is non-disruptive only if Mass Encryption is run afterward to re-encrypt older data. Without it, old keys must remain available, defeating the rotation goal.
- Not every standard field can be encrypted. Confirm field-level Shield support before promising encryption for a specific field; the supported list is published per release.
- Audit logs for key operations are kept for a fixed retention window. Export to an external SIEM if compliance requires longer retention than the platform default.
Trust & references
Straight from the source - Salesforce's reference material on Encryption Key.
- Fundamental Concepts in Shield Platform EncryptionSalesforce Help
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 an Encryption Key?
Q2. What does BYOK mean?
Q3. What's the most security-sensitive key operation?
Discussion
Loading discussion…