Salesforce Shield Platform Encryption: Manage keys, schemes and access with confidence

Shield Platform Encryption protects Salesforce data at rest, but the protection is only as strong as the way the customer manages tenant secrets, key material, encryption schemes and the people allowed to touch them. Salesforce derives data encryption keys from a tenant secret you control, or lets you bring your own key material, or keep keys outside Salesforce entirely with the Cache-Only Key Service or External Key Management. Each choice changes who can make data unreadable, how rotation works and what can go wrong operationally. This guide explains the key hierarchy, the permissions that govern encryption, how to choose between probabilistic and deterministic schemes, how Field Audit Trail fits, and a hardening baseline. It is written for Salesforce architects, platform owners and the security and key management teams who sign off on the design. Logging of user activity is covered in the Salesforce Event Monitoring Detection Guide; this page stays on encryption.

This is an independent guide from NHI Mgmt Group, based on Salesforce's public documentation as of November 2026. It is not sponsored or reviewed by Salesforce. Product features change, so confirm settings against Salesforce's current documentation.

Key takeaways

• Encryption is not access control. Salesforce states plainly that encryption is not the same thing as field-level security: users with access to a field see decrypted values, so set object and field permissions first.
• Manage Encryption Keys is the critical permission. It lets a user generate, export, import, upload and destroy key material, so it belongs to a small key custodian group, separate from everyday System Administrators.
• Destroying key material is permanent. Data encrypted with a destroyed tenant secret cannot be decrypted, so back up key material before any destruction and use a documented approval.
• Choose the scheme per field. Probabilistic is the default and gives random ciphertext; deterministic allows filtering and unique indexes at the cost of revealing equal values, so use it only where a business process needs to query the field.
• Rotation re-keys new data first. A new tenant secret applies to new writes; existing field data stays under the archived secret until you sync it, so plan rotation as a two-step operation.

How identity and access work in Shield Platform Encryption

Shield Platform Encryption is transparent to authorised users: Salesforce decrypts data for anyone whose profile, permission sets and sharing allow them to see the record and field. The controls that matter therefore sit in two layers.

Layer one: who can see data

Object permissions, field-level security and sharing decide whether a user sees a value at all. Encryption at rest protects against exposure of the underlying storage and supports regulatory and contractual commitments, but it does not hide a field from an over-privileged user, integration user or connected app. Review those first in the Salesforce Security Guide.

Layer two: who can change how data is encrypted

Salesforce documents four permissions for Platform Encryption administration:

Turn on Restrict Access to Encryption Policy Settings under Advanced Encryption Settings. With it enabled, policy tasks such as encrypting fields or changing encryption schemes also require Manage Encryption Keys, so a general administrator cannot quietly change which fields are encrypted.

The key hierarchy

• Tenant secret: an org-specific secret, generated by Salesforce or supplied by you, combined with a Salesforce primary secret to derive data encryption keys (DEKs) through a key derivation function.
• Derived DEKs: created on demand and held in an encrypted key cache; Salesforce states DEKs are never stored on disk. You can opt out of derivation key by key and supply DEK material directly.
• Bring Your Own Key (BYOK): you generate key material on your own infrastructure, such as an on-premises HSM, and upload it wrapped with a Salesforce-issued BYOK certificate.
• Cache-Only Key Service: for field-level encryption, DEKs stay in your key service and Salesforce fetches them on demand through a named credential, as JWE payloads wrapped with an AES-256 content encryption key that is itself encrypted to the BYOK certificate's public key with RSAES-OAEP.
• External Key Management: a root key in an external KMS wraps the DEKs; Salesforce documents AWS KMS as the provider as of November 2026, with a key policy you apply there. Wrapped DEKs live in Salesforce; unwrapped DEKs are cached for a limited time and never persisted as plaintext.

For the vendor-neutral theory behind these models, see the BYOK, HYOK and External Key Management Guide.

Admin roles and privileged access

Encryption administration is privileged because it can make data permanently unreadable or change protection for regulated fields. Build the role model around separation of duties.

• Key custodian permission set: a dedicated permission set holding Manage Encryption Keys (and Manage Certificates where BYOK is used), assigned to two or three named people, never to integration users.
• Policy administrators: platform administrators who choose fields and schemes, with Restrict Access to Encryption Policy Settings on so that scheme changes need a custodian.
• Dual control for destruction: Salesforce cannot recover destroyed tenant secrets. Require written approval from data owners and a confirmed backup of exported key material before any destroy action.
• Time-bound assignment: assign the custodian permission set for the change window only, and remove it afterwards.
• Sandbox discipline: sandboxes allow faster rotation (every 4 hours versus every 24 hours in production). Use them to rehearse, but keep production key material out of sandboxes.

Key custodian responsibilities should be written into your key management policy; the Cryptographic Key Management Policy Template gives a starting structure, and the HSM Deployment and Operations Guide covers BYOK key generation infrastructure.

Integrations, API tokens and service accounts

Encryption touches non-human identities in three places.

• Integration users read decrypted data: an API integration with field access receives plaintext. Scope integration users and connected apps tightly; see How to review Salesforce connected apps and integration users and Salesforce External Client Apps.
• Key automation via the TenantSecret object: Manage Encryption Keys allows key operations through the API. If you automate rotation, run it from a dedicated integration identity with that single permission, certificate-based OAuth, and an alert on every use.
• Named credentials for cache-only keys: the Cache-Only Key Service calls your endpoint through a named credential (named principals are supported). Protect the key service with mutual authentication, restrict its network exposure, monitor every fetch, and treat the named credential as a production secret with an owner.
• External KMS key policy: with External Key Management, the external key policy is the trust boundary. Review it as code, restrict who can edit it, and log every use in your KMS.

