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.