Complete Guide to Salesforce Shield (Updated 2025)

Salesforce Shield is for organizations that need to meet extra security and compliance requirements. Four components make up Salesforce Shield (Platform Encryption, Field Audit Trail, Event Monitoring, and Data Detect), with encryption being the main one.

Salesforce Shield brings the Compliance & Security Team and Salesforce Admins together, helping everyone stay on the same page when it comes to critical compliance measures. Turning on Salesforce Shield doesn’t guarantee success – sure, it’s a security control, but it’s not the sole security control you need to consider.

This guide will cover the components that make up Salesforce Shield, as well as tips for getting more out of your Salesforce Shield investment – “the Shield path to value”.

What Is Salesforce Shield?

Salesforce Shield is for organizations that need extra security and compliance requirements. It comprises the following four components:

• Platform Encryption: Natively encrypt data “at rest,” i.e. when it’s stored in Salesforce data centers.
• Field Audit Trail: Tracking field changes. Retain archived field history data for up to ten years.
• Event Monitoring: User activity monitoring to prevent and mitigate threats.
• Data Detect: Scan for sensitive data and deeper insights.

As a “Salesforce Platform” product bundle, Shield’s capabilities can span across all of the Salesforce “cloud” products your organization uses to support the reduction of data risks in all areas of the business.

Salesforce Shield is an add-on product, meaning it comes at an additional cost to the typical Salesforce CRM license types. It’s worth noting that you can purchase the “full umbrella” (all four components), or each component can be purchased separately based on what suits your regulatory and business requirements.

Why You Need Salesforce Shield

Salesforce offers a first-rate service in providing infrastructure – hardware, network services, and the underlying infrastructure. However, there is a shared security responsibility model in operation. This means that responsibility is shared between Salesforce (the vendor) and your organization (the customer). The result is that any configuration/customization to Salesforce needs to be managed by the customer, and the customer is ultimately responsible for the risk that comes with that.

That’s where Salesforce Shield comes in, providing another layer of protection to help customers manage the shared responsibility model security controls.

Salesforce Shield also delivers capabilities that are not provided with Salesforce out of the box (we’ll cover these later). These are especially key for customers who have sensitive data in Salesforce and/or operate in regulated industries.

Let’s take a look at each of the components that make up Salesforce Shield.

1. Salesforce Shield Encryption

Salesforce Shield allows you to encrypt your Salesforce data with AES 256-bit encryption at the field level, as well as manage your own encryption keys. Key takeaways of platform encryption include:

• AES 256-bit: The highest level of encryption available within Salesforce.
• Encrypt data at the field level: Field-level encryption is something that Salesforce does not provide out of the box.
• At-rest encryption: Encrypts your data “at rest”, i.e. when it’s stored on disk in the data center. Data is stored as Cipher text (it switches plain text into Cipher text). This means that database agents working at the Salesforce database centers won’t be able to read your real data.
• Encryption policy: For files and attachments, this policy encrypts them in an “all or nothing” manner (i.e. not selectively according to certain files).
• Manage your own encryption keys: There are three options for managing encryption keys with Salesforce. While you can use Salesforce-generated encryption keys, customers who have a key management infrastructure in place will benefit from “bring your own key” (BYOK).

To clarify, access to records and field-level security is still controlled by the native field-level security you have determined within your Salesforce org. Therefore, platform encryption is mostly invisible to your Salesforce users – in other words, it doesn’t mask data in Salesforce (also known as obfuscating). Again, it’s just encrypted – “at rest” within the data center.

We said mostly invisible to your Salesforce users because there are nuances. For example, if you encrypt a field that is used in a report filter or list view, that can have an impact on the visibility within that specific report or list view (more on this later in the guide!).

Salesforce Key Options (+ BYOK)

As we mentioned in the encryption key takeaways, there are three options for how you can manage encryption keys with Salesforce:

