Platform Encryption key management
Key Takeaway
Rotating a key archives the old key, which still decrypts the data it encrypted. Destroying a key makes its data unreadable unless you import previously exported key material. In a sandbox refreshed from production, these actions affect the sandbox's own copy of the tenant secrets, not the tenant secrets in production.
Shield Platform Encryption encrypts data at rest with keys that your org controls. Key management is the work of creating, rotating, backing up, and rarely destroying that key material, or supplying it from outside Salesforce. You do this work so the org can meet its security, legal, and compliance rules in both production and sandbox orgs.
How encryption keys are built
By default, Salesforce derives a DEK by combining the primary secret with your tenant secret. You control when the tenant secret is generated, activated, revoked, or destroyed, so you control the lifecycle of the DEKs derived from it.
Not every data store uses key derivation. Field-level encryption and Database Encryption use a derived key. Search indexes, Archive, Backup & Recover Next, and Data 360 instead use a root key that wraps their DEKs.
Encryption keys are specific to one org and can't be shared with other orgs. A key also serves only one feature, so a field-level encryption key can't be used for search indexes.