Salesforce Security Guide
j
No Results
Search Tips:
- Please consider misspellings
- Try different search keywords
Platform Encryption Q&A
Here are some frequently asked questions about platform encryption.
| Available in both Salesforce Classic (not available in all orgs) and Lightning Experience. |
| Available as an add-on subscription in: Enterprise, Performance, and Unlimited Editions. Requires purchasing Salesforce Shield or Shield Platform Encryption. Available in Developer Edition at no charge. |
- What are the hardware and software requirements for using Platform Encryption?
- None. The crypto functions run natively on the Salesforce platform. No custom code is required to encrypt or decrypt data.
- Must I encrypt all of my data when using Platform Encryption?
- No. Not all data is sensitive, so encryption isn’t always required. Also, unnecessarily encrypting data can affect performance and functionality.
- When I enable Platform Encryption, how are my existing encrypted fields affected?
- The Platform Encryption process doesn’t affect fields encrypted using Classic Encryption.
- What encryption algorithm is used with Platform Encryption?
- The Platform Encryption uses symmetric key encryption and a 256-bit Advanced Encryption Standard (AES) algorithm to encrypt field-level data and files stored on the Salesforce platform. Data encryption and decryption occur on the application servers. Encryption is integrated into the Salesforce application so the application knows when data must be encrypted or decrypted. Whether you’re accessing data through the user interface or the API, encryption and decryption are handled the same way.
- Can I access tenant secrets using the API?
- Yes. For example, you can use the API to define an automatic process to rotate the Platform Encryption key regularly. For detailed information, search for TenantSecret in the Object Reference for Salesforce and Lightning Platform.
- Do data encryption keys held in memory rotate automatically when Salesforce rotates the master secret?
- No. While Salesforce rotates the master secret on a per-release basis, customers’ data encryption keys aren’t impacted. No new data encryption key is derived automatically.
- I use Platform Encryption, and the Encrypted checkbox isn’t visible when I create or edit an existing custom field. Why?
- Only Email, Phone, Text, Text Area, Text Area (Long), Text Area (Rich), Date, Date/Time and URL custom field types are available for encryption.
- What happens to existing data if I rotate a tenant secret?
- When you generate a new tenant secret, existing encrypted data remains encrypted and accessible as long as the old tenant secret isn’t destroyed. New data is encrypted using the new tenant secret. There’s no functional difference to the user.
- How finely can I control what data is encrypted with Platform Encryption?
- For field data, you control which supported standard and custom fields to encrypt. For files and attachments, you control whether encryption is enabled in your organization.
- If I enable Platform Encryption, is the format for custom phone, email, and URL fields preserved?
- Yes, formats for custom phone, email, and URL fields are preserved when they’re encrypted.
- Are the Hardware Security Module (HSM) network appliances shared by multiple tenants?
- Yes. Key material produced by an HSM is either a per-release secret or a per-tenant secret. Both are required to encrypt your data, so no two tenants have the same data encryption keys.
- Do third-party vendors have access to the Hardware Security Modules (HSM)?
- No. Salesforce controls access to the HSMs exclusively.
- How long are the tenant secret, primary secret, and data encryption keys?
- 256 bits in length.
- Where is my data encryption key stored?
- The keys are stored only in memory and never persisted on disk.
- Can I manage my keys outside of Salesforce?
- Yes. You can store your key outside of Salesforce and have either the External Key Management service or the Cache-Only Key Service fetch it on demand from a key service that you control.
- What is the limit for how many keys we can have?
- You can have up to 50 active and archived tenant secrets of each type. For example, you can have one active and 49 archived Fields and Files (Probabilistic) tenant secrets, and the same number of Analytics tenant secrets. This limit includes Salesforce-generated and customer-supplied key material.
- What if I already have too many active and archived secrets?
- If you run into the 50 limit, review your encryption coverage statistics to find our your active key coverage. Choose one or more keys to destroy. Don’t destroy any of them until you synchronize the data they encrypt with an active key.
- Are keys I store outside of Salesforce part of the 50-key limit?
- There is an across-the-board limit of 50 undestroyed keys. This includes keys managed by external services via EKM, BYOK, and the Cache-Only Key service.
- How is my organization-specific key generated?
- The data encryption keys are derived by a key derivation function (KDF) that combines a primary secret with an organization-specific tenant secret and a randomly generated 128-bit string.
- Where are encryption policies defined?
- Your organization defines its own policies.
- Can I re-encrypt encrypted data?
- Yes. You can review your encryption coverage statistics to find our your active key coverage. Then if you want, you can synchronize the encryption of your data with the most recent tenant secret using the Background Encryption Service.
- Can a Platform Encryption key be shared across more than one organization?
- No. Encryption keys are specific to an organization and can’t be shared with other organizations.
- Does encrypting fields, files, and attachments with Platform Encryption count against my organization’s storage limits?
- No. Encryption and decryption do count against your organization’s per-transaction Apex limits, but they aren’t counted as separate transactions.
- If I can see encrypted data, can Salesforce Support representatives also see the data?
- Yes, if they have access to the object, record and field.