1. Use Salesforce-generated encryption keys.
2. “Bring your own key”: Customers with a key management infrastructure in place can “bring your own key” (BYOK). This is common among enterprise customers, who require full control over the rotation of the keys. Establishing the infrastructure to BYOK can take some time, so customers may initially use the Salesforce-generated key to get platform encryption up and running and then migrate to BYOK.
3. Cache-only: This provides a “tunnel” over the key itself, so there’s no way that Salesforce will really be able to access it. This option is for the most security-conscious organizations. Note that there are implementation considerations that you should get clued up on.

Probabilistic vs. Deterministic Encryption Schemes

Encryption schemes apply to field-level encryption. Probabilistic encryption was the original Shield encryption scheme, with 256-bit AES encryption. Deterministic encryption (also known as Filter-Preserving) is also 256-bit AES encryption. The main difference between Probabilistic versus Deterministic Encryption is in the initialization vectors (i.e. starting variable for the encryption scheme):

A fully randomized starting variable makes Probabilistic encryption more secure. Below is a comparison table with example encryption schemes. These are two separate records in Salesforce – two different “Bobs” or “San Diegos”. You can see that the Cipher text is fully randomized, even with the same input text:

The Static Initialization Vector means that some filtering capabilities can be maintained with Deterministic encryption. In the table above, you can see that the value “San Diego” is populated in the Account city field on two separate records. Regardless of these being two separate records, the Cipher text for “San Diego” will be the same. This allows any records containing “San Diego” to be matched when using filtering capabilities.

So, yes, while Probabilistic encryption is more secure, Deterministic encryption is still secure, and a great option for its functionality benefits.

What Shield Encryption is Not

We’ve already touched on these, but it’s worth reiterating:

• It’s not whole disk encryption. Instead, Shield encryption is at the field-level, and for files and attachments. Winter ‘26 introduced the ability to encrypt the entire database (fields, Apex, custom metadata, etc) but retain full functionality.
• While data can be selectively encrypted (i.e. field by field), Shield cannot selectively encrypt files and attachments. In other words, encryption for files and attachments is binary – meaning that there’s a setting (an encryption policy) that’s either on or off, and applied to all files and attachments.

• When the encryption policy for files and attachments is enabled, all new files and attachments that are uploaded will be encrypted “at rest”. You will need to contact Salesforce support to have existing files and attachments encrypted.
• It does not obfuscate the data; data is still mostly transparent to your end users from the Salesforce UI.

Platform encryption, Data Detect, and data classification all go hand-in-hand. We’ll show you why when we explore the “Salesforce Shield path to value” later.

Salesforce Shield Platform Encryption has been extended to Data 360 (formerly Data Cloud). Summer ‘25 introduced Platform Encryption for Data Cloud by allowing support for External Key Management (EKM), giving Data 360 customers far greater control over their encryption keys.

2. Field Audit Trail

Salesforce Shield Field Audit Trail extends field history tracking for up to ten years, versus 18-24 months with Salesforce standard Field History Tracking. Both of these functions track what data changes, in which fields, when, and by which user.

Retaining field history for longer can allow you to adhere to business requirements (i.e. to refer back to historic data) or legal compliance requirements.

What’s the difference between the standard field audit trail and Salesforce Shield’s audit trail? Here’s an overview:

Field tracking policies (i.e. what, stored for how long, deleted after how long) are set up using the metadata API, which Salesforce provides out of the box.

3. Salesforce Shield Event Monitoring

User activity monitoring allows you to set transaction security policies to track user “events,” i.e. what they are doing in the system, through browsers, the Salesforce mobile app, and the Salesforce APIs. The objective is to spot and block rogue behavior in real time, thereby preventing and mitigating threats.

There are core and real-time event monitoring:

• Core event monitoring: View event streams containing different events, updated over the course of a few hours.
• Real-time event monitoring: View events happening in real-time. As an admin, when these defined activities occur, you can choose to block the user from continuing and be notified. These are defined by your transaction security policies.

Event monitoring is beneficial from both a security and a performance standpoint:

