A managed token vault is operated by the provider, so the vault lives in the provider’s cloud and the provider controls the storage environment. A self-hosted vault runs inside the customer’s own environment, such as private cloud, on premises, or air-gapped infrastructure. Self-hosting gives the organisation direct control over the vault, the keys, and the surrounding security boundaries.
How managed and self-hosted token vaults differ in control and operating model
The core difference is who operates the vault and where the trust boundary sits. A managed vault is run by the provider, so the provider owns the hosting environment, service availability, and much of the operational hardening. A self-hosted vault runs inside your environment, which gives you direct control but also makes you responsible for deployment, patching, access policy, segmentation, backup, and recovery.
That operating split changes more than deployment location. It changes which team owns incident response, how quickly you can enforce custom controls, whether data residency constraints are easier to meet, and how much you depend on the provider’s platform versus your own security stack.
For teams comparing products, a useful way to think about the decision is whether you want to outsource operating burden or keep the trust boundary closer to the systems that consume the tokens. That framing also affects audit evidence, because managed services usually give you provider-level assurance artifacts, while self-hosted deployments require you to produce evidence from your own environment and tooling.
What changes in security posture, resilience, and compliance
A managed vault can reduce the amount of infrastructure you must secure, but it also concentrates trust in the provider’s control plane and administrative model. If the provider misconfigures access, suffers an outage, or exposes a management plane weakness, your tokens may be affected even though the vault is “outsourced.” A self-hosted vault reduces that provider dependency, but the security quality is only as strong as your own hardening, lifecycle discipline, and monitoring.
Self-hosting is often chosen when the organisation needs tighter boundary control, private networking, or isolation from third-party operations. That can matter for regulated environments, air-gapped estates, or systems where token location and administrative access must stay within a narrowly defined security zone. Managed services are often easier to adopt, but the trade-off is less direct control over the underlying platform and its change cadence.
From a resilience perspective, managed vaults can simplify high availability and recovery planning if the provider has mature service operations. Self-hosted vaults can be resilient too, but only if the customer designs replication, backup, failover, and disaster recovery properly. In practice, many failures come from assuming that “self-hosted” automatically means “more secure” or that “managed” automatically means “less responsibility.”
When each model is the better fit
Managed vaults tend to fit teams that want faster time to value, smaller platform overhead, and a provider-operated service with standardised operations. Self-hosted vaults tend to fit teams that need custom network boundaries, strict data control, unusual deployment environments, or strong internal governance over the full token lifecycle. The right choice depends on whether operational simplicity or environmental control matters more for the system being protected.
Token pattern matters too. If the vault protects a small number of stable integrations, a managed service may be efficient and sufficient. If it protects high-value credentials, supports sensitive production workloads, or must integrate with internal controls such as bespoke approval flows, network zones, or local key management, self-hosting can be the more defensible design. For API token handling and revocation discipline, compare your operational model with API Key Management Guide and assess whether the token lifecycle can be governed as tightly in a provider service as it can inside your own boundary.
Risk and Threat Considerations
The main risk is assuming the hosting model changes the token’s sensitivity. It does not. A managed vault can still be compromised through weak access control, exposed credentials, or provider-side administrative abuse, while a self-hosted vault can fail through poor patching, excessive privilege, or weak isolation between the vault and the systems it serves.
Failure mechanism: The managed model centralises operational trust in the provider, which means provider compromise, misconfiguration, or control-plane abuse can broaden impact. The self-hosted model shifts that burden inward, where insecure deployment, weak segmentation, and poor rotation discipline can expose the vault directly.
Impact: Either failure path can lead to token theft, unauthorized access, lateral movement, or extended persistence if the vault stores long-lived credentials or lacks strong revocation and expiry controls. If your environment depends on tokens for production access, the blast radius is usually determined less by the label on the service and more by how quickly you can rotate, revoke, and isolate affected tokens.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Token vault choice directly affects who can administer and access stored secrets. |
| IA-5 — Authenticator Management | Vaults store and rotate tokens, keys, and other authenticators. | |
| Recommendation — Limit vault administration and secret access to the minimum required set of roles. Enforce secure lifecycle handling for tokens and other authenticators. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Token vaults commonly protect cryptographic material and access tokens. |
| Recommendation — Apply cryptographic protections and key handling rules to vaulted token material. | ||
| CIS Controls v8 | CIS-5 — Account Management | Vault access depends on strong account control, especially for admins and operators. |
| Recommendation — Restrict vault administration to approved accounts and review them regularly. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Vaults are access-control systems for sensitive tokens and secrets. |
| Recommendation — Use least-privilege access and strong authentication for vault operators and consumers. | ||
Practitioner Guidance
What to verify: Confirm who can administer the vault, who can read metadata, how access is logged, and whether the provider or your team is responsible for rotation, backup, and recovery. If you cannot clearly answer those ownership questions, the deployment model is not yet operationally defined.
Decision rule: If the strongest requirement is reduced platform burden, managed is usually the cleaner option. If the strongest requirement is strict boundary control, custom isolation, or keeping token handling inside your own security perimeter, self-hosted is usually the better fit.
Practitioner takeaway: Choose the model that best matches your trust boundary and operational maturity, then test it against real token lifecycle tasks, not just architecture diagrams.
Related resources from NHI Mgmt Group
- What is the difference between a self-hosted private vault and a managed vault with customer-managed keys?
- What is the difference between managed and self-hosted AI agent governance?
- What is the difference between self-hosted and managed MCP governance?
- What is the difference between a cloud password manager and a self-hosted password vault?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
