Which open-source option replaces AWS Secrets Manager for your workloads
For workloads spread across several clouds or running on-premises, OpenBao is the main self-hosted option for dynamic secrets and broad Vault-style workflows, and Conjur Open Source fits teams that already work with its policy model. Both let you keep secrets outside any single cloud provider's service, which matters when your applications, CI pipelines and data stores do not all sit in one account or region. Teams usually start looking for alternatives for a few recurring reasons. AWS Secrets Manager is priced per secret per month plus per 10,000 API calls, so the bill grows with the number of secrets and with how often your fleet reads them, and that cost is harder to forecast when hundreds of short-lived workloads fetch credentials constantly. Data residency rules can require that secret material stay in a particular jurisdiction or on premises. Lock-in matters too, because rotation, access policies and audit logging are tied to one provider's APIs. A self-hosted cluster gives you one access model across every environment, at the cost of running it yourself.
Before you decide, confirm three things in your own environment. First, count the secrets and the read volume your workloads generate today, and compare that with the per-secret and per-call pricing on the AWS Secrets Manager pricing page. Second, identify which applications depend on AWS-native integrations, such as Lambda-based rotation or IAM-scoped access, since those will need replacements. Third, decide who will operate the cluster, including unseal procedures, backups, upgrades and on-call coverage. If most of your workloads are on one cloud and they rely on automatic rotation, the managed service may still be the simpler choice. If you run across clouds or must keep secret material in your own facilities, a self-hosted OpenBao cluster is the option to scope in detail.
Open-source options to consider before you move off AWS Secrets Manager
Moving off AWS Secrets Manager means choosing a self-hosted secrets store and deciding who owns rotation, access and audit logging once AWS is no longer doing that work. The options below differ in license, operating model and how much rotation tooling you must still build yourself.
OpenBao as the central store
OpenBao is the option to evaluate first if you need one secrets service across AWS, other clouds and on-premises systems. It is a community fork of Vault, licensed under MPL 2.0 and managed under the Linux Foundation's OpenSSF, and it provides encrypted storage, identity-based access control, and lease management with revocation. Check whether your team can run a Raft cluster with unseal keys and backups, because that operating work replaces the managed service you are leaving.
Dynamic secrets to replace rotation Lambdas
OpenBao can issue short-lived database and Kubernetes credentials on request and revoke them when their leases end, which removes much of the work done by custom rotation functions. Applications then read credentials from the store instead of from a fixed secret that someone must rotate. The trade-off is that each application must support fetching and renewing its own credentials, so inventory which workloads can change how they read secrets before you retire the Lambdas.
Conjur Open Source for machine identity
Conjur Open Source is a good fit when policy-driven machine identity and Kubernetes or CI authentication matter more to you than dynamic database credentials. The server code is under LGPL v3.0 and the API clients and extensions are under Apache 2.0. CyberArk sells separate commercial offerings, so confirm which features your team needs are in the open-source edition and which require a paid product before you commit to it.
Secrets store plus your own rotation tooling
A simpler self-managed pattern is to run a plain encrypted secrets store and keep rotation in your own pipelines or scheduled jobs. This keeps the design familiar and avoids dynamic secret engines, but it leaves your team responsible for every rotation path, failure alert and rollback. Expect ongoing engineering time for each database, API key and certificate type you rotate, and map those before you choose this path.
Audit logging and access review
AWS Secrets Manager writes a CloudTrail GetSecretValue entry for each secret read, which many compliance teams rely on as evidence. Any self-hosted replacement needs an audit device, log shipping and retention that satisfy your own requirements, and you must test that a read of each secret type is recorded. Confirm with your assessor which logs they will accept as evidence before you cut over.
Bulk retrieval during migration
The BatchGetSecretValue API returns up to 20 secrets per call, so applications that load many secrets at startup can batch their reads today. When you move to a self-hosted store, that batching pattern has no direct equivalent, and each application will need its own loader. Measure how many secrets each service reads at startup and plan the client changes as a separate work item from the server deployment.
How AWS Secrets Manager capabilities map to OpenBao and Conjur
This table maps each AWS Secrets Manager capability this page covers to the nearest feature in OpenBao and Conjur Open Source, and marks each as direct, partial or needs custom work. Read it as a starting point for a proof of concept, since AWS-native integrations such as IAM policy evaluation and CloudTrail have no one-to-one equivalent in either platform. Confirm each feature against current OpenBao and Conjur documentation before you rely on it.
| Capability | OpenBao | Conjur Open Source |
|---|---|---|
| Secret storage and versioning | Direct: encrypted KV secrets engine with version history and metadata. Confirm version retention settings for your mount. | Partial: stores encrypted variables with versioned values. Confirm how many versions are retained and how to read older ones. |
| Retrieval by name | Direct: read by path through the API, CLI or SDKs. | Direct: read variables by policy-scoped resource ID through the REST API or clients. |
| Bulk retrieval (BatchGetSecretValue style) | Needs custom work: no single batch call equivalent to the 20-secret limit in AWS. Plan for parallel reads or a sidecar that fetches many paths. | Needs custom work: confirm whether a batch read exists in your client version. Otherwise build a loop with caching. |
| Automatic rotation | Partial: dynamic secrets issue short-lived credentials with leases, which replaces many Lambda rotation jobs. Static secret rotation needs your own scheduler or pipeline. | Partial: rotators exist for some targets. Confirm supported targets and whether custom rotators are needed. |
| Dynamic database credentials | Direct: database secrets engine generates per-request credentials with lease-based revocation. Confirm the plugins you need are shipped by OpenBao. | Partial: dynamic credential support depends on the integration. Confirm target coverage before migration. |
| IAM-based access control | Partial: identity-based policies and auth methods such as AppRole, Kubernetes and JWT/OIDC. No direct IAM policy evaluation, so map roles to OpenBao policies. | Partial: host, group and Kubernetes identities with resource policies written in Conjur policy language. Rewrite AWS IAM conditions by hand. |
| Audit logging (CloudTrail equivalent) | Partial: file, syslog and socket audit devices record requests. Ship logs to your SIEM. Entries are not CloudTrail events. | Partial: audit records are emitted per resource access. Confirm format and forwarding options for your SIEM. |
| Cross-region replication | Needs custom work: performance and disaster recovery replication depend on the OpenBao edition and storage backend. Confirm before design. | Needs custom work: plan replicated databases and multi-site deployments yourself. |
| KMS integration for encryption keys | Partial: auto-unseal through cloud KMS providers is possible. Confirm supported providers and seal configuration for your cloud. | Partial: encryption keys are managed by the server. Confirm key handling and how it aligns with your KMS policy. |
How a self-hosted OpenBao cluster replaces the AWS retrieval path
The replacement for AWS Secrets Manager is a high-availability OpenBao cluster that runs inside your own infrastructure, reachable from AWS, other clouds and on-premises networks through a single identity-based access model. Workloads authenticate to OpenBao with the identity they already have, such as an instance or workload identity on AWS, a Kubernetes service account, or a certificate or OIDC identity elsewhere, and receive a short-lived token scoped to the paths they need. Applications then read secrets through the OpenBao API or a sidecar or agent pattern, instead of calling a regional AWS endpoint. The cluster placement, storage backend, unseal method and network paths are decisions that depend on your environment, so confirm them with your platform, network and security teams before you size anything.
Where AWS Secrets Manager offers BatchGetSecretValue, which returns up to 20 secrets per call and logs a CloudTrail GetSecretValue entry for each secret, OpenBao has no equivalent managed log. Your team must build the audit trail. Enable OpenBao's audit devices, ship those logs to a central store that is append-only and separate from the cluster's administrators, and alert on reads of high-value paths. Decide which identity events, token creation, policy changes, unseal operations and failed authentications you need to retain, and confirm the retention period with your compliance owner. Access logging at the load balancer or network layer should be kept as well, so that a read can be traced from the network request through to the secret path.
For Kubernetes, the OpenBao Helm chart is the recommended installation method and requires Helm 3.6 or later, so check your cluster's Helm version before planning the rollout. The chart covers the server deployment, but it does not replace your decisions on high availability, backup of the storage backend, certificate management, upgrades and disaster recovery. Ask the platform team to document who holds unseal material, how the cluster is restored from backup, and which teams can change policies. Those answers, and the scale of the cluster, determine the effort for the migration and the ongoing operation.
What AWS Secrets Manager costs compared with running OpenBao yourself
This table sets AWS Secrets Manager's metered fees against the components you pay for when you run OpenBao yourself. Read the AWS rows as recurring charges that scale with secret count and API calls, and the self-hosted rows as a mix of one-time setup and ongoing operating effort. Use your own secret count, call volume and environment count to model both sides before requesting quotes.
| Cost component | Who is paid or who pays | One-time or recurring | What drives it |
|---|---|---|---|
| Per-secret fee (AWS Secrets Manager) | AWS, billed per secret per month | Recurring | Number of secrets, including copies kept in each Region or account you use |
| API call fee (AWS Secrets Manager) | AWS, billed per 10,000 API calls | Recurring | Call volume from workloads, batch jobs and retries, and how often clients refetch secrets |
| Compute and storage for the OpenBao cluster | Your cloud provider or data center, or your hardware budget | Recurring | Number of nodes for high availability, storage growth from leases and audit logs, and environment count |
| Load balancing and network access | Your cloud provider or network team | Recurring | Number of clusters, whether clients reach OpenBao across clouds or on-premises, and TLS termination design |
| Backups and recovery testing | Your team or DeployOpen under a fixed-scope engagement | One-time setup, then recurring | Backup frequency, retention period, and how often you rehearse restores and unseal key recovery |
| Licensing | None for MPL 2.0 software (confirm current terms with the project) | Not applicable | Your use of OpenBao; a commercial support contract is a separate, optional cost |
| Implementation and integration | DeployOpen or your platform team, under a written scope | One-time | Number of workloads moved from Secrets Manager, Kubernetes and CI integrations, and auth methods to configure |
| Migration and rewiring of rotation Lambdas | Your application and platform engineers | One-time | Count of rotation functions to replace with dynamic secrets, and how many applications read secrets through SDKs |
| Internal operations, upgrades and on-call | Your platform or security team | Recurring | Upgrade cadence, seal and unseal procedures, monitoring coverage, and out-of-hours response requirements |
What you give up when you leave AWS Secrets Manager
Moving from AWS Secrets Manager to a self-hosted OpenBao cluster trades a managed service for components your team operates. The cards below cover the capabilities that AWS handles for you today, the workaround for each, and the operating effort the workaround adds.
Native AWS integration and IAM
Today, IAM policies, resource policies and service integrations such as Lambda, ECS and EKS secret injection work without extra code. With OpenBao, access is governed by its own identity-based policies and auth methods, so you must map IAM roles to OpenBao roles, for example through the AWS auth method, and rebuild each application's retrieval path. Check how many services read secrets directly from AWS today, because each one needs a new client configuration and a test before cutover.
Managed availability and patching
AWS operates the Secrets Manager control plane, its storage durability and its regional failover. A self-hosted cluster means you design the HA topology, run the storage backend, apply security releases and test restores. Plan a runbook for each OpenBao release, such as the security fixes in v2.7.1, and rehearse a node failure and an unseal procedure before production use.
Automatic rotation through Lambda templates
Secrets Manager ships Lambda rotation templates for AWS-managed databases. The usual replacement is dynamic secrets, where OpenBao creates short-lived database credentials on request and revokes them when the lease ends, so no stored password needs rotating. This requires a database secrets engine configuration for each engine, lease TTLs that match your application restart behavior, and changes to connection pools that cache credentials. Expect the largest effort here if you have many custom rotation functions.
CloudTrail as the built-in audit trail
Each GetSecretValue call is logged in CloudTrail without extra configuration, which many auditors accept as evidence of access. With OpenBao, you enable an audit device and ship its logs to your SIEM, then define retention, tamper protection and alerting yourself. Confirm which events your assessor expects, such as read, write and policy changes, and test that a missing log stream is detected.
Managed key handling
AWS KMS protects the data keys behind Secrets Manager, and key policies, rotation and access logging are managed for you. In a self-hosted deployment, you choose the unseal method, store unseal keys or connect an external key service, and manage the storage encryption keys. Decide who holds unseal material, document the split-custody procedure and test recovery, because a lost unseal capability makes every secret unreadable.
How to move secrets off AWS Secrets Manager without downtime
The sequence keeps AWS Secrets Manager serving live consumers while OpenBao takes over one workload at a time, so each cutover can be checked and reversed before AWS access is removed. Effort scales with how many secrets, consumers and rotation Lambdas the inventory turns up.
Inventory secrets, consumers and rotation Lambdas
The platform team lists every secret in each account and region, the application or pipeline that reads each one, the access policies and resource tags attached to it, and any rotation Lambda that changes its value. Each secret is marked with an owner, a rotation schedule and a classification. The output is a spreadsheet or config file where every secret has at least one named consumer and a decision on whether it moves, is retired or stays in AWS for now. Confirm with each team that the list is complete, because consumers that read secrets from environment variables at build time are easy to miss.
Export secret values under controlled access
A dedicated, least-privilege IAM role is created for the export, limited to the secrets in scope and to the export window. The security team approves it in writing. The export script calls BatchGetSecretValue with up to 20 secrets per request where the selection fits, and writes values only to an encrypted staging location that is deleted after import. Every call creates a CloudTrail GetSecretValue entry for each secret, so the export is auditable. The check is a reconciliation report that matches the count and a hash of each exported value against the inventory, with any failed or throttled batch retried and recorded.
Map each secret to an OpenBao engine or dynamic role
Each inventory entry is assigned a target in OpenBao. Static application credentials usually go to a KV version 2 secrets engine with one path per application and environment. Database credentials that rotation Lambdas currently change are candidates for a database secrets engine, where OpenBao issues short-lived credentials on request and revokes them through leases. Kubernetes service accounts and CI jobs get identity-based policies instead of shared keys. The mapping document records the path, policy, lease behavior and the owner who signs off. Confirm each database plugin and rotation requirement against the current OpenBao documentation before writing the role.
Pilot with one non-production workload
One low-risk workload in a non-production environment is switched to read from OpenBao, using its own secret path and policy. The team changes the client library or sidecar configuration, deploys the change, and runs the application's normal test suite. They also confirm that rotation works by forcing a credential change and checking that the application recovers without a restart. The pilot is complete when the workload has run through its full test cycle, its logs show successful reads from OpenBao, and the team has written down every configuration change needed so the next workloads follow the same pattern.
Run both systems in parallel
Each migrated secret is written to OpenBao while the original value stays in AWS Secrets Manager, so consumers can still read from either system. Values are kept in sync during this period through the export process or a controlled write path, and any change made in one system is recorded and copied to the other. Monitoring tracks read errors and latency on both sides. Rollback means pointing a consumer back to its AWS secret ARN, which is why the old value is not deleted yet. This stage ends when every in-scope consumer has run successfully against OpenBao for a period the owners agree on in advance.
Cut over consumers one group at a time
Consumers are switched in small groups ordered by risk, starting with the least critical. Each group gets a change request, a rollback step and a named owner who watches the application after the change. The platform team confirms through OpenBao audit logs that reads come from the expected identities, and that no consumer is still calling AWS for a migrated secret. Rotation Lambdas are disabled only after their dependent consumers have moved and the dynamic role has been tested. The group is closed when audit logs show no AWS reads for its secrets over the agreed observation window.
Revoke AWS access and decommission
Once every consumer reads from OpenBao, the export role and application roles that could still read AWS secrets are removed, and resource policies on the secrets are tightened to deny access. Rotation Lambdas are deleted. Secrets are scheduled for deletion according to the AWS recovery window, and the deletion is recorded with a reference to the approval. The team keeps the inventory, change records and audit logs as evidence. The step is complete when a fresh inventory query shows no active consumers and CloudTrail confirms no GetSecretValue calls for the retired secrets.
Which replacement fits your situation
Teams running workloads across two or more cloud providers often find that a single AWS-native secrets store leaves applications in other clouds calling a different API or cross-account path for every secret. In an illustrative scenario, an application team runs services on AWS and on another cloud provider and wants one secrets API with one policy model. OpenBao fits this need because it runs in any environment that can reach it, and it exposes one interface regardless of where the workload sits.
- Best-fit option: A self-hosted OpenBao cluster reachable from every cloud network, with auth methods configured per provider.
- Confirm first: Which identity each cloud workload presents, and whether network paths to the cluster meet your latency and failover needs.
- Main risk: Your team becomes the operator of a stateful cluster in every region, so availability and upgrades are now your responsibility.
- Export path: Batch reads from AWS Secrets Manager use BatchGetSecretValue, which returns up to 20 secrets per call, so plan a migration batch size around that limit.
- Audit trail: AWS logs a CloudTrail GetSecretValue entry per secret, so confirm equivalent audit logging in OpenBao before cutting over.
Before committing, confirm which clouds and regions the cluster must serve and who will be on call for it.
Organizations with data residency obligations or disconnected networks often cannot send secret material to a managed cloud service at all. In an illustrative scenario, a public sector team must keep credentials inside a national data center and operate without outbound internet access. A self-hosted OpenBao deployment keeps encrypted storage, unseal material and access decisions inside that boundary.
- Best-fit option: OpenBao on hardware or virtual machines inside the approved facility, with storage and unseal procedures documented for that site.
- Confirm first: Where the unseal keys and recovery material will be held, and who may access them under your residency rules.
- Main risk: A cluster that is not tested for recovery can leave applications without credentials during an outage.
- Upgrade path: The OpenBao migration guide documents a node-by-node in-place upgrade from Vault Community 1.14.1 on Raft storage with Shamir unseal, but it was tested only against that version, so confirm your exact starting point first.
- Plugin check: Mounts that use plugins OpenBao does not ship are skipped during migration, so inventory every engine in use.
Confirm your residency requirements in writing with your legal and compliance owners before selecting a storage design.
Teams that rotate AWS Secrets Manager credentials with custom Lambda functions often maintain rotation code for each database and each credential type. In an illustrative scenario, a platform team has several rotation functions that run on a schedule and break when a database engine changes. OpenBao dynamic secrets shift the approach: the secrets engine issues short-lived database credentials on request and revokes them when the lease ends, so no rotation function is needed for those systems.
- Best-fit option: OpenBao dynamic secrets for databases and Kubernetes, with leases and revocation handling expiry.
- Confirm first: Which systems can accept dynamically issued credentials, since some legacy applications expect a fixed username and password.
- Main risk: Applications that cache credentials or do not reconnect on lease renewal may fail when a lease expires.
- Lease discipline: Test renewal and revocation in a non-production environment before removing any Lambda function.
- Retained rotation: Static secrets that cannot be issued dynamically still need a rotation process, so keep those functions until a replacement is verified.
List every rotation Lambda and classify each secret as dynamic-capable or static before you plan decommissioning.
Regulated teams usually need to show who could read which secret, when access was granted and when it was revoked. In an illustrative scenario, a financial services team must produce access evidence for an assessor during a control review. The evidence depends on how identity, policy and audit logging are configured, and an open-source platform does not supply that evidence on its own.
- Best-fit option: OpenBao with identity-based access policies, documented role ownership and audit devices forwarded to your log platform.
- Confirm first: Which control framework the assessor uses, and which control identifiers map to secret access and rotation.
- Main risk: Policies drift when teams create ad hoc roles, and the platform will not flag that drift without review.
- Evidence set: Keep policy exports, auth configuration, audit log samples and revocation records together.
- Independent review: DeployOpen prepares systems and evidence for assessments, but independent auditors issue any audit report or certification.
Ask your assessor which evidence format they accept before you design the logging and retention setup.
How much effort and cost does moving off AWS Secrets Manager involve?
What drives the cost of running a self-hosted OpenBao cluster?
The main cost is the people and infrastructure to run it, not a license fee, because OpenBao is MPL 2.0 licensed. AWS Secrets Manager bills per secret per month plus per 10,000 API calls, so its cost grows with secret count and call volume. A self-hosted cluster instead costs compute and storage for the nodes, load balancing, backups, monitoring, and staff time for upgrades, unseal procedures, access policy and on-call. Ask a quote to separate one-time build work from recurring run costs, and to show how the estimate changes if secret count or call volume doubles.
How long does a migration off AWS Secrets Manager usually take?
The duration depends mainly on how many secrets exist, how many workloads read them, and how many use rotation Lambdas that must be replaced with dynamic secrets. Each consumer needs its access path changed and tested, and each rotation function needs a designed replacement. We cannot state a duration from the supplied information, so confirm it against your own inventory. Ask for a timeline tied to a written scope with phases for inventory, cluster build, pilot workloads, cutover and decommissioning of the AWS side.
Can an in-house team run this migration without outside help?
Often yes, if the team already operates Kubernetes or similar infrastructure, has experience with secrets platforms, and can staff an on-call rotation for a stateful service that holds credentials. The hard parts are high availability, unseal key handling, audit log retention, access policy design and rehearsed recovery. Assess those skills honestly before committing. A fixed-scope engagement can cover some of this work while your team keeps ownership of operations.
What skills does the team need to operate OpenBao well?
Plan for skills in Kubernetes or VM administration, TLS and certificate management, identity integration, and infrastructure as code. The OpenBao Helm chart is the recommended Kubernetes install method and requires Helm 3.6 or later, so someone must maintain that toolchain. You also need audit and logging skills to send audit records to your SIEM, and a documented on-call process for seal states and node failures. Confirm each skill against your current staff before planning the work.
Does BatchGetSecretValue export every secret I need to move?
No, not on its own. The BatchGetSecretValue API returns the SecretString or SecretBinary of up to 20 secrets per call, selected by name, ARN or filter, so a script can read in batches. It does not export resource policies, rotation configuration, tags or version history in a form that maps directly to OpenBao. Each export also creates a CloudTrail GetSecretValue entry per secret, which you should record as part of the cutover plan. Confirm which metadata you need to preserve and how it will be recreated.
Can DeployOpen help with a fixed-scope migration?
Yes. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope.
What should I request in a quote for this migration?
Ask for a written scope listing the secret inventory method, the number of consumers in each phase, the rotation Lambdas to be replaced, and the target architecture including high availability and backup. Request separate line items for one-time build and migration work, recurring support, and infrastructure you will pay for directly. Ask which assumptions drive the figure, what changes if secret count grows, and what is excluded, such as application code changes or AWS decommissioning.
Which official sources to check before you decide
Before you commit to a self-hosted OpenBao cluster in place of AWS Secrets Manager, confirm the current version and feature status on the official OpenBao site and releases page. Open-source secrets projects change quickly, and a feature you need for multi-cloud rotation or dynamic secrets may be documented for one release line and absent from another. Read the OpenBao releases page for the version you plan to run, then compare its release notes against the capabilities you rely on today, such as the BatchGetSecretValue-style bulk retrieval your applications call and the dynamic secret engines that would replace your rotation Lambdas. Record the exact version in your design document so that every later check is tied to one build.
Next, work through the OpenBao migration guide if you already run Vault, and check its stated scope against your own cluster. The guide describes an in-place upgrade from a specific Vault Community version on Raft storage with Shamir unseal, and it was tested only against that version. Confirm whether your storage backend, unseal method, auth methods and secret engines fall inside that scope, and note which mounts use plugins OpenBao does not ship, because those are skipped. If you are starting fresh instead, use the same guide to understand the token format differences your application teams must handle.
For Kubernetes deployments, check the OpenBao Helm chart documentation against your cluster's Helm version, since the chart requires Helm 3.6 or later. Then verify the AWS side directly: the AWS Secrets Manager pricing page sets the per-secret and per-10,000-API-call charges you are comparing against, and the BatchGetSecretValue API reference defines the 20-secret limit per call and the CloudTrail logging behavior you may need to replace. Finally, review the Conjur repository only if it is a candidate for your workloads, and confirm its license terms for your use case in that repository before you rely on them.
How DeployOpen scopes, migrates, hands over and supports the replacement
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a move off AWS Secrets Manager, that means working through the secret inventory, the OpenBao cluster, the application retrieval paths and the rotation replacements as one written scope.
How we scope
- Inventory every secret, its consumers, its rotation method and the AWS accounts and Regions that hold it.
- Document which workloads call GetSecretValue or BatchGetSecretValue and which run in AWS, other clouds or on-premises.
- Agree in writing which Lambda rotation functions become OpenBao dynamic secrets and which stay as static secrets.
How we build
- Deploy the OpenBao cluster in the client's environment, using the Helm chart where workloads run on Kubernetes.
- Configure identity-based access policies, auth methods for each workload type, and lease settings for dynamic credentials.
- Test retrieval, failover, unseal procedures and revocation against a non-production copy before any cutover.
How we hand over
- Deliver the architecture, policy files, runbooks for unseal, backup and restore, and a secret-by-secret migration record.
- Provide evidence for access control, audit logging and key handling that the client's own auditors can review.
- Run a knowledge transfer session with the platform and security teams, covering the rollback steps that remain available until AWS access is retired.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, OpenBao upgrades and continuous security testing are available as a retainer.
- Confirm with your own environment and the vendor which OpenBao release and upgrade cadence fits your change process before signing.