• Examples of monitoring from a security standpoint – whether they’re viewing a certain page, downloading a report, running a report with sensitive data in it, etc.

There’s a robust set of events that Salesforce provides to monitor from a performance standpoint, for example, if certain reports are taking longer to load.

Event Monitoring Example

We have a report where we know sensitive information is stored. We want to identify a user’s attempt to export 5,000+ rows of data from Salesforce and prevent them from succeeding – perhaps it’s the “high net worth contacts” report, and a disgruntled salesperson is leaving the organization soon.

When there’s an attempt to export the report, it will show the user a message that they don’t have permission, therefore blocking the export. This is recorded as an “event”, which can be monitored with analytics tools.

Event Monitoring Analytics

For reporting on Event Monitoring, Salesforce provides a CRM analytics app (pre-built dashboard), which comes with event monitoring (two licenses).

Events, such as our example with the disgruntled salesperson, are logged and shown in a variety of components. You can monitor trends by user, which reports are being downloaded, or how users are accessing certain reports.

Many customers will choose to bring that into Splunk or Qradar to align Salesforce event monitoring with other event monitoring from across their tech stack.

All events are stored in the Event Log File standard object, meaning you can run queries to do the analysis and forensics in the face of threats.

The chart below shows how Event Monitoring in Salesforce Shield works overall.

4. Data Detect

Data Detect automatically scans your Salesforce database and identifies sensitive data such as:

1. Credit card numbers
2. Emails
3. Social security numbers
4. URLs
5. IP addresses

That’s why Data Detect works hand-in-hand with platform encryption, informing what needs to be encrypted “at rest”.

Data Detect has an incredibly intuitive interface. In the example below, we’re going to:

• Define the objects we want to scan across, e.g. Accounts, Cases, and Contacts.
• Set data policies which determine the data patterns we would like to scan for, e.g. a sensitive data scan policy (Salesforce has predefined logic that will allow you to do this).
• Set which fields we would like to scan.

A common example is when support agents have added information unintentionally in the case description or comments field. How are you able to identify that?

The scan results will show you where you have sensitive data within your org that needs reviewing to ensure you’re protecting it. Below, you can see that there are different objects/fields, with 65k records that potentially have sensitive patterns in fields.

Take ​​a look by object to see, for example, these specific fields on the Account need to be reviewed and classified appropriately:

Back to the Case example – we do have credit card information stored, and we can see in specific fields which patterns have been detected. Data Detect is showing me that there are credit card numbers stored in the description field. We really don’t want this, so we need to ensure that those values are being stored in the appropriate places.

Data Detect is great for identifying where you might have sensitive data stored in those unknown places.

Note: Data Detect is a managed package. Unlike Einstein products, you don’t need a certain amount of record data for Data Detect to work accurately. Instead, it will scan based on whatever data is in your org, no matter the size of your org.

How to Implement Salesforce Shield

How you implement Shield is unique to your business, and there’s no shying away from the fact that it’s a significant investment, so you need to ensure that you’re getting full value from it.

There’s a Salesforce Shield Implementation guide containing the many considerations you need to take into account before encrypting a field. It’s a lot of work and is challenging to maintain.

The steps we outline below will help with the implementation, and more importantly, the maintenance over time.

Start with Data Detect and data classification to inform Shield Platform Encryption, ultimately, to define the extent to which you should protect data.

Step 1. Run Data Detect

Data Detect is designed to help identify sensitive data in your Salesforce org. Given that the Shield suite is all about protecting your data, it makes sense that one of the first things you should do is identify what needs to be focused on.

Data Detect is driven by Data Detect Policies. Create a Data Detect Policy by setting the start and end date (up to one year), and Data Detect will look for any added or changed data in that time. You can then specify the objects to scan, the patterns to look for (Email, Credit Card, etc), and configure which fields you would like to scan and which you don’t. 

Once your scan has run, you can head over to the Results tab to see what Data Detect has identified in your org that you may need to action using other Shield tools.

