Hardening Salesforce Security With Encryption at Arm’s Length

Salesforce is the operational backbone for many organizations, powering customer data, sales pipelines, and core business processes. But as more sensitive and regulated information moves into Salesforce, the risks of misconfiguration, insider threats, and unauthorized access are growing.

In June 2025, security researchers uncovered over 20 critical configuration flaws in Salesforce environments, exposing sensitive data, even within organizations with mature compliance programs. These findings underscore the importance of reassessing how Salesforce environments are secured.

This article takes a closer look at Salesforce’s native encryption options, Classic Encryption and Shield Platform Encryption, and explains why relying solely on these tools may fall short of today’s security and compliance demands. We then explore how StratoKey’s Cloud Data Protection (CDP) platform, with its “encryption at arm’s length” approach, offers a compelling and robust alternative for protecting your most sensitive Salesforce data.

The Changing Threat Landscape in Salesforce Environments

Salesforce offers a suite of security tools, including field-level encryption, user access controls, and monitoring via their Shield product and add-ons. However, recent research shows that even well-configured environments can be vulnerable. A June 2025 report found that common misconfigurations, such as overly permissive sharing rules, insecure integrations, and insufficient audit logging, can leave sensitive data exposed to unauthorized users or external attackers.

This highlights the urgent need for organizations to go beyond default settings and adopt layered security strategies that provide the flexibility, control, and coverage to meet specific regulatory and security requirements.

Beyond "Built-in" Encryption: The Limits of Native Salesforce Security

Salesforce offers two primary encryption solutions: Classic Encryption and Shield Platform Encryption. While both enhance data security, each comes with security and flexibility tradeoffs that organizations must carefully consider.

Salesforce Classic Encryption

Salesforce Classic Encryption is included in all paid Salesforce plans and is straightforward to use, allowing basic encryption or masking of specific custom fields. It uses 128-bit Advanced Encryption Standard (AES). Classic encryption does have key limitations:

• Can only encrypt custom fields (not standard ones), and is limited to 175 characters per field.

• Encryption is not retroactive; existing data remains in plain text until updated.

• Incompatible with workflows, attachments, and formula fields.

• No advanced key management or external storage support.

• Encrypted fields may limit reporting, search, and filters.

Salesforce Shield Platform Encryption

Salesforce Shield Platform Encryption is Salesforce’s advanced, paid security suite designed to help organizations meet regulatory and compliance requirements. It provides AES-256 encryption and supports both probabilistic and deterministic encryption modes:

• Probabilistic encryption offers stronger security by generating unique ciphertexts for the same input data, but limits filtering and searching.

• Deterministic encryption allows exact-match searches, sorting, and filtering, but introduces slightly weaker security and functionality constraints.

Shield Encryption provides two main encryption paths:

1. Field-Level Encryption (FLE)

FLE encrypts specific standard or custom fields at the application layer before data is stored in the database. It’s ideal for securing highly sensitive fields such as Social Security Numbers, health data, or credit card information. FLE is also compatible with Bring Your Own Key (BYOK) configurations, offering greater control over encryption key management and auditability.

However, FLE also introduces notable limitations:

• Not all field types are supported (e.g., formula fields, long text, and external IDs).

• Encrypted fields can restrict filtering, sorting, reporting, dashboards, and declarative tools, particularly with probabilistic encryption (the more secure option).

• If deterministic encryption is used for FLE, it enables limited filtering and exact match searching. 

• Compatibility gaps exist with many Salesforce-native and third-party integrations (e.g., Heroku, Thunder, Quip).

• Some report charts and dashboard components may cache encrypted values unprotected. This behavior can lead to potential exposure of sensitive data in plaintext within these components.

2. Database Encryption

Database Encryption is available to customers on Hyperforce who have Shield or Platform Encryption licenses. It encrypts most Salesforce data at rest, including metadata and Apex code, using tenant-specific keys. Unlike FLE, this encryption happens at the storage layer.

There are several key limitations to this approach:

• Keys cannot be stored outside Salesforce (no external KMS support)

• Encryption occurs within Salesforce’s infrastructure, exposing key material to the platform.

• Provides less control and auditability compared to FLE with BYOK, as Database Encryption encrypts broadly at the storage layer with no logging or policy enforcement tied to specific fields or operations, which limits both visibility and control.

