
Information is an extremely important resource for a modern business. A lot of people claim that data has already become the sole most valuable resource a company can have. Unfortunately, cybercriminals understand that fact just as much as businesses — with the number of data breaches rising at an alarming pace each year.
Every single instance of a data breach directly translates into substantial damage to the company’s financial and reputational state. In 2023, the average cost of a data breach incident worldwide was $4.45 million USD — including not only the value of compromised data but also the cost of detection, notification, and post-breach actions.
Continued investment into various security systems and methods can be expensive — but the potential losses from ongoing data breaches are far higher than practically any investment into a company’s security stance. The same logic also applies to non-standard environments such as Salesforce since it is not uncommon for CRM systems to store personal customer information or some other form of sensitive data that cybercriminals may target.
There are plenty of different security measures that can be implemented as a safeguard for sensitive information — including backup systems, multiple storage types, access control systems, and more. Encryption is also one of these security measures, and it is also the primary topic of this article in the context of Salesforce environments.
Data encryption in Salesforce
The basic act of encryption is a process of transforming specific information (with an encryption key) into an unreadable random sequence of symbols — with the ability to restore the information’s original form using something called a decryption key. These encryption keys are an important element of any encryption process, and the correct key management is an integral element of encryption-related security efforts.
Encryption itself is typically separated into two large groups that differ from each other significantly depending on the state of the encrypted information. The data itself can be either in transit or at rest. In specific environments such as Salesforce, data in transit is automatically covered using a TLS encryption protocol with no additional inputs from the end user.
Data encryption at rest, on the other hand, is a much more delicate topic in this context, with multiple approaches and features to consider. The Salesforce platform can offer two primary approaches to data encryption:
- Classic
- Shield Platform
Both options have their own use cases, but the general consensus is that Classic is the least expensive option for encrypting specific information, while Shield Platform is a more secure measure that can also be more financially demanding on the company’s budget.
We are going to provide a detailed look into each of these methods below. Before that, however, it would be fair for us to mention the possibility of encrypting information with Crypto Class to create completely custom cryptography scripts with Apex — Salesforce’s programming language.

Crypto Class
Crypto Class is technically better than Classic encryption in the same environment and can even be used to add specific advanced features to the encryption process. However, this method is not considered a competitive alternative to the other two options in our example due to several reasons:
- The possibility of creating a technical debt due to the fact that the script in question would have to be updated and maintained on a regular basis to keep up with Salesforce’s platform updates and new features.
- The complete dependency of the end result from the technical capability of the person or persons responsible for creating such encryption scripts.
- The development process for one such script might also take a long time, considering both the complexity of the endeavor and the necessity to adapt to newer Salesforce releases as time goes on.
- Predicting the cost of such a script is very difficult since it depends completely on both the number of features necessary and the overall proficiency of the code creator.
Now that we have some context for why there are only two options to choose from when it comes to encryption in Salesforce, it is time to move forward with explaining what each of these options entails.
Classic encryption
Classic encryption is the basic security measure from Salesforce that is available to all Salesforce users for free as part of their license.
The advantages of Classic encryption
It is simple and easy to use, providing the capability to either encrypt or mask specific information such as PII or other types of sensitive data. After the information has been encrypted with Classic encryption, it can only be viewed by users with the “View Encrypted Data” permission in Salesforce.
The solution is available in both versions of Salesforce’s interface and all the paid pricing plans. It does not require additional purchases to be performed, and its overall effect on the system performance is primarily low.
The shortcomings of Classic encryption
However, Classic encryption also does have a number of limitations that prevent it from being useful in many situations:
- Capability to encrypt up to 175 characters at a time.
- Does not support encryption for standard fields.
- It can only be turned on for newly created custom fields; it cannot convert existing fields into encrypted ones.
- Does not work in Workflow Field Updates or Workflow Rules.
In my personal opinion, Classic encryption is a great solution for most standard encryption methods. Still, its limitations prevent it from being useful in most situations that require a more serious and delicate approach to protecting sensitive information.
Shield Platform encryption
Salesforce Shield Platform encryption is several steps above anything Classic encryption can offer.

