Master HSM
The Master HSM is the air-gapped hardware security module that Salesforce uses to generate the master secret behind Shield Platform Encryption.
Definition
The Master HSM is the air-gapped hardware security module that Salesforce uses to generate the master secret behind Shield Platform Encryption. At the start of each Salesforce release, this dedicated device produces the release-specific master secret. That secret later combines with each customer's tenant secret to derive the AES-256 keys that actually encrypt your data, so the Master HSM sits at the top of the key material chain.
The Master HSM is platform infrastructure, not customer-facing configuration. You never see it in Setup, call it through an API, or operate it yourself. Salesforce keeps the device physically separated from its production network and stored in a bank safety deposit box, where only designated security officers can reach it. For Shield architects and compliance auditors, the Master HSM is the answer to a specific question: where does the most sensitive secret material in the encryption system come from, and how is it protected from insider access.
How the Master HSM fits into key derivation
What the Master HSM actually does
The Master HSM has one job: generate the master secret at the start of every Salesforce release. Salesforce documents this plainly. The master secret is produced by the Master HSM, then stored securely in Salesforce's internal file system for that release. From that point, the device's work for the release is done. It does not sit in the request path and it does not encrypt your data directly. That distinction trips people up. The Master HSM is not a live wrapping service that touches every encrypted field. The actual encryption keys, called data encryption keys, are derived on demand by key derivation servers in Salesforce data centers. Those servers run PBKDF2 over the master secret, the customer's tenant secret, and a per-release master salt to produce each AES-256 key. The Master HSM supplies one of those inputs, the master secret, and nothing more at runtime. So the device matters because of what it produces and how rarely it is used, not because it is busy. One offline generation event per release seeds the entire derivation system. Keeping that generation step on an air-gapped device limits exposure of the master secret to a tightly controlled, infrequent operation.
Air-gapped, offline, and held by security officers
Salesforce describes the Master HSM as air-gapped from its production network. The device is stored in a bank safety deposit box, and only designated Salesforce security officers can access that box and the hardware inside it. This is deliberate. The master secret is the highest-value cryptographic input in the system, so the device that creates it is kept physically away from the always-on infrastructure that attackers or curious insiders might reach. Because the Master HSM is offline, it cannot be compromised over the network. There is no port to scan and no service to exploit. An attacker who breached Salesforce's production environment would still not find the Master HSM there. They might find the release-specific master secret in the internal file system, but the device that generated it stays in the vault. This design also explains why the master secret rotates per release rather than continuously. Generating a new secret requires retrieving the air-gapped device, so the cadence is tied to the release schedule. The tradeoff is intentional: stronger isolation in exchange for a generation step that happens on a fixed, infrequent rhythm rather than on demand.
Master HSM versus the embedded HSMs
Shield Platform Encryption uses more than one kind of hardware security module, and conflating them causes confusion. The Master HSM is the offline device that generates the master secret once per release. Separately, key derivation servers in each data center contain their own embedded HSMs. Those embedded modules are online, FIPS 140-2 compliant PCI devices that handle the day-to-day work. The embedded HSMs do two things the Master HSM does not. They generate tenant secrets on demand when a customer creates a new key through Setup, and they participate in the live derivation of data encryption keys. Every encrypt or decrypt operation that needs a fresh key routes to a key derivation server, where the embedded HSM and PBKDF2 turn the stored secrets into a working AES-256 key in memory. A useful way to hold it: the Master HSM is the offline seed generator, run a handful of times a year. The embedded HSMs are the working hardware in the request path. Both are genuine HSMs, but they sit at different points in the system and serve different roles. Auditors should reference them separately.
How the derived key is built
The data encryption key your org uses is never stored. Salesforce derives it on demand and discards it. The derivation runs PBKDF2 with three inputs: the release master secret from the Master HSM, your tenant secret, and a master salt generated at the start of that release. PBKDF2 stretches these into an AES-256 key, which the encryption service uses to protect field values, files, and attachments. Each encrypted field carries the ID and creation date of the tenant secret used to derive its key. When a user reads or saves that data, the encryption service sends a request to a key derivation server. The server looks up the matching tenant secret and the master secret identified by that creation date, then derives the key. A random 128-bit initialization vector pairs with the key so the same plaintext does not always produce the same ciphertext. Because the key depends on the master secret, the tenant secret, and the salt together, losing any one input breaks derivation. This is why controlling the tenant secret lifecycle gives you control over the keys. The Master HSM supplies the half of the equation that stays under Salesforce's control.
Why this design protects against insiders
A common worry with any cloud encryption service is the provider's own staff. Could a Salesforce database administrator read your encrypted data? The Master HSM is part of the answer. By generating the master secret on an air-gapped device held in a vault, Salesforce limits who can ever touch the most sensitive input, and limits when that input is created to a controlled per-release event. Data encryption keys are never written to disk, so a DBA browsing storage finds ciphertext and wrapped secrets, not usable keys. To derive a real key, an attacker would need the master secret, the tenant secret, and the salt, plus the derivation infrastructure. Splitting custody this way means no single person or system holds everything needed to decrypt your data. For customers who want even stronger separation, Bring Your Own Key lets you supply your own tenant secret rather than have Salesforce generate it. You can revoke Salesforce's access to that secret at any time. The Master HSM still provides the master secret half, but you hold the tenant secret half externally, narrowing the trust you place in Salesforce's infrastructure.
What customers actually see and cite
You will never configure or view the Master HSM. The customer-visible parts of this system are different: tenant secret records in Setup under the encryption key management screen, the ability to generate and rotate those tenant secrets, and audit log entries for key operations. The Master HSM stays entirely behind the platform boundary. What you can do is reference it. Salesforce's compliance attestations and its published Platform Encryption Architecture White Paper describe the Master HSM, the air-gapped storage, and the security officer custody model. Regulated customers cite these documents in their own audits as evidence of how Salesforce protects the master secret. The device itself cannot be demonstrated to an auditor, so the documentation stands in for it. Architects designing a Shield rollout should understand the Master HSM mainly to answer trust questions accurately. When a security review asks how Salesforce protects the root of its encryption keys, the honest answer is the air-gapped Master HSM plus the surrounding controls. Knowing the device generates the master secret rather than wrapping live traffic keeps that answer precise and credible.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Master HSM.
- Shield Platform Encryption TerminologySalesforce
- Key Management and RotationSalesforce
Hands-on resources to go deeper on Master HSM.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is the Master HSM?
Q2. Why use HSMs for key storage?
Q3. Do administrators interact with Master HSMs directly?
Discussion
Loading discussion…