• Database Encryption does not offer field-level event correlation, and logs related to encryption operations are not exposed to the tenant.

• Doesn’t encrypt data in transit or during application-layer processing (risk from logging, and internal access paths that occur before data hits the database).

Trade-Offs and Considerations between Salesforce Database and FLE

While both FLE and Database Encryption extend beyond Classic Encryption in terms of coverage and control, they each come with trade-offs. Organizations can combine them to achieve greater security benefits, using FLE to protect and get visibility of the most sensitive data, and Database Encryption to apply broad protection across the organization. As detailed, both have limitations.

Neither approach achieves true “encryption at arm's length”, as Salesforce retains access to encryption keys and performs cryptographic operations within its infrastructure. 

StratoKey’s “Encryption at Arm’s Length” Approach

The concept of “Encryption at Arm’s Length” refers to keeping encryption keys and cryptographic operations outside of the direct control of the SaaS provider or cloud platform.  This approach is gaining attention due to increasing concerns about insider threats, third-party breach risks, and government data requests (e.g., CLOUD Act).

Read more: Data sovereignty and U.S. technologies: what to consider.

So, how does encryption at arm's length relate to Salesforce Shield Platform Encryption?

While Salesforce Shield Platform Encryption with BYOK (Bring Your Own Key) offers customers more control over their encryption key management, it does not achieve “encryption at arm’s length” as defined by most security standards. This is because the cryptographic system is managed by Salesforce, and the key (or use of) is exposed to the Salesforce system. The table below details the main differences.

While Salesforce Shield is a substantial step up from Salesforce Classic Encryption, it does not provide encryption at arms length, and it still leaves security and compliance gaps, especially for organizations that:

• Require flexibility over control of encryption keys.
• Need to integrate with a broad suite of apps (not just Salesforce).
• Need to ensure encrypted data is never exposed, even in the event of a Salesforce misconfiguration or privileged access.
• Need to ensure internal Salesforce team members (such as support staff) cannot access unencrypted data.
• Need to onshore data to meet data sovereignty or data residency requirements with tokenization.

For these scenarios, StratoKey's Cloud Data Protection (CDP) platform is optimal. The CDP platform can deliver the extra assurance and compliance coverage that is not available natively in Salesforce. 

The key feature is that encryption and decryption occur outside of Salesforce (as illustrated above). The CDP platform's encryption gateway resides within the customer's own environment. Salesforce never has access to the plain-text sensitive data. Moreover, organizations retain control over how they manage their keys. Even with BYOK, Salesforce decrypts data within its platform, meaning privileged access or misconfiguration could expose sensitive data. True separation is required for high-assurance protection.

StratoKey Features that Harden Salesforce Access

The StratoKey platform (CDP) is a suite of enterprise cloud data protection tools that complements Salesforce native controls with a fully independent encryption layer, making it ideal for regulated industries like defense, healthcare and financial services. 

The CDP sits between your users and Salesforce, encrypting data before it enters the Salesforce platform and decrypting only for those with authorized access within your organization.

• FIPS-Validated Encryption: All sensitive fields and attachments are encrypted end-to-end, using industry-standard FIPS 140-2/3 validated algorithms, before entering Salesforce.

• Search and Sort Capabilities: Search (including partial and wildcard) and sort capabilities on encrypted fields.

• Tokenization: Optionally replaces sensitive data with tokens, further reducing exposure risk and enabling storage locally,  like in FedRAMP-authorized environments or within specific jurisdictional boundaries. Moving the data-boundary and potentially de-scoping Salesforce from compliance burdens.

• Real-Time Monitoring: Monitors access to sensitive data and logs all requests against individual user profiles.

• Automated Policy Enforcement: Hardens access to sensitive data and blocks policy violations instantly.

• Seamless Integration: Works with Salesforce Lightning, Classic, SSO, mobile apps, and data loaders without disrupting workflows. 