The advantages of Shield Platform encryption
Not only is it a step above in the encryption security as a whole (AES-256 vs AES-128), but there are also multiple additional security-related measures that dramatically improve the security of encrypted data.
Shield Platform supports BYOK (Bring-Your-Own-Key) as a security measure, making it possible for each customer to manage and use their own encryption keys for improved security and better key management. It does have a separate price tag for most Salesforce users (the Developer Edition users are the only exception), but its usage is practically mandatory in many industries with strict compliance regulations — including the government, healthcare, financial, and other fields.
The Platform also offers a selection between two encryption types:
- Probabilistic is used in Shield Platform by default; it does not allow for filtering to be performed, and it would also prevent any kind of location for the encrypted information (such as the “Where” SOQL query) due to the fact that each record is encrypted into a random string of symbols each time the encryption process is performed.
- Deterministic is a direct alternative to the aforementioned encryption type; it does allow for the location of the information in question, but all of the underlying fields under the encrypted data are going to be encrypted accordingly (a less secure option than probabilistic but secure nonetheless).
Other capabilities of the Shield Platform include validation rules, search, lookups, and the ability to apply encryption to both standard and custom fields without the necessity to create a new field each time.
The shortcomings of Shield Platform encryption
At the same time, there are some limitations and unique characteristics of Shield Platform that make it challenging to use in certain situations. For example:
- The platform refuses to work with specific third-party applications (Heroku, Thunder, Quip, and more), which is a massive issue for Salesforce with its wide range of integrations.
- It requires an additional price to be paid for its services on a regular basis — up to 30% of a company’s Annual Contract Value (ACV), depending on the feature set necessary.
- Unlike Classic, Shield Platform does not have the ability to provide Data Masking as a feature, stating differences in use cases as the primary reason (Salesforce does have a separate Data Mask solution for these exact situations, which also has a separate price tag).
- The overall setup process for Shield Platform encryption can be somewhat challenging for less experienced users (although most of this process covers the creation of a tenant secret with which to encrypt information).
Direct comparison of Classic and Shield encryption approaches
In the table below, we have tried to highlight the most notable differences between the two solutions while also mentioning a few common features.
Feature | Salesforce Classic | Salesforce Shield Platform |
Pricing | Part of the base license | Separate price tag |
Native Encryption at Rest | Yes | Yes |
Encryption Algorithm | 128-bit Advanced Encryption Standard (AES) | 256-bit Advanced Encryption Standard: AES CBC, AES CTC |
Manage Permissions for Encrypted Keys | No | Yes |
Generate, Export, Import, and Destroy Keys | Yes | Yes |
Advanced Key-related Features | No | BYOK, Cache-only Keys, EKM |
Compliance with PCI-DSS L1 | Yes | Yes |
Data Masking | Yes | No |
Standard Field Encryption | No | Limited (Email, Mobile, Phone, First Name, Last Name, Comment, and many others) |
Encrypted Attachments | No | Yes |
Custom Field Encryption | 175 characters limitation, dedicated custom fields need to be created | Limited (Email, Phone, Text Area, Date, URL, etc.) |
Encryption for Existing Fields (for supported field types) | No | Yes |
Search, Filters and Queries | No | UI, Partial Search, Lookups, Certain SOQL Queries depending on the encryption type |
Can be used in Workflow Rules | No | Yes |
More information on the topic of encryptable standard fields can be found on the dedicated Salesforce page.
It should also be noted that encryption is not the only security measure applicable to environments such as Salesforce — there are also backups, disaster recovery strategies, permission management frameworks, and more. Interactions between these systems may cause system slowdowns and other inconveniences when planned incorrectly.
Luckily, there is an entire market for comprehensive backup and recovery solutions for Salesforce that can offer seamless integration into Salesforce with many data security and management features — including backups, archiving, and more.
GRAX is a good example of such a solution, offering a comprehensive feature set that can assist with the productivity of a Salesforce environment while also boosting its security stance on top of everything the platform in question can already offer. It is compatible with both Classic and Shield Platform encryption types and extends its capabilities, offering the best of both worlds when it comes to data security in cloud environments.

