How do you protect sensitive data when your application is too small, too old, or too specialised to handle encryption itself? This chapter explains the Transit Secrets Engine, which provides Encryption as a Service so any application can encrypt data without managing a single cryptographic key.
Jump to a section
A simple way to picture Transit Secrets Engine for Encryption as a Service
A secure shared commercial kitchen has a single heavy-duty safe. The kitchen's owner gives ten different chefs each a key to this safe. Chef A bakes a secret family-recipe cake, places it in the safe, and locks it. Later, Chef B needs that cake to create a dessert special. Chef B does not open the safe, take the cake out, and then put it back. Instead, Chef B uses the safe's built-in mechanism to precisely slice off a single perfect portion of the cake without ever touching the whole cake or seeing the full recipe. Chef B then locks that portion in a new, separate compartment within the safe for the customer. The original cake stays whole, untouched, and fully protected inside the safe. The safe never reveals the secret recipe or the full cake to anyone who does not own the original key. This is the Transit Secrets Engine. The safe is the engine itself. The chefs are different applications or services within a company. The secret recipe is the encryption key managed by Vault. The cake is the data needing protection. The slicing mechanism is the encrypt and decrypt operations. Nobody ever moves the raw, unprotected data outside the safe. The Transit Secrets Engine lets applications send data to Vault to be encrypted or decrypted using keys that only Vault manages. The application never sees or stores the key, just like Chef B never sees the full recipe. This keeps the encryption key completely isolated from the data it protects, solving the fundamental problem of key management.
The Transit Secrets Engine is a dedicated Vault component that provides Encryption as a Service (EaaS). EaaS means you send plain text data to Vault, Vault encrypts it using a key it manages, and returns encrypted ciphertext to you. You never see the key. You never store the key. The application itself does not need to know anything about cryptography. This is a huge advantage because managing encryption keys is one of the hardest problems in IT security. If an application tries to do its own encryption, it must generate a key, store that key safely, rotate that key on a schedule, and ensure no unauthorised person can access that key. One mistake and all encrypted data becomes compromised. The Transit Secrets Engine removes that burden entirely.
When you enable the Transit Secrets Engine, you create a named key within the engine. A key is a secret piece of information used to perform encryption and decryption. Vault supports multiple key types, but the most common is the AES-256-GCM key. AES stands for Advanced Encryption Standard. 256 is the key size in bits, and GCM stands for Galois/Counter Mode, which provides both confidentiality and integrity checking. You can also use keys based on other algorithms like ChaCha20-Poly1305 or RSA-OAEP. Each key lives inside the Transit engine and has its own policy controlling who can use it for what operation.
Here is how the typical workflow works:
An application wants to encrypt a piece of data like a credit card number or a database password.
The application sends an HTTP API request to Vault's Transit engine endpoint, something like POST /v1/transit/encrypt/my-key-name. The request includes the plaintext data encoded in base64.
Vault authenticates the application using its own identity method, often a token or a Kubernetes service account. Vault then checks that the application's policy permits the encrypt operation on that specific key.
If authorised, Vault uses the managed encryption key to encrypt the plaintext. Vault returns the ciphertext, which is a base64-encoded string that looks like random gibberish.
The application stores this ciphertext in its own database. When it needs the original data back, it sends the ciphertext to the Transit engine's decrypt endpoint.
Vault again checks the application's permissions, then uses the same symmetric key to decrypt the ciphertext and return the original plaintext.
Why would you use Transit instead of encrypting data in the application? The major reasons include key separation, centralised auditing, key rotation, and algorithm agility. Key separation means the people who manage the application (developers, operators) never have access to the encryption key. This prevents insider threats. Centralised auditing means every encrypt and decrypt operation is logged in Vault's audit log. You can see exactly who encrypted what and when. Key rotation becomes a simple configuration change in Vault. You tell Vault to start using a new key version for all new encryption, and Vault can still decrypt old data with the previous version. Algorithm agility means if a cryptographic algorithm becomes compromised, you can switch Vault to a new one without changing application code.
The Transit engine also provides several advanced features. It supports convergent encryption, where the same plaintext always produces the same ciphertext. This is useful for deduplication. It supports signing and verification operations using the same keys. It supports datakey generation, where Vault generates a random encryption key and encrypts it with a master key, then returns both the encrypted key and the plaintext key. The application uses the plaintext key locally to encrypt bulk data, then discards it. Only the encrypted key is stored. This is called envelope encryption and is a best practice for encrypting very large datasets.
The Transit Secrets Engine does not store the data itself. It only stores the encryption keys and performs operations on data passed to it. The application is responsible for storing the ciphertext. This is a critical distinction. Transit is not a data store. It is a cryptographic service.
Finally, you enable the Transit Secrets Engine on a path, usually called transit/. You use the Vault CLI or API to create keys within that path. The engine is mounted at a path similar to how you mount a USB drive to a folder on your computer. Keys inside the engine are identified by name. You can have dozens or hundreds of keys, each with its own rotation schedule, deletion intent, and export restrictions.
Enable the Transit Secrets Engine
You mount the Transit engine on a path, typically transit/, using the Vault CLI or API. This makes the engine available for use. For example: vault secrets enable transit. Without this step, the engine is not available.
Create a Named Encryption Key
Inside the Transit engine, you create a key with a specific name and algorithm. For example: vault write -f transit/keys/my-app-key. This key is the cryptographic secret used for all encryption and decryption. You can create multiple keys for different purposes.
Authenticate the Application to Vault
The application must prove its identity to Vault using a method like a token or AppRole. This step ensures unauthorised software cannot use the Transit engine. Authentication is done before any Transit operation.
Define a Policy Allowing Encrypt/Decrypt
A Vault policy grants the application permission to perform specific operations on the Transit key. For example, a policy with path transit/encrypt/my-app-key and capabilities ['create', 'update'] allows encryption. Without a matching policy, Vault denies the request.
Send Data to Encrypt
The application sends an HTTP request to Vault's Transit endpoint with base64-encoded plaintext. Vault checks the policy, uses the key to encrypt the data, and returns base64-encoded ciphertext. The application stores this ciphertext in its own database.
Decrypt Data When Needed
To retrieve the original plaintext, the application sends the ciphertext to Vault's decrypt endpoint. Vault verifies the application's identity and policy, decrypts using the same key, and returns the plaintext. The application must then decode the base64 to get usable data.
Consider FinSecure, a financial technology company that processes loan applications. Their core application is a twenty-year-old mainframe system written in COBOL. This mainframe holds customers' personal identification numbers, bank account details, and credit scores. The mainframe cannot be upgraded to perform modern encryption. It simply locks data inside its own limited database. FinSecure needs to encrypt this sensitive data before storing it in their cloud-based reporting system. They cannot afford to rewrite the mainframe code. They also must comply with regulatory requirements that demand encryption keys be managed separately from the application.
Here is what an IT professional at FinSecure does:
First, they install and configure a HashiCorp Vault cluster with high availability. They mount the Transit Secrets Engine on the path transit/.
They create a new encryption key named loan-app-data using the Vault CLI: vault write -f transit/keys/loan-app-data. They configure the key to automatically rotate every thirty days.
They write a small Python script that runs on a separate jump server, not on the mainframe. This script reads the raw plaintext from the mainframe's nightly database export.
The script authenticates to Vault using an AppRole. The AppRole uses a RoleID and SecretID that Vault validates. The script never stores a static password.
The script sends each piece of plaintext to the Transit engine's encrypt endpoint. Vault returns ciphertext. The script writes the ciphertext to the new cloud database. The plaintext is never stored anywhere permanent.
For the monthly reporting system, a different script reads the ciphertext from the cloud database, sends it to the Transit engine's decrypt endpoint, and receives the plaintext for report generation. The report is then encrypted again before storage.
The IT professional also sets up Vault audit logging. Every encrypt and decrypt request is logged to a secure log aggregator. If a compliance officer asks who decrypted Customer A's data last Tuesday, the answer is immediately visible in the logs.
They configure a key rotation policy. Every thirty days, Vault creates a new key version. New data is encrypted with the new version. Old data remains decryptable with the old version because Vault keeps the full key history.
They write a simple Terraform configuration that declares the Transit key as infrastructure. This makes the key creation repeatable and auditable. If they need to recreate the environment after a disaster, they run Terraform and the key is provisioned automatically.
The outcome is that sensitive customer data is encrypted everywhere except during the brief moment it is being processed. The mainframe never changes. The encryption keys are managed centrally and rotated automatically. Auditors can see the full trail of encrypt and decrypt operations.
The VA-003 exam tests the Transit Secrets Engine in several specific ways. You must understand what Transit does and what it does not do. The exam loves to create answer choices that confuse Transit with other Vault secrets engines like KV (Key-Value) or PKI (Public Key Infrastructure).
Key exam concepts to memorise:
Transit provides Encryption as a Service. It does not store the data. It only encrypts or decrypts data you send to it. If an answer choice says Transit stores data, it is wrong.
Transit keys are created within the engine. Keys have names. To encrypt, you use the endpoint /transit/encrypt/KEY_NAME. To decrypt, you use /transit/decrypt/KEY_NAME.
The plaintext sent to Transit must be base64-encoded. Vault returns base64-encoded ciphertext. The exam may test that you know to base64 encode before encrypting and decode after decrypting.
Transit supports key rotation. When you rotate a key, Vault creates a new version. The latest version is used for encryption. Older versions remain available for decryption. The exam may present a scenario where you need to rotate a key but still decrypt old data. You can because Vault keeps version history.
Transit supports key types. The most common are aes256-gcm96, chacha20-poly1305, and ed25519. The exam will not ask you to compare algorithm details, but you should know that multiple types exist.
Convergent encryption is a feature of Transit that produces the same ciphertext for the same plaintext. This is useful for deduplication. The exam might test that convergent encryption is non-default and requires explicit enabling.
Transit can be used for signing and verification. This is less common but still tested. Signing proves the data came from the holder of the key. Verification checks that signature.
Transit datakey generation is a separate operation. You can generate a random key from Vault, get it encrypted under a named Transit key, and use it locally for envelope encryption.
Common traps to watch out for:
Confusing Transit with KV Secrets Engine. KV stores secrets. Transit processes secrets. A question might say 'You need to store a database password that your application reads'. The correct answer is KV. If the question says 'You need to encrypt a credit card number without the application seeing the key', the answer is Transit.
Assuming Transit requires the data to be stored in Vault. It does not. The data stays in the application's database. Vault only returns the ciphertext.
Thinking you need to create a client-side key. The key lives in Vault. The application never has access to the key material unless you explicitly export it (which is an advanced feature called exportable keys, and is not the default).
Forgetting about base64 encoding. The exam may present a curl command without base64 and ask you to identify the error.
Question patterns you will likely see: choosing between Transit and KV for a given scenario, identifying the correct API endpoint for encrypt or decrypt, understanding key rotation behaviour, and recognising that Transit does not store data.
The Transit Secrets Engine provides Encryption as a Service, meaning it encrypts and decrypts data without the application ever managing or storing the encryption key.
Transit does not store any data; it only processes data you send to it and returns ciphertext or plaintext.
The plaintext sent to Transit must be base64-encoded, and the returned ciphertext is also base64-encoded.
Transit keys support rotation with version history, so old data can still be decrypted after key rotation.
Convergent encryption in Transit produces identical ciphertext for identical plaintext, enabling deduplication.
Transit can perform signing and verification operations in addition to encryption and decryption.
You can use the Transit engine to generate datakeys for envelope encryption of large datasets.
These come up on the exam all the time. Here's how to tell them apart.
Transit Secrets Engine
Performs encryption and decryption operations on data passed to it.
Does not store the data, only returns ciphertext or plaintext.
Manages encryption keys centrally and supports key rotation.
KV Secrets Engine
Stores secrets as static key-value pairs (e.g., passwords, API keys).
Returns the secret value when read by an authorised application.
Does not perform any cryptographic transformations on the stored values.
Transit Encryption
The entire plaintext is sent to Vault for encryption.
Best for small payloads (e.g., individual database fields).
Latency includes network round trip for each piece of data.
Envelope Encryption (with Transit datakey)
A datakey is generated and encrypted by Vault; plaintext is encrypted locally.
Best for large payloads or high-throughput scenarios (e.g., files, backups).
The datakey is used locally so only one round trip per datakey is needed.
Symmetric Key (e.g., AES-256-GCM)
Uses the same key for encryption and decryption.
Faster than asymmetric for bulk data.
Key must be kept secret and shared between parties.
Asymmetric Key (e.g., RSA-OAEP)
Uses a public key for encryption and a private key for decryption.
Slower, suitable for small data like key exchange.
Public key can be shared; private key remains secret.
Mistake
The Transit Secrets Engine stores your encrypted data permanently inside Vault.
Correct
Transit only performs encryption and decryption operations on data you send to it. Vault does not store the ciphertext or plaintext. The application must store the ciphertext in its own database or file system.
This mistake comes from confusing Transit with a secrets storage engine like Key-Value. The word 'engine' sounds like it holds things, but Transit is a processing engine, not a storage engine.
Mistake
You must generate and manage a separate encryption key inside your application code to use Transit.
Correct
The encryption key lives entirely inside Vault. The application only sends data and receives encrypted or decrypted results. The application never sees or manages the key.
People familiar with older encryption patterns assume they need to handle keys locally. Transit is designed to remove that responsibility from the application, which is the whole point of Encryption as a Service.
Mistake
A Transit key can only encrypt and decrypt, never sign or verify data.
Correct
Transit keys can also perform signing and verification using algorithms like Ed25519. Signing proves the data originated from the holder of the key. Verification checks that signature. This is a separate operation from encryption.
Beginners often associate Transit only with encrypt/decrypt because those are the headline features. The exam tests the broader capability including signing and datakey generation.
Mistake
If I rotate a Transit key, all previously encrypted data becomes unreadable.
Correct
Vault keeps a version history of each key. When you rotate, a new version becomes the default for encryption. Old versions remain available for decryption. You can always decrypt old data with the old version.
In everyday life, 'rotate' often means replace entirely. People assume the old key disappears. Vault's rotation model is additive, not destructive, which is a critical distinction for the exam.
Mistake
The Transit engine requires the application to authenticate to Vault using a username and password.
Correct
Transit uses Vault's standard authentication methods such as tokens, AppRole, Kubernetes auth, or LDAP. There is no special Transit-specific authentication. The application must have a policy that allows the encrypt or decrypt operation on the specific key.
New learners sometimes think each Vault feature has its own login system. Vault has a unified authentication layer. The Transit engine just checks the policy after authentication succeeds.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. KV stores secrets as static key-value pairs in Vault. Transit encrypts or decrypts data you send to it, but it never stores that data. They are completely different purposes.
When you rotate a Transit key, Vault creates a new version. The new version is used for all future encryption operations. Old versions remain available for decryption of existing ciphertext. You do not need to re-encrypt old data.
Transit is designed for small payloads. For large files, you should use envelope encryption: generate a datakey from Transit, encrypt the file locally with that datakey, and store only the datakey encrypted under a Transit key.
No. The encryption key is fully managed by Vault. You only need to know the key name and have the correct Vault policy. The key material is never exposed to you or your application by default.
Transit centralises key management and auditing. The key never leaves Vault, key rotation is simple, and every operation is logged. In application code, you would have to manage key storage, rotation, and access controls yourself, which is error-prone.
Yes, but you must carefully manage their Vault policies to control which application can encrypt, decrypt, or only read key metadata. Sharing a key is common but requires proper access control to avoid one application decrypting another's data.
You've finished Transit Secrets Engine for Encryption as a Service. Continue through the VA-003 study guide to build a complete picture of the exam.
Done with this chapter?