What does it mean when Vault is sealed?

When Vault is sealed, the encryption keys are not loaded into memory, making all secrets inaccessible. This is a security feature - even with access to storage, data cannot be decrypted. Vault starts sealed and seals automatically on restart.

How do I unseal Vault?

Unseal Vault by running 'vault operator unseal' and entering an unseal key. Repeat this command with different unseal keys until you reach the threshold (e.g., 3 of 5 keys). Each key holder should enter their key separately.

How many unseal keys do I need?

You need to meet your configured threshold, which is set during Vault initialization. Common configurations are 3-of-5 (need 3 keys from 5 total) or 2-of-3. Check your threshold with 'vault status' when sealed.

When should I manually seal Vault?

Manually seal Vault during security incidents to immediately protect secrets, before major maintenance operations, during compliance audits that require it, or as part of emergency incident response. Use 'vault operator seal'.

What is Vault rekeying and when should I do it?

Rekeying generates new unseal keys, invalidating old ones. Rekey when employees with unseal keys leave the organization, after suspected key compromise, to change the key threshold, or as part of regular key rotation policies.

How do I change the number of unseal keys?

Change the number of keys by rekeying: 'vault operator rekey -init -key-shares=5 -key-threshold=3'. This starts a new rekey operation. Submit existing unseal keys until threshold is met, then new keys are generated.

What is auto-unseal and how does it work?

Auto-unseal uses a cloud KMS (AWS, Azure, GCP) or HSM to automatically unseal Vault on startup. Instead of manual unseal keys, the master key is encrypted by the KMS. Configure in vault config with 'seal' stanza.

Can I unseal Vault remotely?

Yes, you can unseal remotely by setting VAULT_ADDR to your Vault server and running 'vault operator unseal'. Key holders can be in different locations, each connecting to Vault to submit their unseal key.

What happens if I lose unseal keys?

If you lose enough unseal keys to fall below the threshold, your Vault data becomes permanently inaccessible. There is no recovery mechanism. This is why distributing keys to multiple trusted people and storing backups securely is critical.

How often should I rotate unseal keys?

Rotate unseal keys (rekey) at least annually, immediately when key holders leave the organization, after any suspected compromise, and when changing security requirements. Document each rotation for compliance.

Vault Seal, Unseal, and Rekey: Complete Security Operations Guide

Vault's seal/unseal mechanism is a fundamental security feature that protects secrets even when storage is compromised. Understanding these operations is essential for Vault administrators. This guide covers unsealing, sealing, rekeying, and auto-unseal configuration.

Understanding Vault Sealing

When Vault starts or restarts, it enters a "sealed" state where the encryption key (master key) is not loaded into memory. In this state:

All secrets are encrypted and inaccessible
No read or write operations can occur
Only status and unseal operations are available
Even with access to storage, data cannot be decrypted

┌─────────────────────────────────────────────────────────┐
│                    SEALED STATE                          │
│  ┌─────────────┐    ┌──────────────┐    ┌────────────┐ │
│  │   Storage   │    │  Encrypted   │    │  No Access │ │
│  │   (Data)    │───▶│  Master Key  │───▶│  to Secrets│ │
│  └─────────────┘    └──────────────┘    └────────────┘ │
└─────────────────────────────────────────────────────────┘
                           │
                    Unseal Keys
                           │
                           ▼
┌─────────────────────────────────────────────────────────┐
│                   UNSEALED STATE                         │
│  ┌─────────────┐    ┌──────────────┐    ┌────────────┐ │
│  │   Storage   │    │  Decrypted   │    │   Secrets  │ │
│  │   (Data)    │───▶│  Master Key  │───▶│ Accessible │ │
│  └─────────────┘    └──────────────┘    └────────────┘ │
└─────────────────────────────────────────────────────────┘

Vault uses Shamir's Secret Sharing algorithm to split the master key into multiple unseal keys. During initialization, you specify:

Key shares: Total number of unseal keys generated
Key threshold: Minimum keys needed to unseal

Common configurations:

3-of-5: Five keys distributed to different people, any three can unseal
2-of-3: Three keys, any two can unseal (smaller teams)
1-of-1: Single key (development only, not recommended for production)

Checking Vault Status

Before any seal operation, check Vault's current status:

vault status

Example output when sealed:

