Data Encryption Keys
Data Encryption Keys in Salesforce are the cryptographic key material that Shield Platform Encryption uses to encrypt and decrypt the org's protected fields, files, and search index data.
Definition
Data Encryption Keys in Salesforce are the cryptographic key material that Shield Platform Encryption uses to encrypt and decrypt the org's protected fields, files, and search index data. Each key is a secret value the platform holds in escrow (Salesforce-managed keys), the customer holds entirely (Bring Your Own Key, BYOK), or the customer manages through Salesforce's Cache-Only Key Service (the key never touches Salesforce storage; the platform fetches it from the customer's key server per request). The key management approach defines the compliance posture; the keys themselves are the cryptographic primitive that makes the encryption real.
Data Encryption Keys exist because Shield Platform Encryption is built on customer-managed cryptography. The customer choosing BYOK supplies the master key material; the platform derives per-tenant data encryption keys from it. The customer choosing Cache-Only Key Service keeps the key material entirely outside Salesforce. The choice of key management approach is the most consequential Shield design decision; it determines compliance positioning, operational responsibility, and the audit story.
Why the key management choice is the most consequential Shield design decision
Where Data Encryption Keys live in setup
Setup, Platform Encryption, Key Management. The page lists every active key, its rotation date, its source (Salesforce-generated, BYOK-imported, Cache-Only). Admins generate new keys (Salesforce-generated), import key material from an external KMS (BYOK), or configure Cache-Only Key Service to fetch keys on demand from the customer's external key server. Each key has an active state and a destroyed state; destroyed keys cannot decrypt new content but historical content encrypted with them remains decryptable until re-encryption migrates it.
The three key management models
Salesforce-Generated Keys: the platform generates the master key, holds it in its own KMS, uses it to encrypt customer data. Simplest model; the customer relies on Salesforce key custody. Bring Your Own Key (BYOK): the customer generates the master key in an external KMS (AWS KMS, Azure Key Vault, on-prem HSM), wraps it for transport, imports to Salesforce. Salesforce holds the imported key in its KMS for runtime use; the customer holds the source of truth. Cache-Only Key Service: the customer hosts a key server; Salesforce fetches the key per encryption operation; the key never persists in Salesforce storage. Most-control model; most operationally demanding.
Key rotation and the historical-decryption question
Keys rotate per policy (annually is typical). Rotation generates a new active key; new encrypted content uses the new key. Historical content encrypted with the old key remains decryptable until re-encryption migrates it to the new key. Salesforce supports background re-encryption jobs that work through historical data at administrative-throttled rates. The old key cannot be destroyed until all data has migrated; some orgs keep multiple historical keys active for years to support legacy data.
The destroy operation and the irreversible decision
Destroying a key is irreversible. After destroy, data encrypted with that key is unrecoverable; Salesforce cannot decrypt it without the key material. Destroy is the right operation for offboarded customers (purposeful data destruction at end of contract), for compliance retention expiration (data older than the retention window is irrecoverable by policy), and for compromised keys (the key value is publicly leaked; destroy to prevent future use). Destroy is heavyweight; confirm intent before clicking and document the operation in the compliance trail.
Tenant Secrets vs Data Encryption Keys
Salesforce's encryption architecture has two layers. The Tenant Secret is the customer-source master key material (what the customer manages via BYOK or Cache-Only). The Data Encryption Key is the per-tenant key the platform derives from the Tenant Secret and uses for actual encryption operations. Customers interact with Tenant Secrets directly (generate, rotate, destroy); the Data Encryption Keys derive automatically. The distinction matters for compliance documentation; both terms appear in Shield documentation and auditor questions.
Cache-Only Key Service and the never-touches-Salesforce model
Cache-Only Key Service is the strictest key custody model. The customer hosts a key server reachable from Salesforce. Salesforce never stores the key value in its persistent storage; it fetches the key per encryption operation, uses it in memory, discards it. The customer can revoke key access at any moment by taking the key server offline; revocation immediately blocks new encryption and decryption operations. The model satisfies the strictest compliance requirements (data sovereignty, encryption-at-rest with off-platform keys) at the cost of operational complexity and latency overhead.
Compliance, audit, and the key-management evidence
Auditors asking about Shield encryption typically want answers to four questions: who holds the master key material, how often is it rotated, who can authorize key destruction, how are key operations audited. Salesforce-Generated Keys answer the questions with Salesforce-managed responses (Salesforce holds, Salesforce rotates per its policy, etc.). BYOK and Cache-Only put the customer in the answer; the customer's KMS operational practices become part of the compliance story. Pick the model that aligns with what auditors expect for the org's regulatory context.
How to choose and operate the right Data Encryption Key model
The pattern: pick the key management model that matches compliance, build the operational practice (rotation, destruction, audit), document for auditors. The decision is heavy; reverse migration is operationally hard.
- Determine compliance requirements for key custody
Some regulations are satisfied by Salesforce-Generated; some require BYOK; some require Cache-Only. Compliance team confirms the requirement before Shield rollout.
- Pick the key management model
Salesforce-Generated for default Shield, BYOK for customer-master-key requirement, Cache-Only for off-platform-key requirement. The choice cascades through every subsequent step.
- Set up the customer KMS for BYOK or Cache-Only
AWS KMS, Azure Key Vault, on-prem HSM, or the Cache-Only key server. The KMS becomes part of the compliance scope; treat as production infrastructure.
- Configure Key Management in Salesforce Setup
Setup, Platform Encryption, Key Management. Generate, import, or configure Cache-Only per the chosen model.
- Encrypt the target fields and files
Setup, Platform Encryption, Encryption Policy. Pick fields and files; the encryption applies using the active key.
- Document the operational practice
Rotation schedule, destruction authorization, audit logging. The document is what compliance teams reference; build it as you configure.
- Execute the first key rotation as a dress rehearsal
Rotation is multi-week; the first execution catches operational issues before they become emergencies during compliance audit.
Salesforce-Generated, BYOK, or Cache-Only Key Service. Drives compliance positioning and operational burden.
Annually for HIPAA-grade; tunable per compliance.
Which fields and files use the keys. Limit to compliance-required.
Irreversible; gated by authorization workflow.
The customer KMS (AWS, Azure, on-prem) for BYOK/Cache-Only models.
- Destroying a key is irreversible. Data encrypted with the destroyed key becomes unrecoverable; confirm intent and document before destroy.
- Key rotation requires multi-week re-encryption of historical data. Plan as a project; the first rotation is a dress rehearsal.
- Cache-Only Key Service adds latency. Each encryption operation fetches the key; high-volume orgs feel the overhead.
- BYOK key import requires careful wrapping and transport. Mistakes in the import produce keys Salesforce cannot use; coordinate with the KMS team.
- Salesforce-Generated Keys satisfy basic Shield compliance but not customer-key-custody requirements. Confirm compliance expectations before defaulting to Salesforce-Generated.
Trust & references
Cross-checked against the following references.
- Key Management referenceSalesforce
- Salesforce ShieldSalesforce
Straight from the source - Salesforce's reference material on Data Encryption Keys.
- Manage Encryption KeysSalesforce Help
- Bring Your Own KeySalesforce Help
- Cache-Only Key ServiceSalesforce Help
Hands-on resources to go deeper on Data Encryption Keys.
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 are the three statuses a Data Encryption Key can have?
Q2. What happens to data encrypted with an archived key?
Q3. What is BYOK?
Discussion
Loading discussion…