16 Reasons to use Third Party Cloud Security and not Salesforce Shield

tl;dr: Salesforce Shield has a hefty price tag on top of the SFDC license, despite offering limited protection within Salesforce and zero protection to other applications.

As mentioned in our last post, cloud service providers typically offer only baseline protection in a shared responsibility model. Salesforce Shield is no different. That means your organization has to assess what security gaps there might be and, if anything goes wrong, you’re still on the hook. There’s an expression in German that roughly translates to “those who buy cheap, buy twice.” With Shield you already buy expensive the first time around and still end up with gaps that will require you to “buy twice” and find additional solutions to fill those gaps.

To give you a better understanding, here are 16 reasons why you should use third party cloud security and not settle for Salesforce Shield:

Sponsorships Available

Sponsorships Available

Sponsorships Available

1. With Shield, you are fully responsible for backing up data and tenant secrets.

That means you have to figure out how you’re going to backup your keys and carry the associated costs.

2. Existing data is not automatically encrypted when you activate Shield.

Furthermore, all data that is imported or created is arriving in Salesforce in clear text and is only encrypted later. This presents a major yet wholly unnecessary gap in the security of sensitive data . 

3. Salesforce Customer Support may see protected data in plaintext if granted login access.

Sensitive data should only be exposed when absolutely necessary and for support operations this is hardly ever the case. 

4. Some custom fields can’t be encrypted by Shield.

This includes fields that have a “Unique” or “External ID” attribute, fields on external data objects, fields that are used in an account contact relation, etc. There’s no reason for this. As the platform owner, Salesforce should be able to support custom field protection, no matter if it’s account related or not. 

5. Shield can’t encrypt standard fields if portals are activate.

You actually have to deactivate all customer and partner portals if you want to encrypt standard fields with Shield. Another unnecessary inconvenience. If there’s access to the data stream, which is most often the case, then there’s no reason why you’d have to deactivate all your portals. 

6. Shield can’t identify duplicate accounts and contacts when they’re encrypted.

If you’re using deterministic search, then you shouldn’t have trouble locating duplicates, even when the data is protected. This is yet another scenario where you shouldn’t have to compromise on security for a basic function like merging duplicates. 

7. Bounce processing doesn’t work if you encrypt the standard email field.

Email addresses are contact information and in many cases even contain the name of the person who owns the account. That’s not data you want to leave exposed, and bounce processing is an essential part of managing a contact database. You really shouldn’t have to choose one or the other.

8. Campaign member search isn’t supported when you search by encrypted fields.

Again, with Salesforce claiming searchability with deterministic encryption, this should actually work everywhere. 

9. Reports charts and dashboard components that display encrypted field values might be cached unencrypted. 

Hard to say for certain as an outsider, but could this mean that Salesforce caches data in the clear when running charts and dashboards? One would hope not. 

10. Shield’s self-service background encryption doesn’t support description fields, long and rich text area fields, and other data elements such as files and attachments. 

These are standard data field types that any decent cloud security solution should cover.

11. Self-service background encryption can encrypt data once every seven days.

Presumably this means that data might be left unprotected for six days. With a third party solution, you can ensure that sensitive data is only provided to Salesforce in a protected state, which eliminates this and the following vulnerability:

12. Encryption doesn’t run while statistics are being gathered. 

Does this mean that if your run stats on sensitive data, Salesforce needs it to be in the clear before producing the statistics and Shield only protects the data afterwards? Do you want to risk that possibility? If not, it’s better to only provide Salesforce with sensitive data in a protected form. 

13. Encrypted fields can’t be used in criteria-based sharing rules, external lookup relationships, or filter criteria for management tools.

So if you want to have a rule like “customers that spend more than 10k annually and live in zip code XYZ” while keeping the zip code of individuals protected, does that mean you’re out of luck?   

14. Web-to-case is supported, but the Web Company, Web Email, Web Name, and Web Phone fields are not encrypted at rest. 

Those are considered PII so there’s another gap you’ll have to fill. 

15. Deterministic encryption isn’t available for custom data, date/time, long text area, rich text area, or description field types. 

Any cloud security solution worth its salt allows deterministic and/or format-preserving encryption for these types of data.

16. With SecurDPS from comforte, you don’t have to worry about any of the above. 

SecurDPS only provides data to Salesforce in a protected state without forcing you to compromise between security and functionality. To learn more, download the SecurDPS Connect fact sheet below or feel free to send us a message.