Customer-controlled encryption reframes identity data governance

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Daon's blog post: Customer-controlled encryption for identity data is a governance question, not just a technical one, because key ownership determines who can decrypt, revoke and audit sensitive records.

Why it matters: IAM and identity governance teams need to treat key ownership as part of access control, because encryption without customer authority leaves a critical trust boundary with the provider.

Context

Encryption is often treated as a data-protection setting, but the more important question is who controls the key lifecycle. For identity data, that includes biometric templates, proofing records, recovery artefacts and authentication telemetry, all of which become governance-sensitive when the decryption boundary sits outside customer control.

Customer-controlled encryption changes the operating model for cloud and SaaS identity systems because it shifts authority over key use, revocation and audit evidence. In practice, that makes key custody part of the identity governance design, not a separate infrastructure detail.

For biometric environments in particular, the issue is not whether the data is encrypted but whether the organisation can prove who can make it readable, where that authority sits, and how quickly it can be withdrawn. That is a much stricter control expectation than conventional provider-managed encryption.

Key questions

Q: How should teams decide whether identity data needs customer-controlled encryption?

A: Use customer-controlled encryption when the identity data is high value, long lived, or exposed to administrators, support staff, cloud operators, or third parties. The key question is whether the data owner needs separate control over the keys, such as for service account inventories, tokens, certificates, or audit trails. If only the platform vendor can decrypt it, the privacy boundary is weaker.

Q: Why is biometric data treated differently from other encrypted records?

A: Biometric data is treated differently because a biometric template is tied to a person and cannot be replaced like a password or token if exposed. Even when encrypted at rest, it normally needs stricter handling of storage, access, matching, retention, and irreversible template protection than other records. That is why access to biometric data is usually tightly scoped and audited.

Q: How does customer-managed key control support zero trust for cloud identity systems?

A: Customer-managed key control supports zero trust by making decryption authority explicit, so access to identity records depends on a defined key policy rather than implicit platform trust. For cloud identity systems, this lets teams separate data access from infrastructure access, restrict who can unwrap sensitive identity material, and revoke access by changing key governance rather than only application permissions.

Q: What should security teams test before relying on external key management?

A: Security teams should test key ownership, rotation, revocation, failure recovery, and whether the service still enforces access checks when external key management is unavailable. They should also verify auditability through customer-visible logs, including who requested a key operation, when it occurred, and which identity or dataset was decrypted. Without that, external key control can create blind spots.

Technical breakdown

Provider-managed keys versus customer-controlled keys

Key ownership sits on a spectrum, and the operational difference matters more than the label. In provider-managed models, the cloud provider generates, stores, rotates and backs up the keys. In customer-managed and BYOK models, the customer retains more policy authority, but the provider may still execute key operations inside its own KMS boundary. External key management and HYOK push further by keeping key material outside the provider environment, which changes both the trust boundary and the availability dependency. See the Encryption Buyer's Guide.

Practical implication: Map every identity workload to its actual key-residency model before accepting any encryption assurance claim.

Why identity and biometric data raise the control bar

Identity data is different because it links a person to regulated services, high-value accounts and authentication flows. Biometric traits are especially sensitive because the underlying characteristic cannot be replaced the way a password or card number can. That makes key governance part of the security model for liveness checks, proofing records, recovery artefacts and biometric templates, not a side issue after encryption is enabled. See the Identity Proofing and KYC Guide.

Practical implication: Classify biometric and identity datasets separately from ordinary business data when defining encryption and key-control requirements.

How customer-controlled encryption supports zero trust

Zero trust assumes no implicit trust from network location or asset ownership, and that logic extends to decryption authority. If the enterprise cannot independently govern key use, then encryption may protect data at rest while leaving the operational control point with the vendor. Customer-controlled models narrow that trust boundary by making key use explicit, auditable and revocable, which aligns cryptographic operations with least-privilege and separation-of-duties expectations. See the Encryption Guide.

Practical implication: Tie zero-trust reviews to decryption authority, not just network segmentation or encryption status.

NHI Mgmt Group analysis

