There are two options for encryption in Salesforce Marketing Cloud: Transparent Data Encryption (TDE) also known as Data At Rest Encryption and Field Level Encryption (FLE) also known as Encrypted Data Sending (EDS).
Transparent Data Encryption (TDE)
Transparent Database Data Encryption, also called TDE, uses a feature of SQL Server to encrypt the entire database transparently. This feature stores the entire database in an encrypted format at rest at the file level. This feature will prevent someone with physical access to the database or a backup copy of the database from mounting it on another SQL server instance and accessing data. TDE involves minimal performance implications and no loss of functionality. TDE uses AES-256 encryption to generate the key.
Transparent Database Data Encryption is also known as Data at Rest Encryption as it encrypts the underlying files stored in the file system. On the Marketing Cloud application, you will not notice a difference whether or not Data At Rest Encryption is used because this feature is transparent to Marketing Cloud.
Some caveats to Transparent Database Data Encryption (TDE)/ Data At Rest Encryption:
- If your environment is on a shared database, you will be assigned a new MID.
- You can only apply TDE/Data At Rest Encryption to your existing MID if you are on a dedicated database
- Transparent Database Encryption/Data At Rest Encryption can only be implemented by Salesforce
Field-Level Encryption (FLE)
Field-Level Encryption (FLE), on the other hand, is encryption of data at the field level on the actual application layer. Data is encrypted using a cryptographic symmetric key generated via Encryption Key Management where both a key value and initialization vector (IV) is required when using encryption keys. Field-Level Encryption (FLE) was previously known as Encrypted Data Sending (EDS)
Field-Level Encryption (FLE) can only be enabled on new accounts.
How Does Field-Level Encryption Work?
Data extensions that contains encrypted data needs to be created in Contact Builder. Any email address fields are required to be encrypted. When the data extension is created in Contact Builder, you’ll see a checkbox available that enables encryption next to fields with the datatype of text and/or email address.
Under Key Management in the Admin section is where you’ll need to create your symmetric key using a 64-character hexadecimal string — Marketing Cloud supports AES-256 encryption. The Initialization Vector (IV) will also be created under Key Management (using a 32-character hexadecimal string).
Drawbacks With Using Field-Level Encryption
- If you have more than one business unit, you will need Field-Level Encryption (FLE) on all business units.
- Segmenting, filtering, or querying encrypted fields is not supported
- Which means you cannot use Data Filters
- When using SQL queries, you cannot use WHERE clauses on those encrypted fields
- Field-Level Encryption (FLE) cannot be turned off once enabled
- List-based sending is not supported — only data extension sends is supported
- Data relationships are not supported using Field-Level Encryption (FLE)
- Standard email domain reporting is not supported since the any email address field is encrypted (domain is stored as @exct.net)
- Default values are not supported for encrypted fields
- Triggered send API can only decrypt email address fields
- Transactional Messaging API is not supported when using Field-Level Encryption (FLE)
Compatibility With Salesforce Shield and Field-Level Encryption (FLE)
When using the Marketing Cloud Connector the process automatically decrypts the data from Sales/Service Cloud and as the data arrives in Marketing Cloud, those fields are encrypted using Field-Level Encryption (FLE).
Supports Platform Encryption:
- Synchronized Data Extensions — Marketing Cloud encrypts the fields identified as encrypted using Platform Encryption.
- Reports and Campaign Sends — Again, utilizing Marketing Cloud Connector, report and campaign sends can be performed directly from Sales/Service Cloud.
Does Not Support Platform Encryption:
- Journey Builder Events — Data is not re-encrypted via events. You will have to query Synchronized Data Extensions and use a Data Extension as the entry event to keep the encrypted fields (though see the limitation above about using a WHERE clause on those encrypted fields)
- Automation Studio Imports — Data is not re-encrypted via import from Automation Studio. Again, Synchronized Data Extensions is your alternative to sync Salesforce Objects.
What Are The Differences?
The main difference between Field-Level Encryption (FLE) and Transparent Database Encryption (TDE)/Data At Rest Encryption is that Field-Level Encryption (FLE) is on the application layer.
In other words, Transparent Database Encryption (TDE)/Data At Rest Encryption can be enabled or disabled and you would not even notice the difference when using Marketing Cloud.
Field-Level Encryption (FLE) comes with its’ challenges when trying to use on a day-to-day level because of all the limitations mentioned above. For example, running a SQL query with a WHERE clause on a text field that is encrypted is not possible. Using a Salesforce Data entry event in a Journey does not keep the data encrypted.
Depending on your business case, Transparent Database Encryption (TDE)/Data At Rest Encryption may be suitable with the combination of only syncing fields that are not sensitive from Sales/Service Cloud. If security and encryption is something that is not taken lightly, then Field-Level Encryption (FLE) may be a suitable option even considering the limitations.