Encrypting Salesforce Backups: AES-256, TLS 1.2, and What Admins Must Configure

A Salesforce admin can run a weekly export, download the ZIP file, and store it on a shared drive in minutes. The problem appears after the export finishes: that file is not automatically encrypted outside Salesforce. At that point, backup protection becomes the administrator's responsibility.

This article explains where Salesforce encryption stops and what admins must configure next. It covers Salesforce defaults, the gap in exported backups, the compliance standards that shape backup controls, and the Shield Platform Encryption settings that affect key management.

Exported Salesforce backups create a control gap, so admins must add external encryption and documented key management to meet operational and compliance requirements.

What Salesforce Encrypts by Default

Salesforce covers encryption inside its own environment, but exported backups remain the admin's responsibility. This section shows where that boundary sits so backup controls do not stop at export.

AES-256 at rest

Salesforce encrypts data at rest with AES-256 server-side encryption. Data 360 data uses a managed DEK. Administrators cannot access or manage those keys.

TLS 1.2 and 1.3 in transit

Salesforce supports TLS 1.2 and TLS 1.3 for service connections. TLS 1.0 and 1.1 are no longer supported. These transport protections are enabled by default.

The critical limitation

Default encryption protects data stored and transmitted within Salesforce-managed systems. It does not give customers direct key custody. It also does not provide an independent key rotation policy or the same audit evidence some compliance programs expect.

Where Native Backup Tools Leave Data Unencrypted

Native export tools do not document automatic encryption for downloaded backup files, so admins must add that control outside the platform. This is the main gap to close before backup handling aligns with Salesforce security governance.

Weekly Data Export produces ZIP files with object data and attachments. Salesforce documentation does not state that Weekly Data Export encrypts downloaded files after export.

Data Loader can protect stored credentials for command-line automation. The CSV files it creates are unencrypted by default.

Salesforce Backup preserves state for Shield-encrypted fields. Shield Platform Encryption protects data at rest while data remains in Salesforce data centers.

ZIP and CSV files downloaded to local devices, file shares, or cloud storage remain exposed unless a separate encryption control protects them after export.

Compliance Frameworks That Treat Encryption as Expected

Most compliance frameworks treat backup encryption as a required control in practice, so Salesforce teams need documented encryption and key-management procedures. That matters because backup handling, retention, and recovery evidence often sit in the same audit workflow.

HIPAA (45 CFR § 164.312)

Encryption and decryption is an addressable specification under the HIPAA Security Rule technical safeguards. If an organization does not encrypt ePHI, it must document that decision and apply an equivalent alternative safeguard. Civil monetary penalties can reach penalty limits set by penalty tier.

GDPR (Articles 25 and 32)

Article 32 identifies personal data encryption as an appropriate technical measure where risk justifies it. Strong backup encryption can also affect breach analysis under Article 33 if compromised data remains unintelligible without the key. GDPR exposure can reach Article 83 maximums for serious violations.

SOX (Sections 302 and 404)

SOX does not prescribe backup encryption directly. Sections 302 and 404 focus on internal controls over financial reporting and management attestation. If Salesforce stores financial reporting data, backup protection becomes part of the control design auditors review.

In practice, teams should separate three control areas:

• backup access
• recovery procedures
• release-related data changes

What Admins Must Configure for Encrypted Backups

Shield Platform Encryption improves key management inside Salesforce. This section shows which settings matter before backup copies leave the platform.

Required permissions

Shield setup requires access that should stay separate from general administration. Salesforce recommends isolating access through a dedicated permission set.

Use these core permissions:

• Manage Encryption Keys for generating, destroying, exporting, and importing tenant secrets
• Customize Application for enabling Shield Platform Encryption and editing encryption policy settings
• Manage Certificates for BYOK certificate uploads when applicable

For permission details, use Salesforce documentation.

Generating tenant secrets

Go to Setup, then Quick Find, then Platform Encryption, then Key Management. Select a key type and click "Generate Tenant Secret." Salesforce generates the Master Secret with hardware security modules, while tenant secrets are generated and managed by administrators through Setup.

Salesforce derives unique keys with PBKDF2 and additional entropy. Data encryption keys exist in cache and are not stored in plaintext on disk.

Setting encryption policy

Encryption policy determines which Salesforce data elements use Shield protection. Configure it in Setup under Platform Encryption, then Encryption Policy. Run the Encryption Analyzer before enabling encryption in production.

Key rotation

Key rotation requires both policy and process. When admins generate a new tenant secret, new data uses the new key automatically. Existing data needs explicit re-encryption. The time required depends on data volume.

Salesforce does not set a mandatory rotation interval. NIST SP 800-57 Part 1 provides rotation guidance based on sensitivity and usage. Teams should turn that guidance into a documented schedule tied to change control and backup handling.

BYOK and cache-only keys

BYOK supports stronger customer key custody requirements. With BYOK setup, admins can supply key material from enterprise key management systems. Cache-only keys increase control further by avoiding standard key derivation.

This option requires Shield Platform Encryption and the External Key Management Service add-on.

Email TLS enforcement

Outbound email TLS is a separate control and requires manual setup. Go to Setup, then Deliverability, and configure TLS for outbound email. Salesforce does not enable this setting by default.

Closing the Encryption Gap with Purpose-Built Backup Solutions

Shield improves encryption and key management inside Salesforce. Organizations that store backups outside Salesforce should consider using a separate solution that applies strong encryption, such as AES-256 for data at rest and TLS 1.2 or higher for data in transit.

Purpose-built backup solutions for Salesforce can address that external storage gap. Teams that also need stronger release governance should look for audit trails for compliance reporting and policy-based deployment controls.

Protecting Salesforce data also requires recovery and storage choices that fit compliance obligations. Request a demo to review options for Salesforce data protection and control design.