Seal/Unseal Process and Key Management

Let’s start with the biggest problem Vault solves: protecting secrets even from itself. A secret, in this context, is any piece of sensitive data you want to keep safe, such as a database password, an API key, or an encryption key. Vault’s job is to store and manage these secrets. But here is the key paradox: if Vault stores the master key that encrypts all your other secrets, what encrypts that master key? If an attacker breaks into the server running Vault, they can read that master key from memory and decrypt everything. This is a chicken-and-egg problem. HashiCorp Vault’s solution is to never store the master key in a usable form. Instead, Vault uses a process called 'sealing' and 'unsealing' to protect this master key.

A Vault server starts in a 'sealed' state. When sealed, Vault’s entire storage backend (the place where secrets are saved) is encrypted using encryption keys that Vault itself does not know. It is like a locked suitcase where Vault has lost the combination. The server can accept HTTP requests, but it cannot read or write any secrets. It simply refuses all requests that require access to secrets. The sealed state is Vault’s default security posture after a restart, a shutdown, or a suspected intrusion. You can even manually seal Vault if you suspect an attack. Sealing effectively destroys Vault’s ability to access its own secret data, which means an attacker cannot read anything even if they gain full access to the running server.

The unsealing process is the recovery action. It makes Vault operational again. This process is built around a cryptographic key called the 'master key'. When Vault is initialised for the first time, it generates this master key. However, Vault never stores the master key in a single place. Instead, it uses a technique called 'Shamir's Secret Sharing' to split the master key into multiple pieces, called 'unseal keys' or 'key shares'. This splitting is a mathematical trick: you have a secret (the master key), and you can split it into N pieces. You can then configure Vault to require only K of those pieces to reconstruct the original secret. This is known as the (K, N) threshold scheme. For example, a common configuration is (3, 5): you generate five unseal key shares, but you only need three of them (any three) to unseal Vault.

During the unsealing process, an administrator must provide a different physical unseal key each time. Each key is entered using the 'vault operator unseal' command or via the web UI. Each unseal key piece is useless on its own; it reveals nothing about the master key. The administrator enters one key share, then another, and so on. Once the threshold number of key shares has been provided (for instance, three out of five), Vault’s internal algorithm mathematically recombines them to reconstruct the master key. With the master key in memory, Vault can now decrypt its storage backend and begin reading and writing secrets. From that moment, Vault is 'unsealed' and fully operational.

Why go through this elaborate process? It protects against a single point of compromise. If one administrator’s unseal key is stolen, an attacker cannot unseal Vault alone. They would need to steal multiple keys from multiple people. This is called 'separation of duties'. It also provides resilience: you can distribute keys to different team members, and you can still unseal Vault even if one or two members are on holiday or unreachable, as long as the threshold is met.

Because the master key is only held in memory (not on disk) after unsealing, any action that clears memory — such as restarting the server or a manual seal — forces you to go through the unsealing process again. This is by design. This means an attacker who steals the hard drive of a Vault server cannot unseal it; they have no unseal keys. The master key is gone. The attacker is left with an encrypted, useless storage file.

The seal/unseal process is separate from authentication. Even after Vault is unsealed, you still need to log in with a valid token or authentication method (like LDAP, Microsoft Entra ID, or a username/password) to access secrets. The seal/unseal process only controls whether Vault itself can read its own encrypted storage, not who is allowed to read secrets.

There is an advanced option called 'auto-unseal' where Vault can delegate unsealing to a trusted external service, like a hardware security module (HSM) or cloud KMS. This removes the need for human interaction after a restart but is a more advanced topic for the Associate exam. The core concept you need for the VA-003 is the manual, multi-key unseal process using Shamir's Secret Sharing.

Consider a real-world scenario at a fintech company called PayFlow. PayFlow uses Vault to store database credentials for its payment processing systems. The company has five senior engineers on a 'vault operations' team, each responsible for guarding one of the five unseal key shares. The threshold is set to 3. Here is what happens step by step in a realistic business context:

One morning, the company’s data centre experiences a power outage that causes the Vault server to restart. When the server comes back online, Vault is automatically sealed and completely non-functional. The payment processing system cannot connect to the database because it cannot retrieve the password from Vault. An alert is sent to the on-call engineer, Priya. She is the first to arrive at the console.

Priya executes the 'vault operator unseal' command and enters her unseal key share, but nothing happens. That is normal: one share alone is insufficient. The command line shows a progress indicator: '1/3 keys provided'. She then calls two other engineers, Raj and Mei, who are on standby. They each log into the Vault CLI from their laptops and enter their own unseal key shares. After the third key is entered, the command line shows 'Vault is unsealed'. The payment system immediately begins functioning again.

During a quarterly security review, the company decides to improve its key management. They implement the following practices:

- They store each unseal key share in a separate physical safe at different office locations, ensuring no single location has more than one key. - They set up an emergency 'break-glass' procedure: the company CFO holds a sealed envelope containing a printed copy of one of the key shares, for use only in an emergency when no engineer is available. - They perform a 'rekeying' operation once a year to generate new unseal key shares, in case any existing shares have been compromised. - They train all new vault operations engineers on the unsealing process using a non-production environment, so they can practise without risking real secrets. - They configure Vault to automatically seal itself if it detects an unusual number of failed authentication attempts, preventing an attacker from brute-forcing their way past the seal. The IT team’s monthly runbook includes a scheduled 'seal/unseal drill' where they intentionally restart a test Vault instance and practise the multi-person unseal workflow, timing how fast they can restore service. This ensures that the process is well understood and can be executed quickly under pressure. In production, they monitor Vault’s seal status with a dashboard alert; if Vault remains sealed for more than five minutes, an automated PagerDuty notification is sent to the entire operations team. The team uses 'vault status' to check seal state remotely. They also keep a detailed log of every unseal event, recording which key shares were used and by whom, to provide an audit trail for compliance with financial regulations.