When should organisations use customer-managed keys for application data instead of provider-managed encryption?

Why This Matters for Security Teams

Choosing customer-managed keys versus provider-managed encryption is not just a procurement detail. It changes who can approve access, how quickly encryption can be revoked, and who carries the burden when auditors ask for evidence. For sensitive application data, the real question is whether the organisation needs demonstrable control over the key lifecycle, not just encryption at rest. NIST’s Cybersecurity Framework 2.0 treats governance and access control as operational disciplines, not one-time settings.

That distinction matters because encryption only reduces risk if the key management model matches the threat model. If the provider controls the keys, the provider controls a critical part of the trust boundary. If the customer controls them, the organisation gains more authority over rotation, revocation, and audit evidence, but also inherits more failure modes. NHIMG research on the Ultimate Guide to NHIs — Regulatory and Audit Perspectives shows why lifecycle control is central to modern identity governance, while the Ultimate Guide to NHIs — Key Research and Survey Results documents how often governance gaps persist in practice. In practice, many security teams discover key-control requirements only after an audit, a tenant-separation review, or a breach response has already exposed the gap.

How It Works in Practice

Customer-managed keys are most useful when the organisation needs to control the lifecycle of the key material that protects application data. That typically includes independently scheduled rotation, explicit revocation, separation of duties, and proof that only approved administrators can activate or disable the key. In cloud environments, that often means the application still relies on provider encryption services, but the root key authority sits in a customer-controlled key management system rather than being fully abstracted by the provider.

Practitioners usually evaluate three layers: data classification, operational maturity, and recovery design. High-sensitivity workloads often justify customer-managed keys when they contain regulated data, internal IP, or tenant-isolated records. For evidence, teams should map key usage to access logs, administrative approvals, and incident response procedures. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because the same lifecycle discipline that governs non-human identities also applies to keys: creation, rotation, revocation, and offboarding.

• Use customer-managed keys when legal, contractual, or internal policy requires customer-held control over decryption authority.
• Prefer provider-managed encryption when the workload is low sensitivity and operational simplicity is more important than key autonomy.
• Document who can rotate, disable, restore, and audit the key, and test each of those actions before production use.
• Design recovery around lost access, not only around successful rotation, because locked-out keys can become a business outage.

Current guidance suggests treating key ownership as part of your identity and access model, not a separate storage decision. The NIST Cybersecurity Framework 2.0 supports that operational view by tying asset governance, access control, and resilience together. These controls tend to break down when teams adopt customer-managed keys without a tested recovery path, because a lost or inaccessible key can halt the application as completely as a data loss event.

Common Variations and Edge Cases

Tighter key control often increases operational overhead, so organisations have to balance auditability and isolation against added recovery complexity and administrative risk. That trade-off becomes sharper in multi-region, multi-tenant, or highly automated environments where data flows across services faster than manual approvals can keep up.

There is no universal standard for when customer-managed keys are mandatory. Some regulators and contracts require stronger control for specific data classes, while other environments accept provider-managed encryption if the provider’s control plane and evidence are sufficient. Best practice is evolving around explicit risk-based decisions rather than blanket adoption. For example, an internal analytics workload may not justify customer-managed keys, while a financial, healthcare, or shared-tenant application often does.

Teams should also be careful not to assume that customer-managed keys automatically solve compromise risk. If application credentials, CI/CD secrets, or service accounts are weak, attackers may still reach protected data through legitimate application paths. NHIMG’s Top 10 NHI Issues highlights how often identity and secrets governance fail before encryption becomes relevant. Customer-managed keys improve control, but they do not replace access review, secret hygiene, or incident-ready revocation procedures.

Related resources from NHI Mgmt Group

• When should organisations map multiple identity provider roles into an application instead of enforcing a single role?
• What breaks when organisations use a credential store for application-layer data encryption?
• How can organisations use application-level custom fields to improve ownership and filtering in SaaS governance?
• How do organisations decide whether to use organisation-specific feature flags in a B2B application?