Overview

Each Policy Node holds an Encryptor Master Password (EMP). The EMP derives a key-encryption key that wraps that node's Master Encryption Key (MEK). The MEK encrypts MPC key material for tenants served by the node.

Rotating the EMP re-wraps the MEK under a new derived key. The MEK value itself does not change, so existing key material stays usable after rotation.

⚠️

Warning:

Retain every EMP that was in use when a database backup was taken. A restore requires the same Policy Node EMPs that wrapped the MEKs at backup time. Store EMP history with your backup inventory. See System Backup and Restore Process.

Rotation is per Policy Node. Each node has its own EMP and can be rotated independently. Clients call the Vault API, not Policy Nodes directly, so restarting nodes one role at a time does not require client-visible downtime.

Prerequisites

• Institutional Vault build that supports EMP rotation (RotateFromEncryptorMasterPassword on the Policy Node).
• A new EMP value generated and stored in your secret manager (or attested release path) with the same operational controls as the current EMP.
• Access to update each Policy Node config and restart that node's replicas.
• Ability to read wallet / orchestrator logs for the confirmation message below.

How rotation works

On Policy Node start, when both passwords are configured:

1. The node loads the encrypted MEK from the orchestrator database.
2. It probes the ciphertext with the new EMP. If decryption succeeds, the MEK is already under the new password and no write occurs.
3. Otherwise it decrypts with the old EMP, re-encrypts under the new EMP, and stores the result.

Each tenant rotates on the first request that loads that tenant after restart. The write for a tenant is atomic. Restarting again with the same dual config is safe (idempotent).

📘

Note:

Rotation applies to the global EMP in the Policy Node [Secrets] section. Tenant-specific EMP overrides cannot be rotated with this procedure.

Procedure

Perform the steps below for one Policy Node role at a time (policy-node0, then policy-node1, then policy-node2). All replicas of a role must share the same config; do not run replicas of the same role with different EMP settings.

Step 1: Enter the transition state

1. Create or provision the new EMP in your secret store (new secret name or attested SKR ciphertext, depending on deployment).
2. Keep the old EMP available under its current secret lookup.
3. Update the Policy Node [Secrets] section so that:
   • EncryptorMasterPassword resolves to the new EMP
   • RotateFromEncryptorMasterPassword resolves to the old EMP

Example with literal values (prefer secret interpolation in production):

[Secrets]
EncryptorMasterPassword = "new-password"
RotateFromEncryptorMasterPassword = "old-password"

Example with Azure Key Vault interpolation (replace secret names with your deployment prefixes). During a move to attested SKR release, point EncryptorMasterPassword at the new attested source and keep RotateFromEncryptorMasterPassword on the previous azureSecret lookup, as in the diagram below:

[Secrets]
EncryptorMasterPassword = "{{ azureSecret `policy-node0-encryptor-master-password-new` }}"
RotateFromEncryptorMasterPassword = "{{ azureSecret `policy-node0-encryptor-master-password` }}"

4. Restart all replicas of that Policy Node role so the new config loads.

Step 2: Verify rotation

1. Generate Vault traffic that exercises the tenant (or wait for normal traffic) so each tenant loads on the restarted node.
2. Confirm orchestrator / wallet logs contain EncryptorMasterPassword updated for that node and tenant (one entry per tenant per node).
3. Confirm signing and approvals still succeed for that Policy Node role.

If a node serves more than one orchestrator or tenant, verify the log line for every tenant before leaving the transition state.

Step 3: Reach the target state

After every tenant for that node has rotated:

1. Remove RotateFromEncryptorMasterPassword from the Policy Node config.
2. Leave EncryptorMasterPassword pointing only at the new EMP source.
3. Restart the node replicas again so the cleaned config is active.
4. Decommission or lock down the old secret only after you no longer need it for backup restore of pre-rotation snapshots.

Repeat Steps 1–3 for the remaining Policy Node roles.

Example: Azure secret source migration

The diagram shows moving from a plaintext Key Vault secret (azureSecret) to an attested Premium Key Vault SKR release (azureSkrSecret) while rotating the EMP value. The same three states apply when you only change the password string but keep the same secret helper.

---
config:
  themeVariables:
    fontSize: 16px
    fontFamily: arial
---
flowchart LR
  subgraph current [Current State]
    direction BT
    KV1["Key Vault secret<br/>plaintext value = abc.."]
    CFG1["Policy-Node Config:<br/>EncryptorMasterPassword = {{ azureSecret }}"]
    CFG1 --> KV1
  end

  subgraph transition [Transition State]
    direction BT
    SKR2["Key Vault Premium attested SKR<br/>plaintext value = xyz.."]
    KV2["Key Vault secret<br/>plaintext value = abc.."]
    CFG2["Policy-Node Config:<br/>EncryptorMasterPassword = {{ azureSkrSecret }}<br/>RotateFromEncryptorMasterPassword = {{ azureSecret }}"]
    CFG2 --> SKR2
    CFG2 --> KV2
  end

  subgraph target [Target State]
    direction BT
    SKR3["Key Vault Premium attested SKR<br/>plaintext value = xyz.."]
    CFG3["Policy-Node Config:<br/>EncryptorMasterPassword = {{ azureSkrSecret }}"]
    CFG3 --> SKR3
  end

  current --> transition --> target

Other deployments use the same config fields with awsSecret, enclaveSecret, env, or equivalent secret injection for your platform.

Operational notes

• Horizontal replicas: Replicas of the same NodeId share one MEK row. Concurrent rotation is safe; last writer wins with a consistent MEK value.
• Idempotency: Leaving the transition config in place and restarting again does not re-wrap an already rotated MEK.
• Failure: If rotation fails for a tenant, that request fails and retries on the next load. Fix config or secret access, then restart or retry traffic; do not remove RotateFromEncryptorMasterPassword until verification succeeds.
• Backup coupling: After rotation, new backups require the new EMP. Older backups still require the EMP that was active when they were taken.