Regulated teams on Salesforce usually face the same question early in a build. Should sensitive data be protected with Salesforce Shield, or with a third-party encryption product that sits outside the platform? The answer shapes your compliance story and what your developers can build on top of the data.
Both paths can work. They protect against different threats, and they break different things. Shield keeps encryption inside the platform, so most features keep working. Outside encryption can keep plaintext and keys entirely outside Salesforce, which some regulators and data transfer rules favor. This guide explains how each option works and how regulated teams can choose without guessing.
TL;DR
Salesforce Shield is the better default for most regulated teams because Shield Platform Encryption protects data at rest inside Salesforce while keeping most platform features usable. Its key management options, including bring your own key and the Cache-Only Key Service, give you more control over the keys without moving encryption outside the platform. Third-party encryption, such as an encryption gateway or tokenization service, makes sense when Salesforce itself must never see plaintext. That matters most for strict data sovereignty and cross-border transfer cases. This extra protection comes at a cost, because search and automation may stop working on protected fields. Many teams end up combining the 2, using Shield for encryption and an outside key manager for key control.
What Salesforce Shield Includes and Where Encryption Fits
Salesforce Shield is a paid add-on bundle for security and compliance. Salesforce’s own Shield guide describes it as a set of tools for data protection and compliance. Encryption is only one part of it.
The bundle includes Shield Platform Encryption for data at rest. It also includes Event Monitoring, which records detailed user and API activity, and Field Audit Trail, which keeps field history for much longer than standard history tracking. Data Detect, a scanning tool, helps teams find sensitive data they may not know they’re storing.
That matters for this decision because regulators rarely ask for encryption alone. A healthcare or financial services audit usually asks who accessed the data and what changed, along with how it’s protected. Event Monitoring and Field Audit Trail answer the first 2 questions. An outside encryption product answers only the last one. Teams comparing options should be clear about which part of Shield they’re replacing and which parts they still need.
Data residency is a separate question from encryption. Salesforce’s Hyperforce infrastructure lets many customers choose the region where their data is stored. That helps with residency rules, but it doesn’t decide who can read the data. Encryption and key ownership answer that second question, which is why regulated teams usually need both.
Salesforce also offers Classic Encryption at no extra cost. It covers only special encrypted custom text fields of up to 175 characters, uses 128-bit AES and masks values for users without the right permission. For regulated data spread across standard objects and files, Classic Encryption is usually too narrow. Most regulated teams end up comparing Platform Encryption with an outside product instead.
How Shield Platform Encryption Works
Shield Platform Encryption protects data at rest in Salesforce with AES-256 and now includes more than one encryption path. Field-level encryption lets admins select supported standard fields, custom fields, files and attachments. New data is encrypted after the policy is enabled, while existing records may need a sync process. Hyperforce orgs with the required license can also use Database Encryption for the transactional database.
The key point for regulated teams is what Platform Encryption doesn’t do. It protects stored data against threats such as a stolen disk or a backup copied outside its normal controls. It doesn’t hide data from users who already have permission to see it. A user with read access to an encrypted field sees the plaintext value in the interface and through the API. Access control still depends on profiles, permission sets and sharing rules.
Field-level encryption offers 2 encryption schemes. Probabilistic encryption is the default. It produces different ciphertext each time, even for the same value, which gives stronger protection but blocks filtering and sorting on the field. Deterministic encryption produces the same ciphertext for the same value, so the platform can match exact values. That allows equality filters, unique fields and some matching rules, at the cost of revealing when 2 records hold the same value. Deterministic encryption comes in case-sensitive and case-insensitive forms.
Database Encryption is a separate data-tier option for Hyperforce customers with Shield or Shield Platform Encryption. Salesforce says it can encrypt most transactional database data without impeding filtering, sorting or the many platform features that depend on those operations. That makes it different from field-level encryption, where probabilistic and deterministic schemes can change how encrypted fields behave. Teams can use Database Encryption on its own or alongside field-level encryption when they need field-specific protection as well as broader database coverage.
Encryption policies apply field by field, so every new field needs a decision. A team that adds a sensitive custom field next quarter has to remember to encrypt it. Make encryption review part of your change process, and use Data Detect or a similar scan to catch regulated data in fields nobody expected. Without that habit, coverage quietly drifts as the org grows.
Salesforce’s own training material makes the same point. Its Trailhead module on encryption techniques walks through field-level choices for admins. Its main message is that field-level encryption is a design decision. Teams should choose the scheme per field based on how the field is used. Encrypting every field with FLE by default tends to cause avoidable query failures.
Key Management Options: Tenant Secrets, BYOK, EKM and Cache-Only Keys
Key management is where Salesforce Shield gives regulated teams the most room to adjust their risk posture. By default, Salesforce derives each data encryption key from a master secret and an org-specific tenant secret. Admins can generate and rotate the tenant secret, but Salesforce generates the key material.
Bring Your Own Key
With BYOK, your team generates supported key material outside Salesforce and uploads it. Depending on the Shield feature, Salesforce supports customer-supplied tenant secrets, data encryption keys, root keys or other supported key material. A supplied tenant secret can still participate in Salesforce key derivation, while a supplied DEK is used differently. Salesforce documents these differences in its customer-managed key options. BYOK gives your team control over key creation and lets authorized administrators revoke or destroy uploaded key material when required.
Key generation still has to follow good practice. NIST’s guidance on key management, SP 800-57, covers the full key lifecycle, from generation and storage to rotation and destruction. Auditors often check your key procedures against frameworks like this, so the process around BYOK matters as much as the feature itself.
External Key Management
External Key Management is a separate customer-managed key option. Salesforce connects to a supported external key management service controlled by the customer and requests key operations over a secure channel when needed. The root key remains in the external KMS, while Shield uses the returned or unwrapped data encryption key through its protected cache. This differs from BYOK, where supported material is uploaded to Salesforce, and from Cache-Only Keys, where the DEK is fetched for immediate use and is not persisted in a Salesforce system of record. See Salesforce’s external key material guidance for the supported models and feature differences.
Cache-Only Key Service
The Cache-Only Key Service goes a step further. Your key material stays in a key service you control. Salesforce fetches it over a secure connection when it needs to encrypt or decrypt, holds it briefly in cache and doesn’t store it. If you revoke access at your key service, Salesforce can no longer decrypt the protected data.
That revocation ability is the main reason regulated teams choose cache-only keys. It gives you a clear technical answer when an auditor asks how you’d cut off the cloud provider’s access to your data. The trade-off is availability. If your key service goes down, users can’t read encrypted data in Salesforce until it’s back.
Key Rotation and Destroyed Keys
Rotation is part of every key model. When you rotate, Salesforce uses the new key for new data while archived keys stay available to read older data. That’s why key history matters. If you destroy a key, data encrypted with it becomes unreadable unless you can restore the key material.
Regulated teams should treat key destruction as a deliberate, approved action. Keep a backup of BYOK material in a secure location, and record who can approve rotation and destruction. Auditors usually ask to see that record, so keep it current.
Before you commit to a key model, read Salesforce’s encryption implementation guide. It covers these options in detail, including setup steps and limits. Some choices are hard to reverse once data is encrypted, so the reading time pays off.
How Third-Party Encryption Tools Work With Salesforce
Outside encryption covers 2 quite different kinds of product. Teams sometimes treat them as one category, which leads to poor decisions.
Encryption Gateways and Tokenization
The first kind replaces Platform Encryption entirely. An encryption gateway sits between your users and Salesforce. It encrypts or tokenizes sensitive values before they reach Salesforce, and it reverses the process when data comes back to an authorized user. Salesforce stores only ciphertext or tokens, and the keys never leave your environment.
A gateway also moves availability to your side. If the gateway goes down, users can’t work with protected data even though Salesforce itself is running. The gateway becomes part of your production system, with its own monitoring, failover and change process.
Tokenization products follow a similar model. Protegrity’s Salesforce integration is one example of a tokenization approach for Salesforce data. Instead of encrypting a value, the service replaces it with a token that has no meaning outside the tokenization system.
The benefit is strong separation. Salesforce can’t read the protected data, even while processing it. The cost is that every path into Salesforce has to go through the gateway, including browsers, mobile apps, API integrations and AppExchange packages. Vendor documentation shows how much work this can take. Conga’s guide on CipherCloud for Salesforce describes the specific setup its document generation app needs to work with a gateway in place.
Some teams build a lighter version of this pattern themselves. They encrypt a few sensitive values in their integration layer before the data reaches Salesforce, and decrypt them in downstream systems. That avoids a full gateway, but your team then owns the cryptography and every bug in it. It suits a handful of fields that no Salesforce process ever needs to read.
Key Management Add-Ons for Shield
The second kind works with Shield instead of replacing it. These products can support different Salesforce customer-managed key models rather than one generic “external key manager” pattern. BYOK uploads supported key material to Salesforce. EKM keeps root-key control in an external KMS and performs key operations there. Cache-Only Keys keep the DEK outside Salesforce and fetch it into a protected cache on demand. Salesforce documents the 3 options separately in its external key material guidance.
Vendors can support one or more of those models. Thales describes CipherTrust key management for Salesforce, while Fortanix documents how to export keys for the Cache-Only model. The storage, retrieval, revocation and availability behavior depends on which Salesforce option is actually configured, so architecture documents should name BYOK, EKM or Cache-Only explicitly instead of treating them as interchangeable.
Salesforce Shield vs. Third-Party Encryption at a Glance
The table keeps the comparison compact, but the middle column is shorthand for customer-managed key configurations rather than one technical model. BYOK, EKM and Cache-Only Keys differ in where key material is stored, how Salesforce retrieves or uses it, how revocation works and what happens when an external key service is unavailable. Read the middle column as a family of Shield key-control options, not as one identical architecture.
| Factor | Platform Encryption | Shield With External Key Manager | Encryption Gateway or Tokenization |
| Where encryption happens | Inside Salesforce | Inside Salesforce | Outside Salesforce |
| Who holds the keys | Salesforce, or you with BYOK | Your key service | Your gateway or token service |
| Can Salesforce see plaintext? | Yes, while processing | Yes, while keys are available | No |
| Platform features on protected fields | Most work, with limits on filters and sorting | Same as Shield | Many break or need workarounds |
| Revoke cloud access to data | Limited | Yes, with cache-only keys | Yes |
| Integration effort | Low | Medium | High |
| Audit and monitoring tools included | Yes, in the Shield bundle | Yes, in the Shield bundle | No, buy separately |
The plaintext row needs a careful reading. With Shield, Salesforce decrypts data in memory to serve authorized users and run platform features. With cache-only keys, that stops the moment you revoke the key, but it also stops for your own users. With a gateway, Salesforce never decrypts protected values, and your users still reach them through the gateway. Each design draws the line between control and availability in a different place.
The biggest dividing line is the third row. If your requirement is that Salesforce must never handle plaintext, only a gateway or tokenization approach meets it. If your requirement is strong encryption at rest with keys you control, Shield with an external key manager usually meets it with far less disruption.
What Regulations Actually Ask For
Regulations rarely name a product. They describe outcomes, and each outcome points toward a different design. Mapping those outcomes before choosing a tool saves rework later.
HIPAA
The HIPAA Security Rule treats encryption as an addressable safeguard today, which means covered entities must assess it and document their decision. The bigger driver is breach notification. HHS guidance on unsecured protected health information explains that PHI encrypted to its standards isn’t considered “unsecured,” so a breach of that data may not require notification. The same guidance says decryption keys should be kept separate from the data they protect.
For Salesforce teams, that makes key separation a practical requirement. Salesforce Shield with bring your own key or cache-only keys gives you a cleaner story than default tenant secrets. A gateway also meets it, because the keys never enter Salesforce.
GDPR and International Transfers
GDPR names encryption as one example of an appropriate security measure in Article 32. The regulation text also says organizations may not need to notify individuals of a breach when the data was unintelligible to anyone without access, such as through encryption.
Cross-border transfers raise the bar. After the Schrems II ruling, the European Data Protection Board published recommendations on supplementary measures. In EDPB Use Case 1, encryption is treated as an effective supplementary measure only under specific conditions, including strong encryption before transfer, reliable key management, keys kept under the exporter’s control or equivalent protection, and a processing design that does not require the importer to access the data in cleartext. A gateway or tokenization architecture can therefore have an advantage in some transfer assessments, but that is an architecture-specific conclusion rather than a general rule that third-party encryption satisfies cross-border requirements.
PCI DSS
PCI DSS Requirement 3 covers protecting stored account data. It asks organizations to render primary account numbers unreadable and to follow documented key-handling procedures. The standard and its supporting guidance are available in the PCI document library. Keeping full card numbers out of Salesforce entirely removes much of that scope before encryption comes into play.
DORA
For EU financial entities, the Digital Operational Resilience Act adds ICT risk rules that include encryption and cryptographic key management. The DORA regulation also requires exit strategies for critical ICT providers. Your encryption choice should fit that exit plan. Data protected by a gateway or by your own keys has to stay readable if you ever leave Salesforce.
Customer Contracts and Security Reviews
For B2B SaaS companies, customer contracts can be stricter than the regulations that apply. Enterprise buyers often send security questionnaires that ask who holds the encryption keys and whether your provider can read their data. A clear answer on key ownership can shorten those reviews. Shield with BYOK or cache-only keys gives you a defensible answer for most buyers. A few will still insist that their data never appears in plaintext inside a third-party cloud.
Functional Trade-Offs Users Will Notice
Encryption always costs something in usability. The question is how much, and whether users will accept it.
With Shield Platform Encryption, the query limits below apply to field-level encryption. Probabilistic FLE blocks filtering, sorting and report grouping. Deterministic FLE allows exact-match filtering, but not partial matches or ranges, and some field types and features remain unsupported. For Hyperforce orgs, Database Encryption is a separate design choice that encrypts most transactional database data without the same filtering and sorting restrictions. Teams should choose FLE, Database Encryption or both based on the data they need to cover and the Salesforce behavior they need to preserve.
Encryption gateways create bigger changes. Because Salesforce stores only ciphertext or tokens, any feature that runs inside Salesforce sees those values instead of real data. Global search may not find protected records. Reports may show tokens. Flows and validation rules that check a protected value may stop working. Teams often redesign some processes to run outside Salesforce or accept that certain fields can’t drive automation.
Exports and backups behave differently too. With Platform Encryption, an authorized user exporting data gets plaintext, and so does a backup tool that reads through the API. That means backup copies need their own protection outside Salesforce. With a gateway, exports and backups hold tokens or ciphertext, which protects them but also means restores have to pass back through the gateway to be useful.
AI features raise the same question in a newer form. Salesforce AI tools work on data inside the platform. With Shield, data can be decrypted for features that support encrypted fields, subject to Salesforce’s documented limits. With a gateway, AI features inside Salesforce will only see protected values. If AI on customer records is part of your roadmap, check each feature’s support for encrypted fields before you choose.
What Changes for Developers and ISVs
Developers feel the encryption decision in daily work. With Salesforce Shield, Apex code reads and writes encrypted fields like any other field when the running user has access. The main changes are in queries. SOQL that filters or sorts on a probabilistic encrypted field will fail. Code has to filter on other fields, or the field needs deterministic encryption where exact matches matter.
Testing needs encryption turned on. Teams should run development and testing in sandboxes with the same encryption policies as production, so failing queries show up early. Salesforce also documents a Platform Encryption API, which lets teams manage encryption programmatically as part of their deployment process.
Encryption choices can live in source control. Custom field metadata includes the field’s encryption scheme, so teams can review encryption changes in pull requests like any other change. That gives auditors a history of when each field was encrypted and who approved it.
With a gateway, more of the logic moves outside Salesforce. Apex code that works with protected fields sees ciphertext or tokens, so it can’t apply business rules to those values. Every integration that writes to Salesforce has to send data through the gateway, or plaintext ends up stored where it shouldn’t be. That makes integration reviews a standing part of the release process.
ISVs building managed packages face an extra layer. Customers may run your app in an org with Shield turned on, or behind a gateway. Apps that filter on fields customers encrypt can fail in those orgs. Test against orgs with encryption on, and document which fields your package can handle when they’re encrypted.
Cost Considerations Beyond the License
License price is only the first line of the budget. Salesforce currently lists Shield at 30% of net spend and Platform Encryption at 20% of net spend, while directing customers to Salesforce sales for detailed pricing. Outside encryption vendors usually price by quote as well. The bigger differences show up in the work around each product.
Salesforce Shield costs are mostly predictable. You pay for the license, plan the encryption policy and test existing features against encrypted fields. An external key manager adds its own license. It also adds the work of running your key service with high availability, because a key outage becomes a Salesforce outage under the cache-only model.
Gateway costs are harder to predict. Gateways need their own infrastructure, built for high availability. Every integration and AppExchange package has to be tested through the gateway, and some processes need redesign. Some of that testing repeats with each Salesforce release, because changes to pages or APIs can affect the gateway.
Exit costs belong in the comparison. If you later drop a gateway, every protected value stored in Salesforce has to be converted back to plaintext or re-encrypted another way. That can be a large data project on its own. Moving away from Shield is simpler, because the data in Salesforce is already readable to the platform, although you still need to plan key retirement carefully.
There’s also a cost to missing audit tools. If you choose a gateway instead of Shield, you still need a way to answer audit questions about access and field history. That may mean licensing Shield’s monitoring tools anyway, or adding another monitoring product.
How to Choose: A Decision Framework
Start with the requirement. These questions narrow the choice quickly for most regulated teams.
• Must Salesforce never see plaintext? If a regulator or contract requires that, use an encryption gateway or tokenization for those fields.
• Do you need to revoke the cloud provider’s access to data on demand? Use Shield with cache-only keys, or a gateway.
• Do you need customer-managed key control and audit evidence? Choose the specific Shield model that fits the requirement: BYOK, EKM or Cache-Only Keys. They differ in storage, retrieval, revocation and availability behavior.
• Do users need normal filtering, sorting and reports on protected transactional data? On Hyperforce, evaluate Database Encryption where it applies. If you need field-level encryption, use deterministic encryption where exact matching is required.
• Do you also need activity monitoring and long-term field history? Shield includes both, so a gateway alone leaves a gap.
Most teams don’t need one answer for every field. A common pattern uses Shield for most regulated data, with BYOK or cache-only keys for control. A small set of the most sensitive values, such as national ID numbers that no Salesforce process needs to read, goes through tokenization. That keeps the disruptive option limited to fields where it’s truly required.
Common Scenarios Regulated Teams Face
A US healthcare SaaS company storing patient data in Salesforce usually fits the Shield path. Platform Encryption covers PHI fields, cache-only keys support the key separation HHS describes, and Event Monitoring helps with access reviews. Users keep search and reports on most fields.
An EU bank with a strict transfer assessment may need a split design. National ID numbers and account identifiers that no Salesforce process reads can go through tokenization. The rest of the regulated data can use Shield with keys held in the bank’s own key service.
An ISV selling a managed package to regulated customers has a different job. Its customers choose the encryption model. The ISV’s task is to build and test the package so it works in orgs that use Shield, and to document how it behaves behind a gateway.
Write the decision down. Auditors will ask why you chose a design, and a short record linking each field to its regulatory requirement makes that conversation easier.
Implementation Steps for Regulated Teams
A structured rollout avoids the most common problems, such as broken reports or encrypted data nobody can read after a key change.
1. Classify your data. List the fields, files and objects that hold regulated data, and note which regulation applies to each.
2. Map each field to how it’s used. Record whether the field drives search, reports, flows, integrations or AI features.
3. Choose a protection method. On Hyperforce, consider Database Encryption for broad transactional coverage, use field-level encryption when you need field-specific protection, and use third-party protection when Salesforce must not see plaintext.
4. Set your key management model. Decide among Salesforce-managed key material, BYOK, EKM and Cache-Only Keys, then document rotation, revocation and availability procedures for the model you choose.
5. Test in a full sandbox. Turn on encryption with production-like data and run every report and integration.
6. Encrypt existing data. Plan the sync of historical records, and confirm the results before you rely on them.
7. Train admins and support teams. Make sure they know what changes for users and how to handle key incidents.
Write a key incident runbook as part of the rollout. It should cover what to do if the key service goes down, if a key is suspected to be compromised and if someone requests destruction by mistake. Name the people who can act at any hour, since an encryption outage blocks users as surely as a system outage.
Run a key recovery drill before go-live. Rotate a key, then confirm that data is still readable. A key mistake can lock you out of your own data, so practice matters more here than in most rollouts.
Final Thoughts
For most regulated dev teams, Salesforce Shield is the right starting point. Platform Encryption protects data at rest while keeping most of Salesforce usable, and its key options give you strong control over keys. Adding an external key manager often closes the remaining audit gaps without moving encryption outside the platform.
Third-party encryption earns its place when Salesforce must never see plaintext. That’s a real requirement in some data sovereignty and transfer cases, but it comes with lasting costs in usability and integration work. Use it for the fields that truly need it, and let Shield handle the rest.
FAQs
What Is Salesforce Shield?
Salesforce Shield is a paid add-on that bundles security and compliance tools. It includes Platform Encryption, Event Monitoring, Field Audit Trail and Data Detect.
Is Shield Required for HIPAA Compliance?
No. HIPAA doesn’t require a specific product. Many healthcare teams use Salesforce Shield because it supports encryption at rest and activity monitoring that help meet Security Rule expectations.
What Is the Difference Between Classic Encryption and Shield Platform Encryption?
Classic Encryption is free and covers only special encrypted custom text fields of up to 175 characters. Platform Encryption covers many standard and custom fields, files and attachments using AES with 256-bit keys.
Does Platform Encryption Hide Data From Users?
No. It protects data at rest. Users with permission to read a field still see its plaintext value, so access control depends on profiles, permission sets and sharing.
What Is Bring Your Own Key in Salesforce?
Bring your own key lets you generate supported key material outside Salesforce and upload it. Depending on the Shield feature, BYOK can use customer-supplied tenant secrets, data encryption keys, root keys or other supported material, so the exact key use and derivation path varies by feature.
What Is the Cache-Only Key Service?
It keeps your key material in a key service you control. Salesforce fetches the key when needed and doesn’t store it, so revoking access at your key service stops Salesforce from decrypting the data.
What Is the Difference Between Probabilistic and Deterministic Encryption?
Probabilistic encryption produces different ciphertext each time and blocks filtering. Deterministic encryption produces the same ciphertext for the same value, so exact-match filters work.
Can I Search Encrypted Fields in Salesforce?
With field-level encryption, search can work on many encrypted fields, while filtering and sorting depend on the encryption scheme. On Hyperforce, Database Encryption preserves normal filtering and sorting for most transactional database data. With an encryption gateway, Salesforce search usually cannot find protected values.
What Is an Encryption Gateway for Salesforce?
An encryption gateway sits between users and Salesforce. It encrypts or tokenizes sensitive values before they reach Salesforce, so Salesforce stores only protected values.
When Should a Team Choose Third-Party Encryption Over Shield?
Choose an outside tool when Salesforce must never see plaintext, such as in strict data sovereignty or cross-border transfer cases. Expect more integration work and reduced platform features.
Can Shield and Third-Party Tools Work Together?
Yes. Teams can pair Shield Platform Encryption with customer-managed key options such as BYOK, EKM or Cache-Only Keys. These options use different storage and retrieval models, so the architecture should name the specific option instead of treating every external key manager setup as the same.
Does Encryption Affect Apex Code?
Apex reads encrypted fields normally for users with access. Queries that filter or sort on probabilistic encrypted fields fail, so code may need changes.
How Does Encryption Affect AppExchange Packages?
Packages that filter or sort on fields a customer encrypts may fail. Gateways can also require extra setup for packages, so test each app with encryption turned on.
What Happens if a Cache-Only Key Service Goes Down?
Salesforce can’t decrypt the protected data until the key service is available again. Plan high availability for the key service before going live.
How Much Does Salesforce Shield Cost?
Salesforce currently lists Shield at 30% of net spend and Platform Encryption at 20% of net spend. Salesforce still directs customers to sales for detailed pricing, so budget for the applicable license plus testing and any external key-management costs.