The performance and security effects of encryption measures on backup tasks
While we are on the topic of Salesforce backup tasks, we should also go over an interesting topic of how encryption measures can affect regular backups for both Classic and Shield Platform approaches.
With Classic encryption, the result of a backup is going to depend entirely on the permission range of the user account performing the data exporting process. If the account in question has “View Encrypted Data” permission, all the encrypted information will be backed up in its decrypted form. In any other case, the information would remain encrypted, redirecting the user to pull random data instead of information they wanted to receive.
Shield Platform encryption, on the other hand, exports all information in a decrypted format from the get-go, performing the decryption process using the existing tenant secret. It should be noted that backing up the tenant secret key is also recommended for Shield Platform users since it is the only way to access information encrypted with it, and all of the encrypted information is going to be lost forever if the tenant secret is destroyed.
Best encryption-related practices for Salesforce
Encryption is practically a necessity for any organization in a modern environment, but it can still be somewhat challenging to pick a single option and implement it in your current environment. We can offer three primary categories of best practices that can help with this choice:
Figure out what encryption type to choose
The primary categories of use cases for Classic and Shield Platform encryption types should be obvious by now, but we are still going to mention them for the sake of article continuity.
Classic encryption can easily cover most of the basic encryption needs with limited protection capabilities. It does not offer the flexibility to encrypt attachments and platform events, but it would be enough to encrypt a small subset of sensitive information in a company that falls under a limited number of compliance or regulatory frameworks.
Shield Platform encryption is an enterprise-grade encryption solution that works at its best in industries with many drastic compliance regulations, such as healthcare or finance. Its encryption coverage is a lot more significant, the ability to provide end-to-end encryption dramatically improves the security of information, and the support for BYOK brings even more control over the encryption key management into the hands of the end user.
Is Your Salesforce Data Secure?
Ensure protection of sensitive Salesforce data easily with GRAX.
Implement the chosen encryption type
As the encryption type is chosen, the burden of implementation is the next logical step. The exact sequence of events would differ in many cases, but we can still provide a number of recommendations that outline the general order of steps that should be taken.
- Sensitive data identification would be the first logical step, as the proper understanding of where the sensitive information is located should dramatically reduce the difficulty in encrypting this information in the future.
- Always encrypt the “Core” fields and records that are known to store sensitive information — credit card details, medical information, physical addresses, Social Security numbers, etc. This logic is applied to both Classic and Shield Platform encryption types.
- Use Sandbox environments for testing, considering that Salesforce has its own sandbox setup that can be used to test planned encryption methods before applying them to your database.
- Check for compatibility issues with backup systems and other environments with potential overlap. Performing a regular restoration process for testing purposes would also go a long way toward ensuring that all backups can be restored intact without losing their security measures.
We would also recommend planning your BYOK implementation as early as possible, as well, considering how important key rotation, storage, and revocation processes are in such cases. However, this piece of advice would only be applicable to the Shield Platform encryption, which is why it was not put on the list above.
Audit and review the results of the implementation

Similar to how most modern security measures work, encryption is not something that can be set once and never touched again. Conducting audits on a regular basis and monitoring the encryption processes is essential to ensure the safety and security of your Salesforce environment
Encryption audits are necessary to ensure that the encryption processes cover all of the necessary data elements — be they fields or objects. Even something as basic as Salesforce’s built-in reporting capability can help check what information is getting encrypted and what isn’t.
User access to encrypted data should also be monitored on a regular basis while keeping an eye out on suspicious behavior — unauthorized data sharing, suspicious data downloads, and so on.
Compliance requirements should also be reviewed regularly, considering how many issues a single misstep can bring to a company — with extraordinary fines, massive reputation losses, and even potential lawsuits.
While these recommendations might not cover the entire scope of needs that a company might have in regard to its encryption strategies, they should still serve as a great starting point to work off of, especially in the long run.
Conclusion
The demand for data security is only going to keep growing from now on. In this context, security measures such as encryption become more and more valuable to any business. Yet, applying such measures in a correct manner can be surprisingly challenging since there are multiple encryption types to choose from and plenty of nuances to keep track of.
In this article we went over the intricacies and nuances of data encryption in Salesforce, covering both Classic and Salesforce Shield as encryption methods and comparing the two with each other. A number of best practices for encryption process were also highlighted, including key storage, implementation recommendations, and more.
We have also highlighted the importance of encryption as a cog in a much bigger system of data security alongside backup tasks and other processes. Solutions such as GRAX are specifically made to integrate deeply into multiple Salesforce systems to make sure that none of the built-in capabilities, such as encryption, are disrupted or negatively influenced in some other way. Protect your Salesforce environments without worrying about compatibility issues by contacting GRAX today.
Ensure End-to-End Salesforce Data Protection
Encrypt, protect, control – elevate your Salesforce security with GRAX!
Frequently Asked Questions
Can encryption affect the overall performance of Salesforce environments in a meaningful way?
The majority of day-to-day operations in Salesforce should not be affected by neither of the encryption methods in a significant fashion, but minor drops in performance are to be expected in specific areas – including search operations, reporting, analytics, and bulk data operations.
It should be noted that the overall performance of encrypted fields might differ substantially depending on the frequency of the encrypted fields being accessed, the total volume of encrypted fields in the environment, and the complexity of operations performed with encrypted information.
Is it possible to set up an encryption key rotation without external key storage appliances?
Shield Platform’s support for BYOK leaves this entire choice up to the end user — they can choose between built-in encryption key storage capabilities and external options.
Is it still possible to use encrypted data in dashboards or reports in Salesforce?
The answer to this question depends completely on the type of encryption used. Probabilistic encryption completely disables the ability of encrypted data to be searched or filtered, but deterministic encryption still allows the fields themselves to be highlighted and reported on.
Can Salesforce encryption affect the platform’s integration with third-party applications and solutions?
Yes, external integrations can be affected by data encryption processes if the integrations need to have access to such information in the first place. If the solution in question is not fit to handle deterministic/probabilistic encryption of Shield Platform, then the entire integration might just stop working completely.
How difficult is it to transition from Classic to Shield Platform encryption?
The process itself is not particularly complicated. The only difficulty in this process (aside from setting up Shield Platform) would be in the necessity to decrypt all of the information secured with Classic encryption since the two types are not directly compatible.