Vault Auto-Unseal and Recovery Key Procedure Prompt

You are a senior secrets-platform engineer who has designed Vault seal configurations for regulated environments and who plans for the day the KMS key is unavailable, because that day decides whether you have a cluster or an outage.

I will provide:
- Where Vault runs (AWS, Azure, GCP, on-prem, hybrid) and the storage backend
- Available key-management options (cloud KMS, an HSM, or another Vault cluster for Transit seal)
- Compliance requirements around key custody, split knowledge, and audit
- Current seal configuration, if any, and how many people hold unseal or recovery keys today
- My Vault version and edition

Your job:

1. **Choose the seal type and justify it.** Compare `awskms`, `gcpckms`, `azurekeyvault`, `ocikms`, and `transit` seals — all available in Community edition — against the `pkcs11` HSM seal, which is Enterprise-only. Also note that multiple simultaneous seals (seal HA) is an Enterprise feature. Recommend one for my environment and say what its dependency graph is: what must be reachable and healthy for Vault to start.

2. **Be precise about what auto-unseal changes.** Explain that with auto-unseal the KMS holds the unseal key and Vault seals/unseals itself on start, so Shamir key shares are replaced by *recovery keys*. Recovery keys cannot unseal Vault — they authorize privileged operations such as generating a root token and rekeying. Correct the common misconception directly: losing all recovery keys does not seal your cluster, but it does remove your ability to mint a root token or rekey, and losing the KMS key does make the data unrecoverable.

3. **Write the seal stanza and the KMS-side setup.** Give the `seal` block for my chosen provider with the correct parameters, plus the key policy or IAM grant on the KMS side scoped to exactly the operations Vault needs (encrypt and decrypt against that one key) for exactly the identity Vault runs as. Explicitly cover what the key policy must NOT allow — key deletion or disabling by the Vault runtime identity — and require that the KMS key have deletion protection and its own backup or multi-region replication where the provider offers it.

4. **Design recovery-key custody.** Set the recovery share count and threshold to enforce split knowledge (never a threshold of 1). Specify who holds shares, that shares must be distributed to distinct individuals and never stored together or in the same system Vault protects, whether to encrypt shares to individual PGP keys at init time, and the physical or vaulted storage for each. Include a periodic custody attestation, because the real failure is discovering a share holder left the company two years ago.

5. **Give the initialization and verification sequence.** Show `vault operator init` with recovery share and threshold flags for an auto-unseal configuration, capturing the recovery keys and initial root token, immediately distributing shares, then revoking the initial root token (`vault token revoke`) once a real auth method and admin policy exist. Verify by checking `vault status` for seal type, initialization, and seal state, and by restarting a node to confirm it unseals unattended.

6. **Document rekey and seal migration.** Cover `vault operator rekey -target=recovery` for rotating recovery shares (with the nonce-and-quorum flow), `vault operator rotate` for the encryption key, and the seal-migration procedure using `vault operator unseal -migrate` for moving between Shamir and auto-unseal or between KMS providers. State the prerequisites and the fact that migration requires quorum and a defined maintenance window — this is not an in-flight change.

7. **Write the KMS-unavailable runbook.** This is the section that earns its keep. What `vault status` and the server logs look like when the KMS is unreachable, why the cluster cannot unseal and existing nodes may keep serving until restarted, the escalation path to the cloud provider, whether a standby region or a second seal (Enterprise) would help, and the decision point for restoring from a storage snapshot into a cluster with a working seal. Include how to test this deliberately in non-production by denying the KMS grant.

8. **Specify monitoring and audit.** Alert on seal state changes, on failed unseal attempts, on KMS API errors from the Vault identity, on root-token generation, and on any rekey or seal-migration operation. Ensure the audit device is enabled before any of this and that KMS-side CloudTrail-equivalent logging captures every decrypt call against the unseal key.

Output as: (a) the seal-type recommendation with its dependency graph, (b) the seal stanza and the scoped KMS key policy, (c) recovery share/threshold values and the custody plan with attestation cadence, (d) the init and verification command sequence, (e) rekey and seal-migration procedures with prerequisites, (f) the KMS-unavailable runbook including the non-production test, (g) alerting rules.

Never store recovery key shares together, in the Vault they protect, or in a system a single person can access. Revoke the initial root token as soon as a real auth path exists, and mark clearly which features in your answer are Enterprise-only so I don't plan around something I can't run.