# Why can't I change the unseal/recovery key after migration to transit auto-unseal?

**URL:** <https://discuss.hashicorp.com/t/why-cant-i-change-the-unseal-recovery-key-after-migration-to-transit-auto-unseal/77280>\
**Category:** Vault\
**Tags:** vault\
**Created:** [March 26, 2026, 11:03am UTC](https://discuss.hashicorp.com/t/why-cant-i-change-the-unseal-recovery-key-after-migration-to-transit-auto-unseal/77280 "2026-03-26T11:03:39Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![au1](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/au1/32/46402_2.png) [@au1](https://discuss.hashicorp.com/u/au1)\
**Post date:** [March 26, 2026, 11:03am UTC](https://discuss.hashicorp.com/t/why-cant-i-change-the-unseal-recovery-key-after-migration-to-transit-auto-unseal/77280/1 "2026-03-26T11:03:39Z")

</div>

I have successfully migrated the seal type for a Vault cluster from `shamir` to `transit`. During this process, Vault did not create recovery keys. Running the rekey procedure (`vault operator rekey`) yields an empty list of keys (tried CLI and REST API). Amazingly, I can repeat this procedure forever, and Vault happily accepts the original unseal key from its initial setup. So, it looks like I’m unable to change or replace the unseal keys, meaning anyone who knows them can create new root tokens forever. The documentation does not explain this behavior.

Looks like this issue affects only migrated seal types.

Can somebody with insights please explain what’s going on behind the scenes?

By the way, the CLI outputs “nothing” (no new keys) and should probably print out something more helpful if Vault cannot rekey:

```auto
$ vault operator rekey
Rekey operation nonce: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Unseal Key (will be hidden):

Operation nonce: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Vault unseal keys rekeyed with 1 key shares and a key threshold of 1. Please
securely distribute the key shares printed above. When Vault is re-sealed,
restarted, or stopped, you must supply at least 1 of these keys to unseal it
before it can start servicing requests.

```

Thanks for your help.

---

<div class="post-metadata">

**Author:** ![jonathanfrappier](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/jonathanfrappier/32/28004_2.png) [@jonathanfrappier](https://discuss.hashicorp.com/u/jonathanfrappier)\
**Post date:** [March 28, 2026, 10:33pm UTC](https://discuss.hashicorp.com/t/why-cant-i-change-the-unseal-recovery-key-after-migration-to-transit-auto-unseal/77280/2 "2026-03-28T22:33:31Z")

</div>

When you use an auto-unseal service such as transit, or a KMS, your unseal keys are handled by the external system - in this case transit. With Shamir, its manual, which is why it gives you keys.

Rekey on its own produces the unseal keys, for your recovery keys you want to use the [`-target` parameter.](https://developer.hashicorp.com/vault/docs/commands/operator/rekey#target)

More details in:

> **[How-to rekey vault (recovery-keys) when using auto-unseal](https://support.hashicorp.com/hc/en-us/articles/4404364271763-How-to-rekey-vault-recovery-keys-when-using-auto-unseal)**
>
> Introduction
> When a Vault server is first initialized, Vault generates a master key and immediately splits this master key into a series of key shares following Shamir's Secret Sharing Algorithm. J...