External Key Management
Shield External Key Management (EKM) connects your Salesforce implementation to your key material (tenant secret, data encryption key, or root key) in an external KMS and uses that key material for encryption operations on Salesforce data. EKM fetches your keys on demand from the external KMS over a secure channel. EKM is currently available for core encryption services (such as FLE), all Data 360 data, and for Shield Platform Encryption Search Indexes.
Required Editions
| Available in both Lightning Experience and Salesforce Classic (not available in all orgs). |
| Available in: Enterprise, Performance, Unlimited, and Developer Editions. Requires purchasing Salesforce Shield or Shield Platform Encryption, and the External Key Management Service. Data 360 customers must also have the Platform Encryption for Consumption license. |
| User Permissions Needed | |
|---|---|
| To generate, destroy, export, import, upload, and configure tenant secrets and customer-supplied key material: | Manage Encryption Keys |
When you encrypt data using EKM, you get the benefits built into Salesforce Shield Platform Encryption plus the extra assurance that comes from managing your keys with your preferred key management service. Unlike Salesforce’s Cache-Only Key Service, EKM integrates natively with external key management services for a quicker, more streamlined user experience.
For the core Shield Platform Encryption features than use their own tenant secret (fields, files and attachments, CRM analytics data, and event bus data), EKM manages your tenant secret. EKM stores your tenant secret in the key cache and uses your key for immediate encrypt and decrypt operations.
For Shield Platform Encryption features which use a root key (Platform Encryption for Data 360 and Search Index Encryption), EKM manages your root key.
Salesforce doesn’t retain or persist your cached EKM keys in any system of record or backups. You can revoke key material at any time.
- How Salesforce Shield EKM Works
Shield Platform Encryption, when using External Key Management (EKM), relies on a customer's external Key Management Service (KMS) to manage data encryption keys (DEKs). These DEKs are crucial for both encrypting and decrypting data. When not in use, the DEKs are stored in a "wrapped" (encrypted) state within Shield Platform Encryption's key cache. For any encryption or decryption operation, Shield Platform Encryption sends the wrapped DEK to the customer's external key service, which then unwraps it and securely returns it. This process remains consistent for Data 360 users as well. - EKM Prerequisites
To use EKM, you must create a data encryption key (DEK) of sufficient strength in a supported external key management service. You should also check that an external application can communicate with the key service to securely retrieve the DEK. - Key Coordination Policy Setup
Track the status of both the external KMS key and the Salesforce EKM key that depends on it. - Connect Salesforce to AWS KMS and Create a Data Encryption Key
When you configure your connection between Salesforce and AWS, you provide information about the AWS KMS key that you want Salesforce to use (key identifier, region, and description). You then generate a JSON structure and add that structure to your key policy in the AWS console for your key. - Key Maintenance and Auditing for EKM
Common key operations include auditing, deactivating, reactivating, rotating, and checking the connection to your external keys. These operations affect the keys identified in your Salesforce setup. The original keys in the external KMS are managed by a separate external process. - EKM in a Sandbox Org
A sandbox org that’s copied, refreshed, or cloned from a source org that uses EKM keys is granted minimum access to the source org’s keys, so that it can decrypt any encrypted data it inherited from the source org. A sandbox org can’t manage its source org's keys in any way, because sandboxes have limited access to those keys. Rotate the keys in a sandbox org as soon as you create it.
