Salesforce BYOK and Cache-Only Key Service: Secure Your CRM Data with External Key Management

The Salesforce Cache-Only Key Service is the Shield Platform Encryption option that keeps your key material outside Salesforce. Salesforce fetches the key on demand from a key service you control, through a named credential callout, and holds it only in an encrypted cache. Salesforce doesn't retain or persist cache-only keys in any system of record or backup, so if you destroy the key or stop serving it, the data it protects becomes unreadable (Salesforce Platform Encryption Implementation Guide).

Table of Contents

1. Why Salesforce Native Encryption Falls Short
2. BYOK vs Cache-Only Key: Which Model Fits Your Needs
3. Salesforce Cache-Only Key Service: How It Works
4. Salesforce Shield Platform Encryption Explained
5. Integrating External Key Management with Salesforce
6. Meeting GDPR Requirements with Salesforce BYOK
7. Performance and Availability
8. Key Rotation and Lifecycle Management in Salesforce
9. FAQ
10. Conclusion
11. References and Further Reading

For enterprises storing sensitive customer data in Salesforce, the question of encryption key ownership has become a critical compliance and security concern. Salesforce encryption BYOK (Bring Your Own Key) offers organizations the ability to maintain cryptographic control over their CRM data, even when that data resides in Salesforce's multi-tenant cloud infrastructure. This capability has moved from a security luxury to a regulatory necessity, particularly for organizations operating under GDPR, DORA, NIS2, or industry-specific frameworks like HIPAA and TISAX.

The fundamental challenge is straightforward: when your encryption keys are generated, stored and managed by your cloud provider, you've effectively delegated the security of your most sensitive data to a third party. For regulated industries, financial services, healthcare, automotive and government, this delegation creates audit gaps, compliance risks and potential exposure to foreign jurisdiction data access requests. Salesforce external key management addresses this gap by allowing enterprises to retain ultimate authority over the cryptographic keys protecting their CRM data.

This guide examines the technical architecture, compliance implications and operational considerations for implementing BYOK and Cache-Only Key solutions within Salesforce Shield Platform Encryption. We'll provide the technical depth that CISOs and security architects need to make informed decisions about their CRM data sovereignty strategy.

Why Salesforce Native Encryption Falls Short

Salesforce provides encryption capabilities out of the box, but the default implementation leaves significant security and compliance gaps that enterprise security teams cannot ignore.

The Provider-Managed Key Problem

Salesforce's standard encryption uses keys that are generated and stored within Salesforce's infrastructure. While this provides protection against certain threat vectors, such as physical theft of storage media, it does not address the fundamental concern of provider access. Salesforce administrators, support personnel and potentially law enforcement in Salesforce's operating jurisdictions can theoretically access the encryption keys protecting your data.

For organizations subject to European data protection regulations, this creates a direct conflict with the principle of data sovereignty. The Schrems II ruling invalidated the Privacy Shield framework precisely because US-based providers could be compelled to provide access to data under the CLOUD Act, regardless of where that data is physically stored.

Compliance Audit Failures

When auditors examine your Salesforce security posture, they will ask a critical question: "Who controls the encryption keys?" If the answer is "Salesforce," you face several problems:

• GDPR Article 32 requires appropriate technical measures to ensure data security, measures you control
• DORA Article 9 mandates that financial entities maintain control over their ICT security functions
• NIS2 Directive requires organizations to implement cryptographic controls with documented key management procedures
• HIPAA Security Rule necessitates access controls that you can independently verify and audit

With provider-managed keys, you cannot demonstrate independent control. Your security posture is only as strong as Salesforce's internal access controls, controls you cannot audit or verify.

The Insider Threat Vector

Salesforce employs thousands of personnel globally. While the company maintains robust security practices, insider threats remain a statistical reality in any large organization. A 2024 Verizon Data Breach Investigations Report found that insider threats accounted for 19% of breaches, with privileged access abuse being a primary vector.

When Salesforce holds your encryption keys, a compromised insider at Salesforce becomes a threat to your data. External key management eliminates this risk by ensuring that Salesforce personnel, regardless of their access level, cannot decrypt your data without your explicit participation.

Jurisdictional Data Access Risks

The extraterritorial reach of the US CLOUD Act means that a US court order can compel Salesforce to produce data stored on servers anywhere in the world. For European enterprises, this creates an irreconcilable conflict with GDPR's data protection requirements.