• Prevents Salesforce AI tools and Integration Access: Prevents access to sensitive data by encrypting or tokenizing sensitive fields before they reach Salesforce, ensuring AI models and third-party integrations only see masked or redacted values.
• Independent Key Management: StratoKey allows you to manage and store encryption keys in your preferred manner.
• Extensible platform: Use the StratoKey CDP with other integrated or distinct SaaS applications as a central point to secure sensitive data.
• Encryption and Tokenization API: Utilize the in-built StratoKey API to integrate external services with encryption and tokenization, or move data between applications and services whilst supporting encryption and tokenization.

Why “Encryption at Arm’s Length” Matters: Lessons from Recent News

Recently reported vulnerabilities expose the limits of native security controls.  

Social Engineering and Malicious Apps

Hackers have been tricking employees in Europe and the Americas into installing a tampered version of Salesforce’s Data Loader app, enabling them to steal large amounts of data and access other cloud services. Google reports that these attackers are especially effective at using social engineering, posing as IT support, to convince victims to install the malicious app, which then grants unauthorized access to sensitive Salesforce and connected cloud environments.

Configuration and Permission Flaws

Security researchers uncovered over 20 configuration-related risks and several critical vulnerabilities in Salesforce Industry Cloud, some of which allowed unauthorized users to bypass encryption and field-level security, exposing sensitive data in plaintext, even for fields marked as encrypted. Notably, CVE-2025-43697, CVE-2025-43698, and CVE-2025-43700 were found to expose encrypted field values in plaintext, bypassing key security controls.

The Problem with Native Encryption

Native encryption (like Salesforce Shield) relies on keys and cryptographic operations to be exposed to the Salesforce environment:

If attackers gain sufficient privileges, either through social engineering, exploiting misconfiguration, or leveraging other vulnerabilities, they may access data in decrypted form or manipulate permissions to bypass encryption controls.

Even with advanced native encryption features (such as BYOK), Salesforce still processes keys and decrypts data within its infrastructure. This means that a platform-level breach or privileged insider threat could potentially access decrypted data, especially if encryption and access controls are not perfectly configured.

Read More: How hosting your own encryption gateway can assist in third-party breach scenarios. 

Encryption at Arm’s Length for Hardened Access to Sensitive Data

Managing encryption keys and cryptographic operations outside Salesforce enhances data security. With this approach, even if attackers or insiders compromise Salesforce, they cannot decrypt sensitive data without compromising additional systems, making breaches much more difficult. StratoKey further reduces the attack surface by ensuring sensitive data is only accessible through systems you control.

This dramatically limits the impact of any breach; even if encrypted data is stolen from Salesforce, it remains protected and inaccessible, providing a crucial line of defense against third-party breaches.

Compliance and Salesforce Shield

Recent Salesforce vulnerabilities pose compliance risks, including data exposure that can lead to fines, lost contracts, and reputational damage. While Salesforce Shield encryption helps, its limitations, especially around integrations, customizations, and reduced functionality on encrypted fields, can create compliance gaps and operational headaches.

Onshoring and data residency remain difficult with Shield. Even with EU-localized clouds like Hyperforce EU Operating Zone, U.S. laws such as the CLOUD Act can still require data disclosure, meaning full sovereignty isn’t guaranteed.

Salesforce’s native tokenization is also limited to payments and marketing, offering little support for broader data residency or general tokenization needs. True data onshoring requires that sensitive data and keys never leave jurisdictional borders or become accessible to foreign providers, and if you are not a U.S. company, it is a standard only achieved with tokenization and encryption managed entirely outside Salesforce.

A Proactive Path to Salesforce Data Protection

Relying on Salesforce's native tools alone can leave critical gaps for organizations with strict compliance, data residency, or industry-specific security requirements. Externally managed encryption and tokenization are essential to secure sensitive data, at arm's length, and meet regulatory demands.

StratoKey goes beyond the limitations of Salesforce Shield by placing encryption and tokenization fully under your control, outside Salesforce’s infrastructure. This closes compliance gaps and does so at a fraction of Shield’s cost.

StratoKey closes the data protection gap, offering:

• Encryption and tokenization outside of Salesforce.

• Full control over key lifecycle and storage.

• Compatibility with broader cloud apps.

• Support for data residency and sovereign control.

If your industry demands that security and compliance never take a back seat to convenience, StratoKey delivers robust protection, regulatory alignment, and true data sovereignty.

Ready to harden access to sensitive data in your Salesforce environment? Request the Salesforce brochures to learn more.