HashiCorp Vault Recovery Keys Operations Guide: The Ops Key Under Auto Unseal

Once you enable Auto Unseal, manual Unseal operations disappear from day-to-day work, but Recovery Keys become the organization's last line of defense in their place.

This article walks through the correct mental model for Recovery Keys, the specific scenarios where you need them, storage and rotation procedures, and a concrete break-glass example — covering both exam prep and real-world operations.

What Recovery Keys Are and How They Relate to Auto Unseal

Auto Unseal uses an external KMS/HSM (e.g., AWS KMS, GCP KMS, Azure Key Vault, HSM) to automatically decrypt Vault's barrier key, eliminating the Unseal step at startup. Because of this, Shamir Unseal Keys are not generated. Recovery Keys are the operational key issued in their place, used only for exception handling.

Recovery Keys are generated via Shamir's Secret Sharing, and by collecting threshold-many shares you can execute specific recovery operations (such as issuing a new root token or rekeying the Recovery Keys themselves). They are not needed for ordinary secret access or policy management; while Auto Unseal is running, the main operational tasks are storage, audit, and periodic testing.

• Not used in daily operations — strictly for break-glass scenarios
• Shamir shares and threshold are decided at init time
• Even with Auto Unseal, initialization is required and Recovery Keys are issued at that point

Positioning of Auto Unseal and Recovery Keys

Which Operations Actually Need Recovery Keys (Ops View)

In an Auto Unseal environment, Recovery Keys are only used for exceptions that ordinary authentication and authorization cannot resolve. The classic case is when all existing root tokens are lost and no policy-based escalation is possible, and you need to issue a new root token.

Recovery Keys are also used to rekey the Recovery Keys themselves (including changing the threshold or share count). Barrier-key rotation (operator rotate) is performed with a root token and does not require Recovery Keys.

• Issue a new root token: vault operator generate-root -recovery
• Rekey the Recovery Keys: vault operator rekey -recovery
• Barrier-key rotation: vault operator rotate (uses root token, no Recovery Keys needed)
• Some Enterprise operations (e.g., DR promotion) may involve Recovery Keys, but this depends on environment and version specifics — always confirm against the official docs during design

Generation and Storage Best Practices

Define the Recovery Key share count and threshold at init time. A common N-of-M choice is 3-of-5, but you should decide based on your organization's staffing, geographic redundancy, and audit requirements.

For distribution, the pragmatic approach is to output shares wrapped under each operator's PGP public key, then distribute and store them privately per holder. Choose storage options assuming dual custody: offline storage (fire-resistant safes), hardened slots in a secrets manager, or physically sealed vaults.

• Explicitly specify recovery-shares and recovery-threshold during vault operator init
• Use PGP wrapping (-pgp-keys) to encrypt with a distinct public key per holder before distribution
• After distribution, confirm receipt and run an offline decryption test, leaving an audit trail
• Operationalize a share-location ledger, handover procedures for personnel changes, and periodic inventory checks
• Never paste key material into repos or tickets — always store encrypted and segregated

Runbook: Break-glass in an Auto Unseal Environment (Issue a New Root)

Preconditions: Vault is running, but all root tokens are lost and escalation is not possible. Threshold-many Recovery Key shares can be collected. Treat the operation as an audited action and create a change record before starting.

Flow: initialize generate-root, record the displayed Nonce and One-time password, then submit threshold-many Recovery Key shares in sequence. At the end, decrypt the encoded token with the OTP to obtain the root. After execution, complete the intended task quickly and ideally revoke or seal off the root.

• Before starting, check vault status and confirm audit devices are enabled
• Record the OTP safely and avoid mistakes in the decryption step
• Make sure the team knows generation will not occur below threshold
• Treat the generated root as short-lived and disposable (tear it down after the task)

Break-glass: issue a new root using Recovery Keys

# 0) Environment check
export VAULT_ADDR=https://vault.example.com:8200
vault status

# 1) Initialize the generation process (explicit -recovery)
# Safely record the displayed Nonce and One-time password (OTP)
vault operator generate-root -init -recovery
# Example output:
# Nonce:  6f4c...e1
# One-time password:  yxD-2V...-H9
#   (Encoded token is NOT shown at this point)

# 2) Submit each Recovery Key share in turn (repeat threshold times)
# <SHARE_i> is the recovery share held by each operator (already decrypted string)
vault operator generate-root -recovery -nonce 6f4c...e1 <SHARE_1>
vault operator generate-root -recovery -nonce 6f4c...e1 <SHARE_2>
# ... The Encoded token appears on the final submission that reaches threshold
# Example: Encoded token: VVNF... (truncated)

# 3) Decrypt the encoded token with the OTP to obtain the root token
vault operator generate-root -decode=VVNF... -otp=yxD-2V...-H9
# Example: Root token: s.p7y... (share over a protected channel)

# 4) After the intended task, avoid long-term retention of root
# e.g., perform only the minimum operations needed for the emergency response

# Reference: rekeying the Recovery Keys (changing threshold / share count)
# Recommended: wrap with each holder's PGP public key
vault operator rekey -recovery -init \
  -recovery-shares=5 -recovery-threshold=3 \
  -pgp-keys="keybase:alice,keybase:bob,keybase:carol,keybase:dave,keybase:erin"
# After init, submit threshold-many shares in sequence
vault operator rekey -recovery <SHARE_1>
# ... (threshold times)
# On completion, new Recovery Keys are issued (update distribution and receipt records)

Key Points for Rotation and Audit

Rotate the Recovery Keys with rekey -recovery. Service continuity is not impacted, so no planned downtime is required — but you do need human coordination to collect the shares. After completion, promptly destroy the old shares and update both the ledger and audit records.

Barrier-key rotation (vault operator rotate) is performed with a root token and does not use Recovery Keys. The lifecycle of the Auto Unseal wrap key (on the KMS/HSM side) follows the cloud/HSM policy and must be kept consistent with the Vault side. For audit, we recommend at least two audit device backends so that operator endpoint calls are reliably recorded.

• rekey -recovery can be performed without downtime, but scheduling so the human threshold can be met is critical
• Barrier-key rotate is performed with a root token — reinforce backups and monitoring beforehand
• Use multiple audit device backends (e.g., file + Syslog) plus tamper-detection mechanisms
• Reflect KMS/HSM key rotation and revocation plans in the Vault operations calendar

Ops Exam Essentials and Pitfalls

The exam frequently tests the division of responsibility between Auto Unseal and Recovery Keys, which operations need which key, and whether you can pick the correct command switches. In particular, lock in whether -recovery is required on generate-root and rekey, and the distinction that rotate is performed with a root token.

Questions often target real-world pitfalls — for example, baiting you toward the wrong answer that 'Auto Unseal means Recovery Keys are unnecessary.' Don't forget the framing: Recovery Keys are not used day-to-day, but losing them leaves you with no way out.

• In Auto Unseal environments, Unseal Keys are not generated — Recovery Keys are generated instead
• New root issuance: vault operator generate-root -recovery
• Rekeying the Recovery Keys: vault operator rekey -recovery
• Barrier-key rotation: vault operator rotate (uses root token)
• PGP wrapping and N-of-M design are key topics for both practice and the exam

Check Yourself with a Question

Frequently Asked Questions