With Salesforce BYOK encryption properly implemented, even if Salesforce is compelled to hand over encrypted data, they cannot provide the keys to decrypt it. This creates a technical safeguard that complements legal and contractual protections.

BYOK vs Cache-Only Key: Which Model Fits Your Needs

Salesforce Shield Platform Encryption offers two ways to supply your own key material: Bring Your Own Key (BYOK), where you upload a tenant secret, and the Cache-Only Key Service, where Salesforce fetches the key from your key service each time its cache is empty.

Bring Your Own Key (BYOK) Architecture

In the BYOK model, you generate a tenant secret outside Salesforce and upload it, encrypted with a BYOK-compatible certificate. Shield uses your tenant secret together with Salesforce's master secret to derive the data encryption key. The uploaded secret is stored in Salesforce.

BYOK improves on Salesforce-managed keys because you control how the tenant secret is generated and can destroy it. But once uploaded, the material lives inside Salesforce.

Cache-Only Key Architecture

With the Cache-Only Key Service, your key material never sits in a Salesforce system of record. Salesforce calls your key service, receives the key wrapped in JSON Web Encryption (JWE), and keeps it only in an encrypted cache. Cache-only keys bypass the key derivation process and directly encrypt and decrypt your data (Salesforce).

The cache matters for revocation. Salesforce flushes it regularly every 72 hours, and some operations flush it about every 24 hours. Destroying the cache-only key in Setup invalidates the cached copy at once; stopping your key service takes effect when the cache next needs the key (Salesforce).

Decision Framework

Choose BYOK when:

• You need customer-generated keys for compliance, but can accept that Salesforce stores the material
• You don't want a runtime dependency on an external key service
• Your threat model does not include the CRM provider itself

Choose Cache-Only Key when:

• Policy requires that key material is not stored by the SaaS provider
• You need to be able to cut Salesforce off from the key on your side
• Your threat model includes jurisdictional access requests (for example the US CLOUD Act)
• You can run, or buy, a highly available key service

For a broader comparison of these models across SaaS and cloud providers, see Hold Your Own Key (HYOK) vs BYOK.

Salesforce Cache-Only Key Service: How It Works

When users read encrypted data or write data to encrypted fields, and the key isn't in the cache, the Cache-Only Key Service makes a callout to your key service through a named credential. Your service returns the key material wrapped in JWE over the authenticated channel you set up. Salesforce encrypts the fetched key with an org-specific AES-256 cache encryption key, itself protected by HSM-protected keys, before caching it (Salesforce).

Key format

A protected header looks like {"alg":"RSA-OAEP","enc":"A256GCM","kid":"982c375b-f46b-4423-8c2d-4d1a69152a0b"}. Salesforce publishes a Cache-Only Key Wrapper sample on GitHub that shows how to assemble the response.

Replay detection

With replay detection enabled in Platform Encryption Advanced Settings, every callout carries a RequestIdentifier with a one-time nonce. Your key service must echo the nonce as jti in the JWE header; otherwise Salesforce aborts the callout with POTENTIAL_REPLAY_ATTACK_DETECTED.

When the key service is unreachable

• While the key is cached, encryption and decryption keep working.
• If a callout fails, the active cache-only key is set to Destroyed and Salesforce retries: once a minute for five minutes, then every five minutes for 24 hours. A successful retry sets the key back to Active.
• Data whose key can't be fetched, or whose key was destroyed, is masked as ????? in the app.
• Every callout is captured in the RemoteKeyCalloutEvent object, which you can use to alert on failures.

Salesforce is explicit that you own the key: it can't retrieve lost key material stored outside its encrypted cache (Salesforce).

Licensing

The Cache-Only Key Service is available in Enterprise, Performance, Unlimited and Developer editions, and requires Salesforce Shield or Shield Platform Encryption plus the Cache-Only Key Service. Use a separate cache-only key for each key type (for example Data in Salesforce and Analytics).

Salesforce Shield Platform Encryption Explained

Salesforce Shield Platform Encryption is the enterprise encryption framework that enables both BYOK and Cache-Only Key implementations. Understanding its architecture is essential for proper deployment.

Shield Platform Encryption Components

Shield Platform Encryption operates on a hierarchical key structure:

1. Master Secret, Generated and managed by Salesforce
2. Tenant Secret, Generated by Salesforce or by the customer (BYOK). With the Cache-Only Key Service, your fetched key is used directly instead of a derived key
3. Data Encryption Key, Derived from the combination of master and tenant secrets
4. Per-Record Keys, Individual keys derived for specific data records

