Salesforce Shield Platform Encryption encrypts your Salesforce data at rest using AES 256-bit encryption with keys you control. It is part of Salesforce Shield, a paid add-on suite that also includes Event Monitoring, Field Audit Trail, and Data Detect.
Organizations enable it to satisfy regulatory obligations that standard platform security does not cover on its own, particularly where auditors require customer-managed encryption keys.
The part most guides understate is the trade-off. Shield now offers two encryption approaches, and they behave very differently. Database Encryption protects most data transparently. Field-level encryption protects specific fields more deeply, and in doing so restricts filtering, sorting, and SOQL operations that your teams already rely on.
The stakes run both ways. IBM put the average global cost of a data breach at $4.88 million in its 2024 report, and encryption at rest is one of the most direct ways to reduce that exposure. A poorly planned rollout, though, simply trades one category of risk for another, and DevOps process adjustments are usually the piece teams discover last.
What Shield Platform Encryption Actually Does
Shield Platform Encryption is not an incremental upgrade over Classic Encryption. The differences are architectural, and administrators should understand them before choosing an approach.
Classic Encryption supports 128-bit AES and protects only a special encrypted text custom field type. It cannot encrypt standard fields, files, or attachments, and it offers no customer key management.
Shield Platform Encryption uses 256-bit AES across standard fields, custom fields, files, and attachments, and it supports customer-managed key material. The encryption services are built natively into the platform, so no additional hardware or custom code is required.
Database Encryption vs. Field-Level Encryption
Shield Platform Encryption now offers two distinct approaches, and choosing between them is the first real decision an administrator makes.
Database Encryption encrypts most of your data at rest with a tenant-specific key at the storage layer. It is available to Hyperforce customers with a Shield or Shield Platform Encryption license, and it is transparent: filtering, sorting, and SOQL queries continue to work normally.
Field-level encryption encrypts individual fields, files, and attachments before the data reaches the database, so even someone with database access cannot read the values. That deeper protection is what introduces the functional restrictions covered later in this guide.
The two are not mutually exclusive. Many organizations run Database Encryption as a broad baseline and apply field-level encryption selectively to the fields an auditor specifically requires. Where field-level encryption is layered on top, the standard field-level limitations still apply to those fields.
Takeaway: encrypt broadly with Database Encryption, then reserve field-level encryption for the fields that genuinely justify losing query functionality.
How to Enable Shield Encryption in Salesforce
Enabling Shield encryption is a sequence rather than a switch. The order matters, because several steps cannot be cleanly undone.
Prerequisites first. Shield Platform Encryption requires Enterprise, Performance, or Unlimited Edition with a Shield or Shield Platform Encryption license, and it is available free in Developer Edition for testing. You also need the Manage Encryption Keys permission, which should be assigned deliberately rather than bundled into a general admin profile.
- Confirm the license is provisioned and assign the Manage Encryption Keys permission to the specific users who will handle key material.
- In Setup, search for Platform Encryption to reach the encryption pages. Field-level encryption can also be managed from the Shield app.
- Generate a tenant secret. No data can be encrypted until key material exists.
- Back up the tenant secret immediately, before encrypting anything.
- Run the Platform Encryption Analyzer to identify which fields are safe candidates.
- Set your encryption policy by selecting the fields, files, and data elements to encrypt, choosing the scheme for each field.
- Let the synchronization process complete, then verify coverage on the Encryption Statistics page.
- Test reports, dashboards, list views, flows, and integrations in a full copy sandbox before repeating the sequence in production.
To confirm encryption is actually active, use the Encryption Statistics page rather than the policy screen. The policy shows what you intended to encrypt. Encryption Statistics shows what is encrypted and when data was last synchronized.
Key Hierarchy Administrators Control
Field-level and Database Encryption both use key derivation. A data encryption key is derived on demand from a tenant secret that you control and a primary secret that Salesforce maintains.
Derived keys are never stored in plaintext, so controlling the tenant secret lifecycle gives administrators effective control over the encryption itself. Other features, including external key management and search index encryption, instead use a root key that wraps the data encryption keys directly.
Note the terminology. Salesforce documentation now refers to the Salesforce-held component as the primary secret, replacing older language you may still see in third-party guides.
Operational Limitations That Break Workflows
Encryption protects data and restricts how that data can be queried, filtered, and deployed. Evaluate these constraints against business requirements before encrypting any field, because skipping the assessment produces broken automation and failed deployments.
The table below summarizes the constraints that most often surprise administrators, with the detail following underneath.
Run the Analyzer First
Before encrypting any field in production, run the Platform Encryption Analyzer, included in the Shield Extension managed package. Access it from the Shield app after installing the extension.
The Analyzer evaluates which fields are suitable candidates and reports the impact on list views, filters, search, and reports. Its output tells you which fields will break something before you find out from a user, and it should drive every decision in the sections below.
Querying and Filtering Restrictions
The encryption scheme you select determines what functionality survives. Probabilistic encryption prevents filtering, sorting, and SOQL WHERE operations on encrypted fields. Deterministic encryption permits exact-match filtering, with no wildcard or range queries.
Fields encrypted with the probabilistic scheme cannot be used in SOQL aggregate functions, WHERE clauses, GROUP BY, or ORDER BY. Encrypted fields of either scheme cannot be used in criteria-based sharing rules, similar opportunities searches, or external lookup relationships.
Flows and processes can reference encrypted fields in most contexts, but not for filtering or sorting. One subtler risk is worth planning for: when a flow pauses or waits, the interview is serialized to the database, and encrypted field values loaded into variables are not always encrypted at rest in that state.
The 80-Field Deployment Limit
Salesforce does not impose a hard limit on how many fields you can encrypt. It does impose one functional limitation on deployment: with Shield Platform Encryption enabled, you can deploy only 80 fields at a time in a package, and packages configured with 80 or more encrypted fields must be deployed in phases containing fewer than 80 fields each. This affects metadata deployments at scale.
A worked example makes the batching concrete. An org encrypting 210 fields across Account, Contact, and Case cannot ship them as one package. Split into three phases of roughly 70 fields each, sequence them by object so dependencies resolve cleanly, and validate each phase in the target org before starting the next.
CI/CD pipelines need batching logic to orchestrate that sequence, which is the point where manual change sets stop being viable.
Takeaway: the limit is about deploying packages, not about how much you can encrypt, and it is a pipeline design problem rather than a policy problem.
Deterministic vs. Probabilistic Encryption
Deterministic and probabilistic encryption are the two schemes available for field-level encryption, and the choice is per field rather than per org.
Probabilistic encryption generates different ciphertext each time the same value is encrypted, which offers the stronger protection and removes the most functionality. Deterministic encryption generates consistent ciphertext for the same value, which is what allows exact-match filtering to keep working, at the cost of revealing which records share a value.
Takeaway: every field moved to deterministic encryption is a deliberate security trade made for a named business requirement, and should be documented as such.
Key Management: The Highest-Risk Responsibility
Tenant secret management carries permanent consequences that no other Salesforce configuration decision shares.
Salesforce states plainly that it cannot help you with deleted, destroyed, or misplaced tenant secrets. If a tenant secret is destroyed without a backup, all data encrypted with keys derived from it becomes permanently unreadable. There is no escalation path and no recovery.
The implication is simple and often skipped: back up every tenant secret immediately after generation, store the backup outside Salesforce, and make key destruction a procedure requiring more than one person.
Rotation and BYOK Considerations
Key rotation applies new tenant secrets to future data while retaining previous keys so existing records stay readable. Beyond Salesforce-managed keys, Shield supports Bring Your Own Key, external key management through a service such as AWS KMS, and cache-only keys fetched on demand rather than stored. Each option moves more control, and more operational burden, to you.
Takeaway: choose BYOK because a control requirement demands it, not because it sounds more secure, since the added control comes with real operational cost.
Deployment and DevOps Impact
Shield Platform Encryption changes how metadata moves between environments, so DevOps teams need to adjust pipeline design, testing workflows, and sandbox management. A workable implementation order is: enable encryption in a developer sandbox, run the Analyzer, encrypt a small pilot field set, validate reports and automation, then promote the policy and the batched metadata through your normal pipeline stages.
Asynchronous Encryption Creates Test Failures
A timing issue affects automated pipelines. The encryption compliance check runs asynchronously, after the Metadata API has already reported deployment success. Apex tests that query encrypted fields can fail if they execute before encryption processing finishes.
A two-phase deployment resolves it:
- Deploy the field metadata and encryption policy changes on their own.
- Wait for encryption processing to complete and confirm it on the Encryption Statistics page.
- Deploy the dependent Apex code and tests in a second package.
- Run the test suite only after both phases have landed.
Sandbox Refresh Behavior
When Shield Platform Encryption is enabled in production, encryption settings including tenant secrets copy automatically to sandboxes during refresh, so no manual reconfiguration is needed.
After every refresh, verify three things before the sandbox is used for testing: that the encryption policy matches production, that key material is present and current, and that reports, dashboards, flows, and processes still behave as expected. Salesforce recommends testing all of those in a sandbox before applying encryption changes to production.
Takeaway: a sandbox refresh is a checkpoint, not a formality, because an encryption policy drift between environments surfaces as a failed production deployment.
Compliance Requirements Shield Addresses
Shield Platform Encryption maps to specific regulatory mandates, but in every case the platform supplies a capability and the administrator supplies the evidence.
PCI DSS deserves a specific caution. Salesforce holds a PCI DSS Attestation of Compliance, but customers who use deterministic encryption for primary account numbers or other cardholder data fall outside the scope of that attestation and are responsible for their own PCI DSS compliance on those fields.
Takeaway: a Salesforce certification covers Salesforce, and your auditor will still ask for evidence of your own configuration.
Salesforce Shield Platform Encryption Documentation
Salesforce publishes extensive Shield Platform Encryption documentation, and knowing which page answers which question saves considerable time.
- What You Can Encrypt. Covers Database Encryption, standard and custom fields, search indexes, Data 360 data stores, files and attachments, event bus data, Chatter data, and CRM Analytics data.
- General Shield Platform Encryption Considerations. The single most useful page for planning. It lists feature-by-feature behavior changes across leads, user email, flows, reports, search, duplicate management, and more.
- Considerations for Using Deterministic Encryption. The specific SOQL and SOSL compatibility detail for filter-preserving encryption.
- Key Management and Rotation. Generating, backing up, rotating, and destroying key material, plus BYOK, external key management, and cache-only keys.
- Trailhead: Shield Platform Encryption for Admins. A guided module covering architecture, key management, and encryption policies.
Check the considerations page before encrypting any field type you have not encrypted before, and re-check it after each Salesforce release.
Before Enabling Salesforce Shield Encryption: Administrator Checklist
Work through this before any production change. Most Shield incidents trace back to a skipped item here rather than to a misconfiguration.
Making Encryption Work Across Your Release Process
Three points are worth carrying out of this guide. Database Encryption and field-level encryption solve different problems, and most orgs should use both rather than choosing one. The encryption scheme decides which functionality survives, so it is a business decision as much as a security one. And tenant secret management is the only Salesforce configuration where a mistake is permanent.
The operational weight lands on the release process. The 80-field package limit and asynchronous encryption processing require batched, sequenced deployments with validation between phases, which is exactly what manual change sets handle poorly.
Flosum is an end-to-end enterprise DevSecOps platform purpose-built for Salesforce. Automated pipelines orchestrate batched metadata deployments, policy-based controls govern what reaches production, and audit trails for compliance capture the deployment history auditors ask for.
When audit deadlines approach, complete deployment history and change documentation shorten preparation considerably. Request a demo to see how encryption-aware release management works in practice.
Frequently Asked Questions (FAQ)
Thank you for subscribing