Key                Value
---                -----
Seal Type          shamir
Initialized        true
Sealed             true
Total Shares       5
Threshold          3
Unseal Progress    0/3
Unseal Nonce       n/a
Version            1.15.0
Build Date         2024-01-01
Storage Type       raft
HA Enabled         true

Key fields:

Sealed: true means Vault is sealed
Total Shares: Number of unseal keys that exist
Threshold: Keys needed to unseal
Unseal Progress: How many keys have been submitted

Unsealing Vault

Step-by-Step Unseal Process

# Check current status
vault status

# Begin unsealing - enter first key
vault operator unseal
# Prompt: Unseal Key (will be hidden):
# Enter first unseal key

# Check progress
vault status
# Should show: Unseal Progress 1/3

# Continue with second key
vault operator unseal
# Enter second unseal key

# Final key to reach threshold
vault operator unseal
# Enter third unseal key

# Verify unsealed
vault status
# Should show: Sealed false

Non-Interactive Unseal

For automation (use with caution):

# Provide key directly (appears in process list!)
vault operator unseal "$UNSEAL_KEY_1"

# Safer: pipe from secure source
echo "$UNSEAL_KEY_1" | vault operator unseal -

Unseal Multiple Nodes (HA Cluster)

In HA deployments, each node must be unsealed separately:

# Unseal primary
VAULT_ADDR=https://vault-1.example.com:8200 vault operator unseal

# Unseal standby nodes
VAULT_ADDR=https://vault-2.example.com:8200 vault operator unseal
VAULT_ADDR=https://vault-3.example.com:8200 vault operator unseal

Manual Sealing

When to Seal Vault

Seal Vault manually in these scenarios:

Security Incidents: Immediately protect secrets if unauthorized access is detected
Maintenance Windows: Before major upgrades or configuration changes
Compliance Requirements: Some audits require demonstrating seal capability
Emergency Response: Part of incident response procedures
Testing: Verify unseal procedures work correctly

Sealing Commands

# Must be authenticated first
vault login

# Seal Vault (requires sudo capability in policy)
vault operator seal

# Verify sealed
vault status

Warning: Sealing immediately stops all applications from accessing secrets. Plan seal operations carefully and notify stakeholders.

Emergency Seal

If you suspect a security breach:

# Immediately seal to protect all secrets
vault operator seal

# Then investigate the incident
# Re-unseal only after securing the environment

Rekeying Vault

Rekeying generates new unseal keys, invalidating all existing keys.

When to Rekey

Personnel Changes: When employees with unseal keys leave
Key Compromise: If any unseal key might be compromised
Threshold Changes: Changing from 3-of-5 to 4-of-7, etc.
Regular Rotation: Annual key rotation for compliance
Security Incidents: After investigating potential breaches

Rekey Process

Step 1: Initialize Rekeying

# Start rekey with new key configuration
vault operator rekey -init -key-shares=5 -key-threshold=3

# Output includes a nonce for the operation
# Nonce: 2dbd10f1-8528-6246-09e7-82b25b8ded63

Step 2: Submit Existing Unseal Keys

Each key holder submits their current unseal key:

# First key holder
vault operator rekey -nonce=2dbd10f1-8528-6246-09e7-82b25b8ded63
# Enter current unseal key

# Second key holder
vault operator rekey -nonce=2dbd10f1-8528-6246-09e7-82b25b8ded63
# Enter current unseal key

# Continue until threshold is met

Step 3: Receive New Keys

Once the threshold is met, new unseal keys are generated:

Key 1: 3cEoW7Z8y...
Key 2: V8HwPkl0j...
Key 3: nKpFm2dL9...
Key 4: BjR7qAeT1...
Key 5: XwY9sZvC4...

Operation nonce: 2dbd10f1-8528-6246-09e7-82b25b8ded63

Vault rekeyed with 5 key shares and a key threshold of 3.

Rekey with PGP Encryption

For enhanced security, encrypt new keys with PGP:

# Initialize rekey with PGP keys
vault operator rekey -init \
  -key-shares=5 \
  -key-threshold=3 \
  -pgp-keys="keybase:user1,keybase:user2,keybase:user3,keybase:user4,keybase:user5"

Each new unseal key is encrypted to the respective PGP key, ensuring only the intended recipient can decrypt it.

Cancel Rekey Operation

If needed, cancel an in-progress rekey:

vault operator rekey -cancel

Auto-Unseal Configuration