Choosing a scheme

Deterministic encryption reveals when two records hold the same value, so reserve it for fields that genuinely need equality search. After applying a deterministic scheme or switching between schemes, sync the data so filters return accurate results. For data classification inputs to this decision, see the Data Classification Guide.

Field-level encryption and Database Encryption

Salesforce documents two coverage models. Field-level encryption protects selected standard and custom fields, files and attachments, search indexes, Chatter and other listed data, and Salesforce advises encrypting as few fields as necessary. Database Encryption covers standard and custom fields plus metadata and Apex. Rotation and destruction behave differently: Database Encryption tenant secrets can be archived but not destroyed, and re-encrypting a whole database is arranged through Salesforce Support, while field-level encryption offers self-service sync.

Logging and detection

Salesforce states that administrative encryption tasks are audited. Setup Audit Trail is the usual place to look for setup changes; confirm in your own org which encryption events it records before you build alerts on it, and build your monitoring around those changes and the evidence auditors ask for.

Field Audit Trail

Field Audit Trail, part of Shield, extends field history so you can show who changed a sensitive value and when. Salesforce documents up to 200 tracked fields per object (standard field history tracks up to 20), retention until deleted, archiving by default after 18 months in production and one month in sandboxes, a HistoryRetentionPolicy per object and archived records in the FieldHistoryArchive big object, which is accessed through the API only. Track the same fields you encrypt where change history matters, such as bank details or national identifiers.

Metrics: number of Manage Encryption Keys holders (target: two or three); days since last tenant secret rotation per type; percentage of records synced to the active key on Encryption Statistics; encrypted fields with a documented scheme rationale; key service availability for cache-only keys; and time between a key event and its review.

Hardening baseline

1. Fix access first: review object permissions, field-level security and sharing for every field you plan to encrypt, including integration users.
2. Classify and choose fields: list regulated fields, choose field-level encryption or Database Encryption, and pick a scheme per field with a written reason. Organisations encrypting 80 or more fields should phase the rollout, as Salesforce advises.
3. Test in a sandbox: review Salesforce's encryption trade-offs for the features you use (reports, search, formulas, managed packages), then run user acceptance tests with encryption on.
4. Set up custodians: create the key custodian permission set and turn on Restrict Access to Encryption Policy Settings.
5. Generate or supply key material: generate the initial probabilistic and deterministic tenant secrets, or upload BYOK material, and export a backup to secure offline storage under dual control.
6. Enable the policy: encrypt the chosen fields, files and other data types, then sync existing data from Encryption Statistics.
7. Schedule rotation: rotate on a fixed cycle that fits your policy (Salesforce allows a new Fields and Files secret every 24 hours in production and Search Index secrets every 7 days), back up each new secret, and sync data after rotation. Keep within 50 active and archived secrets per type.
8. Roll back carefully: confirm in a sandbox how turning encryption off for a field affects existing data before doing it in production; keep archived key material until all data encrypted with it has been re-encrypted or retired, and never destroy keys as a rollback step.

Small and large organisations

A smaller org usually does well with Salesforce-generated tenant secrets, a short list of probabilistic fields and a yearly rotation. A large or highly regulated organisation may need BYOK for key origin assurance, External Key Management or cache-only keys for revocation at source, and a formal custodian process with HSM-backed generation; weigh that control against the availability duty it places on your own key service.

Common misconfigurations

• Treating encryption as a permission control: fields encrypted but still visible to broad profiles and integration users. Encryption keeps storage protected; field-level security decides who sees values.
• Manage Encryption Keys on every administrator: granted through a broad permission set. Move it to a custodian set and audit assignments.
• No exported backup before rotation or destruction: destroyed material cannot be recovered by anyone. Back up every secret and test the restore path.
• Rotating without syncing: new secrets applied, but historical records left under archived keys for years. Check Encryption Statistics after each rotation.
• Deterministic everywhere: schemes switched to deterministic for convenience. Keep probabilistic as the default and justify each exception.
• Single point of failure in a cache-only key service: a key endpoint without redundancy makes encrypted fields unreadable when it is down. Design it for the same availability as Salesforce itself.

Framework mapping

Practitioner checklist

• Review field-level security and integration user access for every field before encrypting it.
• Create a key custodian permission set with Manage Encryption Keys and limit it to two or three named people.
• Turn on Restrict Access to Encryption Policy Settings.
• Record a scheme decision (probabilistic or deterministic, case-sensitive or not) for each encrypted field.
• Export and store a backup of every tenant secret under dual control, and test restoring it in a sandbox.
• Rotate tenant secrets on a fixed schedule and sync data on Encryption Statistics after each rotation.
• Alert on key lifecycle events and custodian permission assignments, after confirming where your org records them (Setup Audit Trail, Key Management page history).
• Enable Field Audit Trail for sensitive encrypted fields that need long-term change history.
• For cache-only keys or External Key Management, design the key service or KMS policy for high availability and log every key use.

Standards and references

• Salesforce: Strengthen Your Data's Security with Shield Platform Encryption
• Salesforce: Required Permissions for Shield Platform Encryption
• Salesforce: Probabilistic and Deterministic Encryption
• Salesforce: Shield Platform Encryption Architecture
• Salesforce: Shield Platform Encryption Implementation Guide
• Salesforce: Field Audit Trail
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Encryption Guide · BYOK, HYOK and External Key Management Guide · Salesforce Security Guide · Salesforce Event Monitoring Detection Guide