What is the difference between a self-hosted private vault and a managed vault with customer-managed keys?

A self-hosted private vault gives the organisation direct control over the entire stack, including operations and audit readiness. A managed vault with customer-managed keys keeps key ownership with the customer while shifting infrastructure operation, monitoring, and independent assurance to the provider. The practical trade-off is less self-sovereignty in exchange for stronger continuous oversight.

Why This Matters for Security Teams

The difference is not just where the vault lives. It is who operates it, who can prove it is configured correctly, and how much trust is placed in a provider versus internal controls. A self-hosted private vault concentrates responsibility in the organisation, while a managed vault with customer-managed keys splits control across customer governance and provider operations. That distinction matters when auditors ask who can rotate keys, inspect logs, and recover access after an incident.

For teams already struggling with secret sprawl, the vault model can either reduce risk or hide it behind a false sense of centralisation. NHIMG’s Guide to the Secret Sprawl Challenge notes that duplication and scattered storage are persistent failure points, and the 2025 State of NHIs and Secrets in Cybersecurity reports that 50% of organisations are onboarding new vaults without proper security approval. Current guidance from the NIST Cybersecurity Framework 2.0 still points teams toward governance, recovery, and continuous monitoring rather than assuming the vault choice alone creates security.

In practice, many security teams discover vault design weaknesses only after a leaked token, failed rotation, or audit exception has already forced a response.

How It Works in Practice

A self-hosted private vault gives the organisation direct control over the full control plane: deployment, hardening, logging, patching, backup, and break-glass access. That can be attractive where data residency, latency, or regulatory interpretation demands internal operation. But it also means the organisation owns every operational failure mode, including misconfigured access policies, stale certificates, and delayed patch cycles. By contrast, a managed vault with customer-managed keys usually keeps the cryptographic root of trust under customer control while the provider runs the service layer, availability, and much of the detection and assurance work.

The practical difference is best understood as a split between key ownership and service operation. In a managed model, the customer still decides when keys are created, rotated, disabled, or revoked, but the provider may handle metadata services, replication, incident telemetry, and platform hardening. That can reduce operational burden, especially when paired with well-defined lifecycle controls from NHIMG’s NHI Lifecycle Management Guide and the Ultimate Guide to NHIs. However, customer-managed keys do not eliminate provider dependency; they mainly reduce the blast radius if the provider is compromised.

• Use self-hosted vaults when internal control, bespoke audit evidence, or strict isolation is the overriding requirement.
• Use managed vaults with customer-managed keys when faster recovery, external assurance, and lower operational overhead matter more.
• Require clear responsibility for rotation, recovery, logging, and emergency access before production use.

NIST SP 800-53 Rev. 5 reinforces the need for control over key management, auditability, and incident response, but it does not prescribe one vault model over another. These controls tend to break down when legacy applications hardcode secrets or when multiple teams share one vault without clear ownership.

Common Variations and Edge Cases

Tighter control over a self-hosted vault often increases operational cost, staffing needs, and recovery complexity, so organisations have to balance sovereignty against resilience. That trade-off becomes sharper when compliance teams want evidence faster than platform teams can produce it. Best practice is evolving, but there is no universal standard for whether customer-managed keys alone are sufficient for regulated workloads; the answer depends on data sensitivity, threat model, and evidence requirements.

One edge case is the “managed but not really controlled” deployment, where the customer owns the keys but cannot independently validate provider-side access paths, logging, or backup procedures. Another is the over-rotated vault, where frequent key changes create service outages because applications are not designed for short-lived secrets. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Static vs Dynamic Secrets both reinforce that weak lifecycle discipline often matters more than the brand of vault. For teams aligning to policy, NIST CSF 2.0 and control families in the framework set should be read as operating requirements, not product endorsements.

Managed vaults with customer-managed keys are often the better fit for hybrid and multi-cloud estates, but they can be a poor fit when an organisation needs complete provider independence or cannot tolerate third-party service dependencies.

Related resources from NHI Mgmt Group

• 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?
• What is the difference between short-lived credentials and permanent API keys for NHI security?