Auto-unseal uses external key management systems to automatically unseal Vault on startup.

AWS KMS Auto-Unseal

# vault.hcl configuration
seal "awskms" {
  region     = "us-east-1"
  kms_key_id = "alias/vault-unseal-key"
}

Required IAM permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:DescribeKey"
      ],
      "Resource": "arn:aws:kms:us-east-1:*:key/your-key-id"
    }
  ]
}

Azure Key Vault Auto-Unseal

seal "azurekeyvault" {
  tenant_id      = "your-tenant-id"
  vault_name     = "vault-unseal"
  key_name       = "vault-key"
}

GCP Cloud KMS Auto-Unseal

seal "gcpckms" {
  project     = "your-project"
  region      = "global"
  key_ring    = "vault-keyring"
  crypto_key  = "vault-key"
}

Migration to Auto-Unseal

Migrating from Shamir to auto-unseal:

# 1. Configure auto-unseal in vault.hcl
# 2. Add -migrate flag when starting Vault
vault server -config=vault.hcl -migrate

# 3. Unseal with existing Shamir keys one final time
vault operator unseal
vault operator unseal
vault operator unseal

# 4. Vault generates recovery keys
# 5. Future restarts auto-unseal via KMS

After migration, Shamir keys become "recovery keys" used only for:

Root token generation
Rekeying recovery keys
Disabling auto-unseal

Security Best Practices

1. Distribute Keys Properly

Key Distribution Strategy:
- Key 1: CTO (Executive)
- Key 2: Security Team Lead
- Key 3: Infrastructure Manager
- Key 4: On-Call Engineer (rotating)
- Key 5: Secure Offline Storage (safe deposit box)

2. Store Keys Securely

Use hardware security modules (HSM) or secure enclaves
Never store keys in version control
Consider key management services for key storage
Maintain encrypted backups in geographically separate locations

3. Document Procedures

## Unseal Procedure Runbook

1. Verify incident requiring unseal
2. Contact key holders (minimum 3)
3. Each key holder authenticates identity
4. Key holders submit keys via secure channel
5. Verify Vault is unsealed
6. Document in incident log

4. Enable Audit Logging

# Enable audit logging for all operations
vault audit enable file file_path=/var/log/vault/audit.log

# Monitor for seal/unseal operations
grep "seal" /var/log/vault/audit.log

5. Backup Before Rekeying

# Create Raft snapshot before rekey
vault operator raft snapshot save pre-rekey-backup.snap

# Store backup securely

6. Test Recovery Procedures

Regularly test your ability to:

Unseal Vault after planned restart
Rekey with new key distribution
Recover from disaster scenario

Troubleshooting

Cannot Unseal

Symptom: Keys are rejected during unseal

Causes:

Wrong unseal key entered
Keys from different Vault initialization
Vault was rekeyed and old keys used

Solution:

# Verify you're using correct keys for this Vault
vault status
# Check initialization/rekey timestamps match your key records

Unseal Progress Resets

Symptom: Progress resets to 0/N

Causes:

Timeout between key submissions (10 minutes default)
Vault restarted
Different nonce used

Solution:

Coordinate key holders to submit keys quickly
Check Vault didn't restart during process

All Keys Lost

Symptom: Cannot reach unseal threshold

Reality: Data is permanently inaccessible. This is by design.

Prevention:

Distribute keys to multiple trusted parties
Maintain secure backups
Document key holder contact information
Consider auto-unseal for critical environments

Performance After Unseal

Symptom: Slow operations after unsealing

Cause: Vault rebuilding caches and indexes

Solution:

Allow warm-up period after unseal
Consider pre-warming common paths
Monitor and wait for stabilization

Command Reference

Command	Description
`vault status`	Check seal status
`vault operator unseal`	Submit unseal key
`vault operator seal`	Seal Vault
`vault operator rekey -init`	Start rekey operation
`vault operator rekey`	Submit key for rekey
`vault operator rekey -cancel`	Cancel rekey
`vault operator rekey -status`	Check rekey progress

Next Steps

For more security operations guides, explore our complete HashiCorp Vault series.

Vault Seal, Unseal, and Rekey: Complete Security Operations Guide

Frequently Asked Questions

Related articles

HashiCorp Vault Root Token Regeneration

HashiCorp Vault CLI Install & GUI Setup: 2026 Full Guide

HashiCorp Vault Token Management: Complete Authentication