Key control, not encryption itself, is the governance primitive for identity data. Encryption only matters operationally when the organisation can define who authorises use of the key, who can revoke that authority and who can prove the action afterward. When those decisions sit with the provider, the enterprise has protection without independent control. Practitioners should treat key ownership as a first-class identity governance decision.

Biometric data makes provider dependency harder to justify. A biometric template is not a disposable secret in the way a password or token is. Once that data is tied to an identity proofing or authentication workflow, the organisation needs stronger evidence that access can be revoked, audited and geographically bounded under its own policy. That shifts the burden from encryption presence to governance quality.

Customer-controlled encryption creates a clearer accountability chain across cloud identity services. A vendor may operate the infrastructure, but the customer still owns the data risk, the regulatory exposure and the incident response burden. Independent key control gives auditors and security teams a defensible answer to who can decrypt identity data and under what conditions. That is why this model belongs in identity architecture reviews, not only procurement checklists.

Data sovereignty is increasingly a key-management issue. If key residency, key operations and logging locations are unclear, cross-border identity programmes will struggle to demonstrate meaningful control over sensitive records. The important concept here is cryptographic governance boundary: the place where policy, auditability and legal authority converge around decryption. Practitioners should define that boundary before they approve a deployment.

Zero trust is incomplete when decryption authority remains implicit. NIST SP 800-207 focuses on explicit trust decisions, and encryption should follow the same principle. If a provider can still decide when protected identity data becomes readable, the programme has not fully shifted from assumed trust to governed trust. Security teams should therefore evaluate key control as part of zero-trust maturity, not as an adjacent control.

Read next: Encryption Buyer's Guide

What this signals

Customer-controlled encryption should be treated as part of identity architecture, not as an implementation footnote. The practical question for programme owners is whether decryption authority can be revoked, audited and proven under customer policy rather than provider convention.

Cryptographic governance boundary: the control boundary is shifting from where data is stored to where decryption authority is exercised. That matters because identity programmes increasingly depend on being able to prove who can turn protected records back into readable identity data.

For teams running regulated identity and biometric workloads, the next step is to align encryption design with data classification, retention rules and incident response ownership. If those three do not match, the organisation may have encrypted data without meaningful control.

For practitioners

• Define the decryption authority boundary Document exactly who can authorise key use, who can revoke it, and which identity datasets sit inside that boundary.
• Separate biometric data from ordinary records Apply a stricter encryption and key-control model to biometric templates, proofing records and recovery artefacts than to general business data.
• Test revocation and recovery paths Verify that key suspension, rotation, backup restoration and outage recovery all work under the chosen key-residency model.
• Require customer-visible key logs Ensure key-use events, policy changes and administrative actions can be exported into your logging and monitoring stack for audit evidence.
• Review cloud identity deployments for provider dependence Check whether encryption controls are still operationally dependent on the vendor for storage, rotation, revocation or audit access.

Key takeaways

• Encryption does not automatically equal control when the provider still governs key use and revocation.
• Identity and biometric data justify a stricter key-management model because exposure has longer-lived consequences.
• The deciding factor is whether the organisation can prove decryption authority, not just that data is encrypted.

Related NHI Mgmt Group resources: Encryption Guide · Encryption Buyer's Guide · Identity Proofing and KYC Guide

Key terms

• Customer-controlled encryption: 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.
• Bring Your Own Key: Bring Your Own Key is a model where the customer supplies and controls the API credential used to access a service. In identity terms, it creates a non-human identity that must be owned, rotated, revoked, and audited like any other privileged secret.
• Hold Your Own Key: Hold Your Own Key is a custody model in which the organisation retains independent control of encryption keys outside the provider environment. Unlike arrangements where the provider can still mediate access, HYOK is used when legal exposure, incident response, or jurisdictional constraints require true external custody of the key material.
• Key Residency: Key residency is the requirement that cryptographic keys are created, stored, and used within a defined jurisdiction, system, or trust boundary. It is used to control where key material can exist and where cryptographic operations may run, limiting exposure to foreign access, legal reach, or unmanaged export of secrets.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.