Customer-Managed Encryption is a model where an organisation controls the encryption keys used to protect its data. The customer creates, stores, rotates, and revokes the keys, while the cloud or application provider encrypts and decrypts data only under that customer-controlled authority, reducing provider access to sensitive content.
What Customer-Managed Encryption Means
Customer-managed encryption is not just “using encryption,” it is a custody model. The organisation owns the decision rights for the keys, which changes who can grant, revoke, or recover access to protected data and who must be trusted with decryption capability.
This distinction matters because provider-managed encryption can still leave the provider or its support processes with some level of operational control, while customer-managed keys reduce that default trust. The security question shifts from “is the data encrypted?” to “who controls the authority that makes decryption possible?”
How Customer-Controlled Key Custody Changes the Security Model
With customer-managed encryption, key ownership becomes part of the protection boundary. That means the organisation must treat key generation, storage, rotation, backup, and revocation as security functions, not just administrative tasks. A compromise of the keys can be equivalent to a compromise of the data itself.
The model is often used to reduce provider visibility into sensitive content and to support stricter internal governance. It is especially relevant where the provider should not be able to independently read customer data, even if the provider operates the encryption service or storage platform.
Because key control is central, the design must account for escrow, recovery, separation of duties, and the operational consequences of key loss. If the organisation cannot recover the keys, it may also lose access to the data.
Typical Deployment Patterns and Trust Boundaries
Customer-managed encryption appears in several patterns, including customer-held cloud keys, external key management systems, and envelope encryption where data keys are protected by a customer-controlled master key. The exact implementation varies, but the same principle holds: the customer remains the authority over the keys that protect the data.
That trust boundary is often what distinguishes customer-managed encryption from standard provider encryption settings. In a well-designed model, the provider can process encrypted data only within the constraints the customer has defined, and key access can be narrowed by policy, location, or approval workflow.
The model is strongest when the organisation can independently audit key usage and key policy, rather than relying entirely on the provider’s default administrative plane. That makes the underlying key management system part of the security architecture, not an afterthought.
Why Key Governance Matters for Encryption Ownership
The security value of customer-managed encryption depends on the organisation’s ability to govern the keys consistently over time. If key rotation, revocation, backup, and access review are weak, the model can create a false sense of control while leaving sensitive data exposed through stale or over-shared keys.
It also creates a dependency on key lifecycle discipline. A lost, misconfigured, or improperly revoked key can produce availability failures, while an overly permissive key policy can undermine the intended confidentiality gains. For that reason, customer-managed encryption is as much about governance as it is about cryptography.
When this model is used for regulated or highly sensitive data, the organisation should also verify how the provider handles logs, administrative overrides, disaster recovery, and support access, because those operational details can affect the real strength of customer control.
Risk and Threat Considerations
Customer-managed encryption reduces provider access, but it also concentrates risk in the organisation’s own key management practices. If keys are stolen, mishandled, or left exposed in poor operational workflows, the resulting compromise can defeat the protection the model is meant to provide.
Failure mechanism: Attackers or insiders target the key store, management plane, backup copies, or administrative workflow, then use valid keys or policy gaps to decrypt data, impersonate legitimate access, or prevent recovery through revocation or destruction.
Impact: The organisation can lose confidentiality, integrity, and sometimes availability of the protected data, especially if key custody, rotation, or recovery processes are weak or if compromise is not detected quickly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | NIST SP 800-57 Part 1 — Key Management | Defines key lifecycle practices central to customer-controlled encryption custody. |
| Recommendation — Apply key lifecycle governance for generation, rotation, recovery, and revocation under customer control. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Customer-managed encryption relies on disciplined credential and secret handling for key-access systems. |
| SC-12 — Cryptographic Key Establishment and Management | Directly addresses control of cryptographic keys used to protect customer data. | |
| Recommendation — Manage encryption-related authenticators and secrets with strict lifecycle controls and limited distribution. Implement customer-controlled key establishment and management for protected data stores. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Key custody depends on tightly governed administrative access to encryption controls. |
| A.8.24 — Use of cryptography | Customer-managed encryption is a cryptographic protection model governed by organisational policy. | |
| Recommendation — Restrict who can administer and use encryption keys through defined access control policy. Define and operate cryptographic use so key ownership and handling remain under customer authority. | ||
Practitioner Guidance
Why practitioners should care: Customer-managed encryption only delivers meaningful control when the organisation can actually administer the keys with discipline. The operational question is not whether encryption exists, but whether the key lifecycle, access model, and recovery process are trustworthy under stress.
Common misunderstanding: Teams sometimes assume that choosing a customer-managed option automatically prevents all provider access. In practice, the security outcome depends on the exact key architecture, the surrounding administrative controls, and whether the provider still has any operational path that can influence encryption behavior.
Practitioner takeaway: Treat the key management process as a first-class security control, because in this model the key policy is the control plane that determines whether encryption truly protects the data.
Related resources from NHI Mgmt Group
- When should organisations use customer-managed keys for application data instead of provider-managed encryption?
- What is the difference between login with SSO and SSO with customer managed encryption?
- What is the difference between customer-managed encryption keys and provider-managed encryption keys in SaaS PKI environments?
- What is the difference between provider-managed encryption and customer-managed encryption for cloud data streams?