Transit and key lifecycle | Vault Associate 003: secrets and operations

Concept and mechanism

Transit provides cryptographic operations without storing the submitted application document as a data repository. The client must retain ciphertext and present it for decryption. This model can separate key administrators from those encrypting or decrypting with a specific key. Define policies around these needs rather than granting key administration to every consumer. Input base64 is payload transport encoding rather than encryption. Calls still need TLS and authorization. Output identifies the version used, allowing Vault to select appropriate decryption material when that version and access policy permit it.

Guided application

In a fictional project, a key moved from v2 to v3 while old data remains in application storage. This does not prove failure: rotation creates material for future operations rather than rewriting existing files. Rewrap can return updated ciphertext without returning plaintext to the migration process. That process must persist and validate the result. Before raising min_decryption_version, inventory backups and historical documents still required. A version outside the permitted set can make those data unavailable to consumers even while business retention remains active. Include restore exercises, acceptance criteria, and a decision owner. Editing a ciphertext prefix does not perform re-encryption and is not a valid migration.

IN PRACTICE

Key rotation and backup migration are separate tasks with their own evidence.

Common pitfalls

Base64 as encryption; Transit as storage; rotation as rewrap; edited prefix as migrated data.

Related topics: Authentication and identity · Policies, paths, and capabilities · Tokens, leases, and renewal

Take this idea with you

Retain ciphertext and validate dependencies before restricting old versions.

Create account

Reference: Transit encryption and key rotation · Vault Associate (003); product version tested: Vault 1.19