This hierarchy provides defense in depth. Compromising a single per-record key does not expose all encrypted data and the separation between master and tenant secrets means neither party alone can derive the data encryption key.

Encryptable Data Types

Shield Platform Encryption supports encryption for:

• Standard and custom field data, Text, text area, phone, email, URL fields
• Files and attachments, Documents uploaded to Salesforce
• Search index, Encrypted search maintains functionality while protecting data
• Chatter, Posts and comments in the Salesforce collaboration platform
• Platform Events, Event data in asynchronous processing

Not all field types support encryption. Formula fields, auto-number fields and certain system fields cannot be encrypted. Your implementation team must map sensitive data fields to encryptable field types during the planning phase.

Probabilistic vs Deterministic Encryption

Salesforce Shield offers two encryption schemes:

Probabilistic Encryption provides maximum security by generating unique ciphertext for identical plaintext values. The same customer name encrypted twice produces different ciphertext. This prevents pattern analysis attacks but limits certain functionality, you cannot filter or group by encrypted fields.

Deterministic Encryption produces consistent ciphertext for identical plaintext values, enabling filtering, grouping and case-insensitive matching on encrypted data. However, this consistency creates a theoretical vulnerability to frequency analysis on high-cardinality fields.

For most enterprise deployments, probabilistic encryption is appropriate for highly sensitive fields (social security numbers, financial data), while deterministic encryption suits fields requiring query functionality (email addresses for duplicate matching).

Licensing Requirements

Shield Platform Encryption requires the Salesforce Shield add-on license. This license also includes Event Monitoring and Field Audit Trail capabilities. For organizations implementing comprehensive security programs, these additional features often justify the Shield investment beyond encryption alone.

The Cache-Only Key Service requires Shield or Shield Platform Encryption plus the Cache-Only Key Service.

Integrating External Key Management with Salesforce

External Key Management Architecture

A Cache-Only Key Service integration has four parts:

1. Your key service, which generates, stores and serves the 256-bit key, wrapped in JWE
2. A BYOK-compatible certificate in Salesforce, whose public key your service uses to wrap the content encryption key
3. A named credential, the allowlisted, authenticated HTTPS channel Salesforce uses for the callout. Named credentials support common authentication formats such as mutual TLS and OAuth
4. The cache-only key entry on the Key Management page, which ties a unique key identifier to the named credential

Salesforce also offers Shield External Key Management with keys in AWS KMS, reached through an AWS Signature Version 4 named credential. If that AWS KMS key lives in an AWS external key store, the root key stays outside AWS as well.

Implementation Prerequisites

• Shield or Shield Platform Encryption, plus the Cache-Only Key Service
• At least one active Data in Salesforce key (Salesforce-generated or customer-supplied)
• A BYOK-compatible certificate created in Setup
• A highly available key service reachable from Salesforce
• The Manage Encryption Keys permission, and Customize Application for named credentials

Step-by-Step Integration Process

These steps follow Salesforce's Platform Encryption Implementation Guide:

1. Create a named credential that points to the HTTPS endpoint serving your key material.
2. Allow cache-only keys. In Setup, open Platform Encryption > Advanced Settings and select Allow Cache-Only Keys with BYOK.
3. Open Key Management, choose the key type from the Tenant Secret Type list and select Bring Your Own Key.
4. Select the BYOK-compatible certificate and tick Use a Cache-Only Key.
5. Enter the Unique Key Identifier (your kid) and choose the named credential for that key.
6. Let Salesforce check the connection. If the endpoint answers, the key becomes active and its status shows as Fetched. Use the Callout Check page to retest later.
7. Optionally enable replay detection once your service echoes the nonce.
8. Encrypt fields and files through your encryption policy, and synchronize existing data on the Encryption Statistics and Data Sync page.

Cache-Only Key Service with DuoKey

DuoKey for Salesforce runs the key service side for you. Salesforce Shield calls DuoKey's Cache-Only Key Service (COKS) endpoint directly through a named credential and its external credential, authenticated with a bearer connector secret that DuoKey generates when you create the Salesforce app. DuoKey never logs into your Salesforce org and never needs a Salesforce username, password or security token.

• The key is created and kept in a DuoKey Cockpit vault, and access to the integration is limited to the DuoKey roles you assign to the app.
• Key creation, rotation and revocation are managed from Cockpit.
• For Shield External Key Management through AWS KMS, DuoKey documents a chain in which AWS KMS uses an external key store and the DuoKey XKS proxy, with the key in the DuoKey MPC vault.

