OpenBao transit encryption as a service: when applications should stop handling keys
The transit engine in OpenBao keeps encryption keys inside OpenBao while applications call it to encrypt, decrypt, sign, verify and HMAC data. The application never receives the key material, so the key can no longer be copied into logs, container images or configuration files. This matters most for teams that encrypt fields or files with keys stored in config or code. In those setups, rotating a key means redeploying every service that holds a copy, and an auditor who asks who used which key has to rebuild the answer from application logs. OpenBao documents encryption as a service as one of its core capabilities. Transit-specific behavior, such as supported algorithms, key types and rotation controls, should be confirmed in the current OpenBao documentation before design begins.
Several teams usually need this pattern. Application teams that handle personal, payment or health data across multiple services benefit from one place where encryption is applied and governed. Platform teams that run shared services want to set a key policy once and have it apply to every caller. Security and compliance teams want a record of cryptographic operations that they can tie to a identity. Teams building internal signing, such as signed tokens or webhook payloads, can use the sign and verify operations instead of keeping signing keys in their own code. In each case, the decision turns on who may use a key and what they may do with it. Write that policy down before any application is changed.
Transit encryption is a poor fit in several situations. Bulk encryption of large files sends every payload through a network call to OpenBao, so throughput and latency must be measured against the actual workload before rollout. Systems that must keep working during a cluster outage, such as offline devices or edge sites with intermittent links, need a local key strategy or a different design. Legacy applications that cannot be changed to call an API may be better served by an encryption library at the application layer, with keys managed under a documented process. Teams without anyone responsible for operating OpenBao, including its upgrades, backups and access policies, should expect that operating burden to fall on them after delivery.
Before choosing this pattern, run three checks. First, inventory every place an application currently reads a key from configuration, code or a secret store, and record which keys are shared across services. Second, decide the failure behavior: if OpenBao is unreachable, should a service queue writes, fail closed or follow a documented fallback path? The answer shapes how OpenBao is deployed, and the high availability design, including the supported HA storage backends, should follow from it. Third, confirm which key types and rotation operations the current release supports for your use case. A quote for this work should list the inventory, integration design, test plan, runbooks and operator handover as separate line items, with ongoing operations stated separately.
Which transit options fit which data and application needs
This table compares the main OpenBao transit key options, including the external key option added in 2.7.0, by purpose, fit and the check to make before adopting each. Settings and behavior vary by version, so confirm specifics against the OpenBao transit documentation for the version you run. The main takeaway is that each option moves a trust or data-handling decision, not only a cryptographic one.
| Option | What it is for | When it fits | Trade-off or check |
|---|---|---|---|
| Key rotation | Creates a new version of a named key while older versions remain available to decrypt existing data. | Routine rotation policies, or a response to suspected exposure of a key that protects stored data. | Confirm whether stored ciphertext must be re-encrypted, who runs that work, and how it is scheduled. |
| Convergent encryption | Produces the same ciphertext for the same plaintext and context, so equal values can be matched without decrypting them. | Lookups or deduplication on fields where applications must match records without exposing plaintext. | Equal ciphertexts reveal equality and can expose patterns. Assess this against your data classification and confirm derivation settings. |
| Imported keys | Brings key material generated elsewhere into the transit engine instead of generating keys inside OpenBao. | Keys must originate in an existing HSM, key ceremony or prior system, or you are migrating existing key material. | Confirm the import procedure for your version and plan custody and backup of the source key before importing. |
| Sign and verify | Signs data with a managed key so applications can verify signatures without holding the private key. | Signing tokens, artifacts or records where verifiers need only the public key and can fetch it reliably. | Confirm supported algorithms and key types for your version, and decide how verifiers receive public keys after rotation. |
| HMAC | Computes and verifies keyed message authentication codes using a key that stays inside OpenBao. | Integrity checks on messages or records where only parties with access to the managed key should verify them. | An HMAC proves integrity only to holders of the key. Confirm which systems verify, and that algorithms match on both sides. |
| External key option (added in 2.7.0) | Lets transit work with keys managed outside the standard transit key storage, as introduced in OpenBao 2.7.0. | Only where a documented requirement for external key custody applies and the team has verified the option covers that case. | Confirm exact scope, supported providers, behavior when the external source is unavailable, and interaction with rotation and backup. |
How key rotation and convergent encryption change your data model
Rotating a transit key creates a new key version. New encryptions use the latest version, but ciphertext written under earlier versions must stay decryptable for as long as those versions remain permitted by the key's minimum decryption version. Applications therefore need to handle mixed key versions in the same column, table or message queue from the first release. Before the first production write, decide whether old versions will ever be retired. If they will, plan a rewrap pass with the transit rewrap operation so stored values move to the latest version without the application ever holding plaintext. Confirm the exact parameters and behavior for your OpenBao version in the transit documentation before you commit to a design.
The data model has to carry that version information. Store the ciphertext exactly as OpenBao returns it, including its version prefix, and avoid application code that parses or assumes a fixed format, because the format and length can change between versions and key types. Size columns for the longest expected ciphertext, not the plaintext. Identify every field that needs indexes, sorting, reporting or search, since encrypted values cannot be range-searched or sorted meaningfully. Add contract tests that write data under one key version, rotate, and then read, update and rewrap the same records. These tests catch the cases where a service assumes a single version and fails only after rotation.
Convergent encryption is a deliberate choice, not a default setting to switch on for convenience. In the transit engine it depends on derived keys and a context value, and it produces the same ciphertext for the same plaintext within that context. That is what makes equality lookups, deduplication and joins on protected values possible. The trade-off is that anyone who can read the stored ciphertext can see which rows hold the same value. For low-cardinality fields such as status flags, country codes or yes or no answers, an observer can also test candidate values against the ciphertext. Confirm the nonce behavior, the derived-key requirement and how context is set for your version, and document that choice next to the field it protects.
Make these decisions per data class, with the security owner, before any schema is built. For each class, record the lookup and deduplication needs, what an observer could learn from equal ciphertexts, how often the key is expected to rotate, and whether old versions must be retired. Mark each class as randomized, convergent or not encrypted at the field level. Then test rotation on non-production data first. Copy a representative dataset, including the edge cases your application handles, rotate the key, run the rewrap pass, and confirm that reads, lookups, updates and rollback all behave as the design says. Keep the results as evidence for the security review, and rerun the test whenever the key policy or the application's encryption calls change.
How to set up a transit key for one application
This sequence takes one application from a running OpenBao cluster to a transit key it can use for encrypt and decrypt calls, with a policy limited to that key. Each step closes with a check, so the team can confirm the setup works and that other identities are refused. The exact commands should be taken from the current OpenBao docs.
Confirm the cluster and scope
Start from a running, unsealed and initialized OpenBao cluster, and use an operator identity allowed to manage mounts, keys, policies and auth methods. Decide whether the transit engine goes into its own namespace or a dedicated path, and record the application name, key name and the team that owns both. Done when the cluster status reports it is initialized and unsealed, and the namespace or path is written into your change record. Take the exact status and namespace commands from the current OpenBao docs.
Enable the transit secrets engine
Using the operator identity, enable the transit secrets engine at the path you chose. Keep the path specific to the application or team so that policies can target it precisely. Done when the mount list shows transit at that path with the expected engine type. Confirm the enable syntax and mount options in the current docs before running the command.
Create the encryption key
Create a named key under the transit mount with the options your design requires, such as the key type, whether the key may be deleted or exported, and whether convergent encryption is needed. Several of these choices are hard to undo, so review them against your data classification before any application encrypts data. Done when reading the key back shows the settings your team approved. Confirm which options can change after creation in the docs.
Write a least-privilege policy
Write a policy that grants encrypt and decrypt on this key's path and nothing broader. Leave out key deletion, configuration changes, rotation rights and listing of other keys, and keep rotation with the team that owns the key. Done when the policy is stored and reading it back shows only the capabilities you intended. Check the path syntax against the current docs, since a wildcard in the path can grant access to more keys than you meant.
Enable AppRole and bind the role
Enable the AppRole auth method, which the OpenBao docs recommend for servers, and create a role that attaches only the policy you just wrote. Set token lifetimes and secret ID handling to match your environment, and deliver the role ID and secret ID through your secret delivery process rather than placing them in images or source control. Done when a login with the role ID and secret ID returns a client token whose attached policy is the one you wrote.
Prove the round trip
Using the token from the AppRole login, send a non-sensitive test value to the encrypt endpoint for the key, then send the returned ciphertext to the decrypt endpoint. Confirm in the docs how plaintext must be encoded before it is sent, and how the decrypted output is returned. Done when the decrypted output matches the original test value. Clear the test value from shell history and logs afterward.
Confirm other identities are denied
Repeat encrypt and decrypt with identities that should not have access: a token with no policy, a token with an unrelated policy and a token issued for another application. Also record what the operator and root-level identities can do, because administrators are not always blocked by an application policy. Done when each unauthorized attempt returns a permission denied response. Keep the results with the setup notes.
Record the setup and audit access
Write down the mount path, key name, policy name, AppRole name, and who owns rotation and access reviews. Confirm that an audit device is enabled, so the test encrypt and decrypt requests appear in the audit log in the form your configuration sets. Done when the audit entries for your test calls are visible to the team that will review them. Confirm audit device setup in the current docs.
Security and operational considerations for transit keys
A transit engine holds the keys that protect every application that calls it, so its own controls matter as much as the encryption it performs. The cards below cover the decisions and checks that protect the service itself: policy scope, workload authentication, audit logging, storage for the HA cluster, and namespace boundaries between teams or customers.
Policy scope per key
Each transit key should be reachable only by the workloads that need it for the operations they perform. Policies can separate encrypt, decrypt, sign, verify and HMAC permissions, and can restrict key rotation and key deletion to administrators. Verify in your environment that each application identity has only the paths and operations it uses, and that no shared policy grants decrypt rights to a service that only needs encrypt.
Auth method choice for workloads
The auth method decides how a workload proves its identity before it receives a token that can call the transit engine. OpenBao documents AppRole for servers and Kubernetes, JWT/OIDC and TLS certificate methods, among others, and recommends Userpass only for developer machines. Confirm which method each workload class uses, how secret IDs or service account tokens are issued and rotated, and what token TTLs apply to transit callers.
Audit logging of cryptographic operations
Every encrypt, decrypt, sign and HMAC call should produce an audit entry, so teams can reconstruct which identity used which key and when. Audit devices are configured on the cluster, and the design should decide where logs are written, how long they are retained and whether request data is HMAC-hashed before it leaves the cluster. Confirm that an audit device failure is handled as planned and that someone reviews the log stream.
HA storage backend
The transit service depends on the storage backend that holds encrypted key material and cluster state. OpenBao's officially supported HA backends are integrated storage (Raft) and PostgreSQL, and the docs describe PostgreSQL as easier to operate safely than Raft. Verify the backend choice, the number of nodes, backup and restore procedures for the storage layer, and the failover behavior you have tested, because losing the backend can block every application that calls transit.
Namespace boundaries for teams or customers
Namespaces let several teams or customers share one OpenBao cluster while keeping their mounts, keys, policies and administrators separate. The boundary matters for who can see or manage a key, so the design should state which namespace owns each transit mount and who holds administrative rights inside it. Confirm that no policy written at the root level grants cross-namespace access that the tenancy model does not intend.
Where the external key option in 2.7.0 fits and what it changes
The external key option added to the OpenBao transit engine in 2.7.0 matters only if your transit keys must stay under a key source that your organization already governs. Before you plan around it, confirm three things in the 2.7.0 release notes and documentation: which key types and transit operations the option supports, how key material is referenced from the transit engine (by identifier, handle or configuration path), and which additional libraries, network paths or services the integration needs at runtime. The OpenBao releases page lists v2.7.0 with a release date of September 23, 2026, so record that date in your change file and pin the exact version you test and deploy.
The central decision is where custody of key material sits. With transit keys held inside OpenBao, key material is stored in OpenBao's own storage and protected by its barrier, and your team controls it through OpenBao policies, audit devices and backups. With the external option, custody or key material sits in a system that already has its own access reviews, rotation procedures and logging. Choose the external path when a policy, contract or regulator assigns key custody to that system and your auditors expect one evidence trail. Keep keys inside OpenBao when the added dependency would add more operational risk than it removes.
Each path changes how failures behave. If the external source is unavailable, encrypt and decrypt requests may fail even when the OpenBao cluster itself is healthy. Ask the vendor or documentation whether cached material is ever used during an outage, how recovery is supposed to work, and who can rotate keys or disable a key. Also confirm whether a key can be exported and which party holds the audit record of each key use. Write these answers into the design before the build starts, because moving key custody after data is encrypted may require re-encryption planning that you should estimate with your own data volumes.
Plan the rollout as a repeatable test. Build a non-production cluster on the pinned version, run encrypt, decrypt, sign, HMAC and rotation calls from a representative application, and simulate loss of the external source. Check that each audit entry shows which identity acted and which key version was used. Treat any move to a later patch release, such as v2.7.1 (released October 1, 2026), as a new test cycle rather than an automatic upgrade. Keep the internal-key path documented as a fallback until the external path has passed each of these checks in your environment.
Limits and what to confirm in your environment
Transit encryption looks simple until a specific key type, cluster topology or load profile is in play. The cards below list the questions to answer against your chosen OpenBao version and your own test results, not against assumptions carried over from Vault or from a general description of the engine.
Is your key type and operation available?
Confirm that the key types, operations and options you plan to use, such as signing, HMAC, convergent encryption or imported keys, exist in the exact OpenBao version you will run. The external key option was added in 2.7.0, so a cluster on an earlier line will not offer it. Check the transit engine documentation for your version and record the result in your design review.
What throughput and latency will you see?
Published documentation does not give a throughput or latency figure you can plan against, because results depend on your hardware, network path, key types, payload sizes and request concurrency. Build a load test that mirrors your real call pattern, including bursts from batch jobs, and measure p95 and p99 latency at the application edge. Use those results to size nodes and decide whether applications should batch requests.
How does your storage backend fail over?
Integrated storage (Raft) and PostgreSQL both support high availability, but they fail over differently and need different operational skills. Ask how leader election and standby promotion behave in your topology, how long clients see errors during a leader change in your own tests, and who restores a lost quorum or database. Rehearse a node loss and a database failover before go-live.
How are key versions retained and retired?
Rotation creates new key versions, but old versions must remain available to decrypt existing ciphertext and must be retired deliberately. Confirm the minimum decryption version, the trim behavior and the process for re-encrypting stored data before old versions are removed. Document who approves retirement, because removing a version too early makes data unrecoverable.
Does the Vault migration baseline apply to you?
The migration guide describes in-place replacement of the Vault server process and was tested against one Vault community edition release, not Vault Enterprise. Confirm your Vault version, whether your cluster was bootstrapped before Vault 1.3 and needs a rekey, and whether disable_mlock must be removed from your configuration. If any of these differ from the tested baseline, plan a staging rehearsal before production.
What transit encryption as a service costs and what it takes to implement
What drives the cost of transit encryption as a service implementation?
The cost follows the written scope. DeployOpen does not publish a price list, so a quote is the only way to get a figure for your environment. The main components are planning and key policy design, deploying and hardening the OpenBao cluster in your infrastructure, integrating each application that calls transit, testing, documentation and handover. Most of the build is one-time work. Upgrades, support and continuous testing recur and can be set up as a retainer if you want them.
Main cost drivers:
- Number of applications and services that will call the engine
- Languages, frameworks and client code that must change
- Key types, rotation rules and whether keys must be imported or held in an external key store
- Chosen storage backend and high availability design
- Identity integration and the compliance evidence you need
Ask for a quote that lists deliverables, assumptions, your responsibilities and how scope changes are priced.
How long does a first transit encryption implementation usually take?
Duration depends on how many applications will use transit and how many key decisions your organization must make first. The written plan states the timeline for your case. The work usually moves through the same phases: agreeing key policy and ownership, preparing the cluster, configuring transit mounts and access policies, integrating one pilot application, testing rotation and recovery, then rolling out to the remaining applications. The pilot matters most because it exposes application changes early. The first implementation usually takes longer than later ones, because policy and identity decisions are made once and reused. If you plan to use the external key option added in OpenBao 2.7.0, add time for the key store integration and its testing. Ask for milestones and the dependencies that could move them.
What must our internal team provide before implementation starts?
Several groups of people and resources affect how smoothly the work goes, and they matter as much as the software.
Key policy owners decide which data each key protects, who may encrypt and decrypt, how often keys rotate and when old key versions can be retired. Security, data protection and business owners usually need to sign off.
Application teams provide code access, a test environment and an engineer who can change how their service stores and reads encrypted fields.
A running cluster or infrastructure we can reach, with networking, certificates, backups and monitoring, or a written plan to build it.
Test data that matches the production shape without exposing live personal or payment data.
An identity administrator who can configure how applications authenticate to OpenBao.
Can one internal engineer implement transit encryption on their own?
One engineer can usually build a proof of concept on a non-production cluster if they already know OpenBao well, but a production rollout typically needs more people. The engineering work is only part of it. Someone must own key policy decisions, coordinate changes in every application that encrypts data, set up high availability and backups, and run on-call support once services depend on the engine. If the engine becomes unreachable, applications that call it for decryption can stop working, so the operating model matters as much as the first deployment. A useful test is whether your team can answer these questions in writing: who approves a key rotation, how the cluster recovers from a failed node, and which application breaks if the engine is unavailable. If those answers are unclear, a scoping engagement will show where internal capacity runs out.
How does transit encryption differ from database-level encryption?
Transit encryption moves the encrypt and decrypt step into the application's call path. The application sends data to OpenBao and receives ciphertext back, while the key stays on the server. Database-level encryption protects data as it is written to disk or stored in a table, and the database engine handles most of the work with little application change. With transit, key control sits with the security team, and each application or data class can have its own key with its own rotation and access policy. With database-level encryption, anyone who can run queries under an authorized database account typically sees plaintext, so access control depends on the database account model. Transit suits data that must stay protected from other application tiers and administrators. Database-level encryption suits protecting whole stores at rest. Many organizations use both, and the choice depends on the threat model and how much application change the team can absorb.
What changes in application code when we adopt transit?
Each application replaces direct handling of key material with calls to the transit encrypt and decrypt operations, usually through an HTTP client or an official client library in its language. The application sends the data, receives ciphertext that records which key version produced it, and stores that value in place of the plaintext. Changes usually include:
- Data models that can hold longer ciphertext values than the original fields
- Error handling for timeouts and temporary unavailability of the engine
- Caching or batching decisions that balance latency against load
- Search, sorting and indexing that stop working on encrypted fields unless designed for them
- Tests that cover reads of data written under older key versions
Confirm each operation and option against the version you deploy, because supported options change between releases.
What goes wrong after go-live when transit encryption is set up poorly?
Most failures come from operations and policy rather than from the cipher itself. Rotation may be scheduled, but older ciphertext is never rewrapped, so stored data stays under retired key versions that must still be readable. A minimum decryption version or deletion setting that is too aggressive can make stored data unreadable. Broad decrypt permissions granted to every service undo the value of per-application keys. A single cluster without tested high availability and backups turns one node failure into an outage for every dependent application. Teams also skip restore tests, so the first real recovery happens during an incident. Plan a rewrap process for data written under old versions, set minimum version and deletion rules deliberately, scope decrypt permissions per application, and run restore tests on a schedule. Choose the high availability backend, Raft or PostgreSQL, with these operating duties in mind.
Does DeployOpen certify that our transit encryption setup is compliant?
No. DeployOpen does not issue audit reports, attestations or certifications. It can plan and build the controls and prepare the evidence an assessment will examine, such as documented key policies, access configuration, audit logging settings, backup records and restore test results. Independent auditors or certification bodies perform the assessment and issue any report. Ask early which framework applies to the data that transit will protect, because control requirements differ by framework and by how your organization is assessed. The compliance-related work is scoped in writing with the rest of the implementation, so evidence collection and the audit calendar appear in the same plan.
How DeployOpen scopes, builds and supports transit encryption
DeployOpen plans, builds and supports OpenBao transit encryption as a service inside infrastructure you control. The work starts with a written scope that defines which applications, key types and operations are covered, then moves through build, testing, documentation and handover. Engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work begins.
How we scope
- The written scope names the applications that will call transit, the key types and operations each one needs.
- Scope records which encryption, signing and HMAC operations are in scope, and which are out of scope.
- Key rotation, convergent encryption and imported key decisions are documented before any build starts.
How we build
- Build covers transit mounts, key policies and access policies that limit each application to its own keys.
- Application integration is tested with encrypt, decrypt, sign, verify and HMAC round trips against the target environment.
- Rotation, imported key and external key procedures are exercised in a test cluster before production cutover.
How we hand over
- Deliverables include the configured engine, policy files, and runbooks for key rotation and recovery.
- Documentation maps each application to its keys, operations and policies so owners can review access.
- Your team receives a walkthrough of key lifecycle tasks and the upgrade checks for future OpenBao releases.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrade planning checks transit behavior and key compatibility before each OpenBao minor version goes live.
- Ask us to confirm which release line your environment will follow before signing the scope.
