Customer-controlled encryption means the organisation, not the provider, controls the encryption keys used to protect its data. In regulated identity environments, this reduces provider-side exposure and helps preserve control when the platform is hosted outside the customer’s direct infrastructure.
Expanded Definition
Customer-controlled encryption is a key custody model in which the customer retains governance over the keys that encrypt data, rather than leaving that authority entirely with the platform provider. In NHI and cloud identity environments, the term usually refers to operational control over key generation, storage, rotation, revocation, and access policy, even when the underlying service is hosted externally.
Definitions vary across vendors, especially where “control” may mean customer-managed keys, customer-held keys, or external key management. NHI Management Group treats the distinction as material: if a provider can decrypt data without customer involvement, the control is weaker than the label suggests. This is closely related to zero trust and data sovereignty expectations described in the NIST Cybersecurity Framework 2.0, but no single standard governs the phrase itself yet. The most common misapplication is treating provider-administered key policies as customer-controlled encryption when the provider still has unilateral decryption capability.
Examples and Use Cases
Implementing customer-controlled encryption rigorously often introduces key lifecycle and availability constraints, requiring organisations to weigh stronger control against recovery complexity and operational overhead.
- A regulated SaaS tenant uses external key management so security teams can rotate and revoke keys without waiting for provider support.
- A secrets platform protects API keys with customer-held keys, reducing exposure if the platform operator is compromised. NHI Management Group notes that 79% of organisations have experienced secrets leaks, with 77% causing tangible damage, in the Ultimate Guide to NHIs — Standards.
- An identity pipeline encrypts service-account records before they are stored in a managed database, limiting provider-side plaintext access.
- A federated workload uses an external KMS boundary to separate application operations from decryption authority, aligning with least-privilege design.
Practitioners often compare this model with the control expectations in NIST Cybersecurity Framework 2.0, but the implementation pattern depends on whether the customer can independently suspend, rotate, and audit the keys.
Why It Matters in NHI Security
Customer-controlled encryption matters because many NHI incidents become worse when the platform operator can read protected data, recover secrets, or bypass customer approval during an investigation. For service accounts, API keys, and automation tokens, key custody is not just a data protection issue, it is an access-governance issue. If the same provider that hosts the workload also controls the decrypt path, compromise of the platform may expose secrets at scale.
This is especially relevant given NHI Management Group research showing that 96% of organisations store secrets outside of secrets managers in vulnerable locations, and 97% of NHIs carry excessive privileges in the Ultimate Guide to NHIs — Standards. Customer-controlled encryption does not solve poor rotation or overprivilege, but it limits the blast radius when those failures occur. It also supports governance expectations in the NIST Cybersecurity Framework 2.0 by strengthening recoverability, protection, and access accountability. Organisations typically encounter the need for this control only after a provider-side incident, at which point customer-controlled encryption becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Key custody and access boundaries support identity and access protection goals. |
| NIST Zero Trust (SP 800-207) | Zero trust assumes no implicit trust in provider-side decrypt access. | |
| OWASP Non-Human Identity Top 10 | NHI-02 | Encryption protects secrets tied to NHIs from provider-side exposure. |
Ensure only approved customer roles can approve, rotate, and revoke decryption keys.
Related resources from NHI Mgmt Group
- What is the difference between encryption and access control in AWS data protection?
- What is the difference between strong customer authentication and ordinary MFA?
- What is the difference between symmetric and asymmetric encryption for IAM use cases?
- How should organisations reduce identity friction in customer-facing services?