Meeting GDPR Requirements with Salesforce BYOK

Salesforce BYOK and Cache-Only Key in particular, directly addresses several GDPR compliance concerns raised by the Schrems II ruling.

Demonstrating Data Sovereignty

With Cache-Only Key properly configured, you can demonstrate to regulators that:

• Salesforce cannot decrypt your data without your key service
• A CLOUD Act request to Salesforce produces only unusable ciphertext
• You maintain exclusive control over the key material protecting European personal data

Compliance Documentation

Maintain the following documentation for GDPR audits:

• Data flow architecture showing external key control
• Key management policy with rotation and revocation procedures
• Key access logs demonstrating your exclusive control
• Data Protection Impact Assessments (DPIAs) for Salesforce processing activities

Performance and Availability

Because Salesforce caches the fetched key, the key service is only called when the cache is empty, after a flush, a rotation or a destroy. Day-to-day encryption and decryption run against the cache.

Availability is the real constraint. If the key isn't cached and your service can't be reached, users can't read or write encrypted data. Salesforce asks for a key service with an acceptable SLA and stresses busy periods such as quarter and year end.

• Run the key service in high availability, in a location with a reliable path to your Salesforce instance
• Alert on RemoteKeyCalloutEvent failures with an after-insert Apex trigger
• Rehearse an outage in a sandbox, including reactivating a key that was set to Destroyed by a failed callout

Key Rotation and Lifecycle Management in Salesforce

Regular key rotation is a compliance requirement and a security best practice.

Recommended Rotation Frequencies

Key Rotation Process

1. Generate a new key in your key service and host it at the endpoint of your existing named credential
2. Change the key ID in the Unique Key Identifier field; you don't need a new named credential
3. Keep the previous key available: archived keys are used for decryption until all data has been re-encrypted under the active key
4. Synchronize existing data to the new key on the Encryption Statistics and Data Sync page
5. Retire the old key only when nothing still depends on it

(Salesforce Platform Encryption Implementation Guide)

FAQ

Q: What is the Salesforce Cache-Only Key Service?

A Shield Platform Encryption option that fetches your 256-bit key from a key service you control, through a named credential callout, and keeps it only in an encrypted cache. Salesforce doesn't persist cache-only keys in any system of record or backup.

Q: What is the difference between Salesforce BYOK and a cache-only key?

With BYOK you upload a tenant secret that Salesforce stores and uses to derive the data encryption key. With a cache-only key, Salesforce fetches your key on demand, uses it directly, and doesn't store it.

Q: How long does Salesforce cache a cache-only key?

The cache is flushed every 72 hours, and some Salesforce operations flush it about every 24 hours. Destroying the key in Setup invalidates the cached copy immediately.

Q: What happens if my key service goes down?

Cached keys keep working. When the cache is empty and the callout fails, the key is set to Destroyed, Salesforce retries for up to 24 hours, and affected data shows as ????? until the key can be fetched again.

Q: Does the Cache-Only Key Service need mutual TLS?

No specific method is required. The callout uses a named credential, which supports formats such as mutual TLS and OAuth. DuoKey's endpoint uses a bearer connector secret set in the named credential's external credential.

Q: Which licenses do I need?

Salesforce Shield or Shield Platform Encryption, plus the Cache-Only Key Service, in Enterprise, Performance, Unlimited or Developer edition.

Conclusion

Salesforce BYOK encryption and Cache-Only Key in particular, represents the most robust CRM data sovereignty architecture available on the platform. For European organisations subject to GDPR, DORA, or NIS2, it is increasingly not an option but a necessity to demonstrate adequate control over sensitive personal and financial data.

The key to success lies in choosing the right architecture (BYOK vs Cache-Only Key based on your threat model), implementing a high-availability external key management infrastructure and rigorously documenting controls for audits. DuoKey provides a ready Cache-Only Key Service endpoint for Salesforce, so you don't have to build and operate the JWE key service yourself.

References and Further Reading

• Salesforce Shield Platform Encryption, Official Documentation
• Salesforce Cache-Only Key Service, Developer Guide
• Salesforce Platform Encryption Implementation Guide (PDF)
• Salesforce Cache-Only Key Wrapper (GitHub)
• DuoKey for Salesforce
• GDPR Article 32, Security of Processing
• Schrems II ruling, Implications for US data transfers
• DORA, Regulation (EU) 2022/2554
• ENISA, Cryptography and Key Management Guidelines
• Verizon Data Breach Investigations Report 2024