Step 2: Platform Encryption

Platform Encryption has a few key steps (you’ll understand shortly why ‘key’ steps are funny). The first thing you need to do is assign the correct permissions. The way you do this is by creating Permission Sets and granting them to the users who require them. 

Create a Permission Set that contains the Customize Application and Manage Encryption Keys permissions (See, keys! Now you get why it was funny!). Manage Encryption Keys gives the ability to manage the tenant secrets that will ‘unlock’ your encrypted data, so to speak. This Permission Set needs to be granted to users who will manage the tenant secrets, so be careful to make sure that only those who require it have access to it. 

Next, you’ll need to generate the tenant secret – again, these are used to derive your keys, so they must be protected at all costs, which is why we limit who has access to this functionality. To create the secret, you need to ensure you’ve granted yourself the Manage Encryption Keys permission using the Permission Set you just created, then go to Key Management. Here, you’ll have the option either to have a Tenant Key generated or Bring Your Own Key.

In this example, I’ll continue with the built-in key generation functionality, but your business may need to click the Bring Your Own Key button if you intend to supply these yourself. Notably, you can only do this once every 24 hours, so make sure you’re clear on whether you need to generate a key or use your own.

Now that you have a new key generated, you need to secure it. This can be done using the export functionality. In the table on the Key Inventory and Management page (Key Management in Setup), you’ll see an Export button next to each line. Clicking this button will download the key to your local computer as a text file. Store this key in a secure location, where you will be able to find it but others won’t.

Think of your secret like a password – it is good practice to change it relatively frequently. You can do this by generating a new key, which automatically archives the old generated key. 

Finally, the fun begins. Now that you’ve got a secret set up, you can begin encrypting your data and files. In Setup, head over to the Encryption Settings page, and scroll down to the Advanced Encryption Settings section. Here, you’ll see the Encrypt Standard Fields section. You can click the Select Fields button to mark the fields you’d like to be encrypted.

On the next screen, you’ll see a list of Objects and their related Standard Fields that you can encrypt. Click the Edit button and select which ones you’d like covered by Shield Platform Encryption.

Once you’re done, you can also consider encrypting other data like Chatter, Files and Attachments, Search Indexes, and Custom Fields in Managed Packages. All this can be done from the Encryption Settings page, but you’ve got the basics down at this point! 

Step 3: Field Audit Trail

While some of the interfaces that we just navigated when enabling Shield Platform Encryption probably need to see a fresh lick of paint, the Field Audit Trail UI is missing entirely and requires you to use the Metadata API.

Unfortunately, this means that it isn’t so admin-friendly. There are tools out there that will make this process easier, but for now, I wanted to identify what you need to create in terms of metadata (XML) and deploy into your org, as this is how most Salesforce customers will need to do things.

Luckily, once you’re comfortable working with metadata directly in its XML format, there are just four values that you need to set per object that you wish to track via Shield Field Audit Trail.

The first is archiveAfterMonths, which requires a whole number between 1 and 18. This is the number of months that you wish to keep the field history data before it is archived. Salesforce sets this value to 18 by default.

The second is archiveRetentionYears, which requires you to set a number in years that you will manually delete the data (this is a MANUAL deletion, so this field is to be used as a reminder).

The third is description, and is like any other description field in Salesforce. Provide a description for the Retention Policy. 

Finally, provide a value for the gracePeriodDays – the number of days after the archiveAfterMonths period before the data is archived, and applies only to the first archival. This gives your administrator extra time to get the data ready before the first archive. By default, this value is set to 1, but can be set to any number between 1 and 10. 

Knowing all of this, how can you apply it without a UI? And where are these values set? Great questions (if I do say so myself)!

Using the Salesforce CLI, you can retrieve your Object XML files and apply these values to them. An example of what it may look like on a Custom Object is as follows.

