Why Isn’t My Encrypted Data Masked?

Encryption prevents outsiders from using your Salesforce data even if they manage to get it. It is not a way to hide data from authenticated users. User permissions are the only way to control data visibility for authenticated users. Encryption at rest is about logins, not permissions.

With Shield Platform Encryption, if a user is authorized to see a given set of data, that user sees that data whether it’s encrypted or not.

• Authentication means that making sure only legitimate users can get into your system. For example, a company’s Salesforce org is only for use by active employees of that company. Anyone who is not an employee is not authenticated; that is, they are barred from logging in. If they do somehow get their hands on the data, it’s useless to them because it is encrypted.
• Authorization defines which data or features an authenticated user can use. For example, a sales associate can see and use data in the Leads object, but can’t see the regional forecasts, which are intended for sales managers. Both the associate and the manager are properly logged in (authenticated), but their permissions (authorization) are different. That the data is encrypted doesn’t make any difference to them.

In general, data can be masked but not encrypted, or encrypted but not masked. For example, regulators often require that only the last four digits of a credit card number be visible to users. Applications typically mask the rest of the number, meaning they replace the digits with asterisks on the user’s screen. Without encryption, you can still read the digits that are masked if you can get to the database where they are stored.

Masking might not be enough for your credit card numbers. You may or may not want to encrypt them in the database as well. (You probably should.) If you do, authenticated users will still see the same masked values.

In this way, masking and encryption are different solutions for different problems. You mask data to hide it from users who are authenticated but not authorized to see that data. You encrypt data to prevent someone from stealing the data. (Or, more precisely, to make the data useless if someone does steal it.)

Runtime Masking Notification

If you use Shield Platform Encryption to encrypt fields that you masked, for some fields you can encounter two types of in-field notification instead of the masking value for a field.

• When the field is encrypted but the encryption key has been destroyed
• When either the Shield Platform Encryption or the Masking service is unavailable

If either of these situations occurs, the field displays a value according to the table.

Notification values such as ????? and 01/01/1777 are strings reserved for masking notifications and can’t be used as data values in encrypted fields. While you aren’t restricted from saving a record with one of these reserved masking notification strings into an encrypted field, the field is saved with a blank value. For example, if a Date field is encrypted and you enter 07/07/1777, when you save the record, the contents of that field are empty.