Encryption Key Management
Encryption Key Management in Salesforce is the set of features that controls how data encryption keys are generated, stored, rotated, and revoked for Shield Platform Encryption.
Definition
Encryption Key Management in Salesforce is the set of features that controls how data encryption keys are generated, stored, rotated, and revoked for Shield Platform Encryption. The default approach uses tenant secrets generated by Salesforce inside its Hardware Security Modules (HSMs); the platform handles key generation, storage, and automatic rotation without admin intervention. The advanced approach is Bring Your Own Key (BYOK), where the customer's security team generates the keys outside Salesforce, uploads them, and retains revocation rights. Salesforce never sees the BYOK key material in cleartext; it derives data encryption keys (DEKs) from the customer's tenant secret and uses those for actual encryption.
Encryption Key Management requires Shield Platform Encryption, which is a paid add-on. Beyond BYOK, the Cache-Only Key Service lets customers keep keys entirely outside Salesforce (in AWS KMS, Azure Key Vault, or a custom KMS), with Salesforce fetching them per-encryption-operation. This is the highest-control model and is used by regulated industries (financial services, healthcare, government) that require key custody as part of their compliance posture.
How Salesforce Encryption Key Management works
The three key types: Tenant Secret, DEK, Master
Salesforce uses a layered encryption model. The Master Encryption Key encrypts the Tenant Secret, which encrypts the Data Encryption Key (DEK), which encrypts the actual data. This three-layer approach lets Salesforce rotate keys at different cadences and revoke them granularly. The Tenant Secret is what customers manage; the DEK and Master are internal.
Salesforce-managed tenant secrets
By default, Shield Platform Encryption generates tenant secrets in Salesforce''s HSMs. Salesforce stores them, rotates them on a default cadence (typically yearly), and uses them to derive DEKs for each encrypted field or file. Customers manage this through Setup, then Platform Encryption, then Tenant Secrets: generate new secrets manually, rotate, or revoke. The HSM origin guarantees keys never leave their secure storage.
Bring Your Own Key (BYOK)
BYOK lets the customer generate the tenant secret outside Salesforce and upload it. The platform supports RSA-2048 keys and AES-256 derived secrets. The customer keeps a copy of the key in their own KMS; if Salesforce ever has a key compromise, the customer can revoke and replace immediately. BYOK requires the Shield Encryption license plus the BYOK add-on.
Cache-Only Key Service: keys outside Salesforce
Cache-Only Key Service takes BYOK further: the key never lives in Salesforce, even encrypted. Salesforce fetches it from the customer''s KMS for each encryption or decryption operation. If the customer revokes the key in their KMS, Salesforce immediately loses the ability to decrypt the data. This is the highest control model and the most operationally complex. Common in financial services with regulatory requirements like NYDFS Part 500.
Key rotation and the impact on data
Rotating a tenant secret does not re-encrypt existing data. The new secret is used for new encryptions; old encryptions continue to use the old DEKs derived from the old secret. The old secret remains accessible for decryption until explicitly destroyed. This means rotation is fast (a few seconds) but does not provide post-rotation protection for old data. For full data re-encryption, run the Mass Re-encryption job.
Revocation and the cryptographic shred
Revoking a key (or destroying a tenant secret) renders all data encrypted with it permanently inaccessible. This is the cryptographic shred: you destroy the key, and the encrypted data is mathematically unrecoverable. Regulated industries use this for data-retention compliance: when a customer asks for deletion under GDPR''s right to erasure, revoking the relevant key satisfies the request without needing to scrub the data from backups.
Compliance and audit reporting
Salesforce logs every key operation: generation, rotation, revocation, key-derivation. The KeyManagementEventLog object exposes this for audit reporting. SOC 2, HIPAA, and FedRAMP compliance audits often request these logs. Shield Platform Encryption customers receive standardized compliance documentation from Salesforce that maps platform behavior to specific control frameworks.
How to set up Bring Your Own Key in Shield Platform Encryption
Setting up BYOK is a multi-team effort: security generates the keys, Salesforce admins upload them, compliance documents the chain of custody. Plan a few weeks for the first BYOK key; subsequent rotations are faster.
- Verify Shield Platform Encryption and BYOK entitlement
Setup, then Platform Encryption. Confirm the org has Shield Platform Encryption and BYOK enabled. Without both, BYOK is not available.
- Generate the key in your KMS
Use your enterprise KMS (AWS KMS, Azure Key Vault, Thales, HashiCorp Vault) to generate a key meeting Salesforce''s requirements: typically AES-256 derived from an RSA-2048 wrapping key.
- Wrap and export the key
Wrap the AES-256 key with Salesforce''s published certificate (download from Setup) and export the wrapped key as a Base64-encoded file. The wrapping ensures Salesforce can decrypt the key when it arrives but no one else can.
- Upload the wrapped key to Salesforce
Setup, then Platform Encryption, then Tenant Secrets, then Upload Tenant Secret. Select the wrapped key file. Salesforce unwraps and stores it as the new active tenant secret.
- Activate the new secret
Mark the new secret as Active. Going forward, all encryption operations use a DEK derived from this secret. Old encryptions continue to work with their prior secrets.
- Document the key custody chain
Record in your security documentation: who generated the key, when it was generated, the key fingerprint, the upload date, the rotation schedule, the revocation triggers. Auditors will ask.
Default. Keys generated and stored in Salesforce HSMs. No customer effort.
Customer-generated keys, uploaded wrapped. Customer retains a copy and can revoke.
Keys live entirely in customer KMS. Salesforce fetches per-operation. Highest control.
All keys originate or pass through HSMs. Ensures cryptographic-quality randomness.
- Revoking a tenant secret is irreversible. Encrypted data becomes permanently inaccessible. Plan revocations carefully and ensure data backups (if needed) exist outside Salesforce.
- BYOK requires the customer''s KMS to be operationally reliable. If the KMS is down, Salesforce cannot decrypt; for Cache-Only Key Service, this means user-facing impact.
- Key rotation does not re-encrypt existing data. New writes use the new key; old reads decrypt with old keys. Run Mass Re-encryption explicitly if post-rotation re-encryption is required.
- Encryption Key Management does not encrypt every field. Standard PII fields are typically encrypted; many other fields require explicit configuration. Audit your encrypted-fields list against compliance requirements.
Trust & references
Straight from the source - Salesforce's reference material on Encryption Key Management.
- Bring Your Own Key OverviewSalesforce Help
- Cache-Only Key ServiceSalesforce Help
- Shield Platform Encryption OverviewSalesforce 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 Encryption Key Management?
Q2. What is the difference between archiving and destroying a key?
Q3. What's a best practice for key management?
Discussion
Loading discussion…