<?xml version="1.0" encoding="UTF-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
  <historyRetentionPolicy>
    <archiveAfterMonths>12</archiveAfterMonths>
    <archiveRetentionYears>3</archiveRetentionYears>
    <description>Application History Retention.</description>
    <gracePeriodDays>5</gracePeriodDays>
  </historyRetentionPolicy>
~~the rest of the XML file~~
</CustomObject>

Salesforce’s Field Audit Trail Implementation Guide gives additional information and examples about the steps to properly enable and set up Field Audit Trail.

Step 4: Event Monitoring

Back to the land of clicks instead of code (or command line), it’s time to enable Shield Event Monitoring. 

First, just like with Platform Encryption, you’ll need to create a new Permission Set. Give it a name like “View Event Monitoring Data”, and give it the View Real-Time Event Monitoring Data permission. 

Then, head over to the Event Monitoring Settings page in Setup and turn on Generate Event Log Files. From here, head to the Event Manager page in Setup to configure the events you wish to track. In my example, I enabled Login Event, LoginAs Event, Logout Event, and List View Event. 

Salesforce itself recommends that you leverage a tool called Streaming Monitor from the AppExchange to view your event logs. You can install this from the AppExchange. Once installed, you can use it to filter and view your events as they occur. 

Salesforce Shield Pricing

Salesforce Shield is an add-on product, meaning it comes at an additional cost to the typical Salesforce CRM license types. As opposed to the typical per-user, per-month pricing, Shield pricing is calculated as a percentage of your total Salesforce spend, making it a fairer pricing model for small to medium organizations.

Up-to-date Salesforce Shield pricing can be found on Salesforce’s official pricing page.

Again, note that you can purchase the “full umbrella” (all Shield components), or each component can be purchased separately based on what suits your regulatory and business requirements.

How Do I Know if I have Salesforce Shield?

1. Quick find search: In Salesforce Setup, use the quick find box to search for “platform encryption”. If you see the option appear, this confirms you have Shield.
2. Check your Salesforce licenses: Alternatively, in Salesforce Setup, navigate to Company Information. Check if you have the “Salesforce Shield” license by hovering over “User Licenses”.

Options for Masking Salesforce Data

As we’ve said, Salesforce Shield platform encryption encrypts data “at rest” i.e. when it’s stored in the data center.

Going forward, the best practice to hide sensitive data from users, is field-level security, i.e. defining which fields are readable/editable for which users.

Most third-party Salesforce backup providers have “sandbox seeding” capabilities, which will mask or randomize data when it’s transferred from the production org to sandboxes. Salesforce itself also offers Data Mask & Seed to serve this purpose.

If you want to mask (obfuscate) data from Salesforce users viewing data within the Salesforce interface, you will need to look for another option.

Getting Skilled Up on Salesforce Shield

How much of a learning curve is there for a Salesforce Admin getting started with Shield?

Security is a separate domain, so there can be a significant learning curve. That’s why we’ve explored additional tools to guide you as you get started. It’s important to identify partners with plenty of domain expertise.

Having said that, Salesforce Shield is a fantastic opportunity to bring the Compliance & Security Team (CISO) and Salesforce Admins together, helping everyone to get themselves on the same page when it comes to critical compliance measures.

As well as this guide, there are great resources provided by Trailhead. Employees of Salesforce partners can achieve the Security & Privacy professional accreditation that covers Salesforce Shield alongside the Salesforce Privacy Center.

Final Thoughts

If you’re still wondering, “Why do I need Salesforce Shield?”, it’s worth keeping the following points in mind:

• As always, aim to do it right the first time. It’s certainly not a set-and-forget process; you need to implement Shield and then maintain it over time. You don’t want to waste your (or your security team’s) time protecting medium or low-risk information.
• Data classification is a great way to help guide your Shield efforts, whether it’s for fields you need to encrypt, fields you need to track, or, if event monitoring, knowing where to monitor in the first place.
• Event monitoring or data classification is effective for making sure that you’re taking an efficient approach to Shield, while protecting all of your most sensitive information within the org.