Customer-Controlled Encryption: Why Key Ownership Matters for Identity Data
Ralph Rodriguez
President & Chief Product Officer
Ralph A. Rodriguez is President, Chief Product Officer (CPO), and a member of the Board of Directors for Daon. He is accountable for defining the go-to-market vision, strategy, and roadmaps for Daon’s products and technology.
Ralph was most recently an Executive-in-Residence at Summit Partners, a Boston-based private equity firm. Previously he was a Research Scientist and Head of Identity Verification at Facebook, where he oversaw Applied Identity Intelligence. Ralph was also the co-founder and chief technology officer of Confirm.io, an identity verification and authentication company acquired by Facebook in March 2018. Ralph founded Blue Hill Research, Delfigo Security, Invenio, and NTA before Confirm.io. In addition, he was the CTO/CIO of public companies Brooks Automation (NASDAQ: BRKS), C-bridge Internet Solutions (NASDAQ: CBIS), and Excelon Corporation (NASDAQ: EXLN).
As the longest-serving Fellow at the Massachusetts Institute of Technology (MIT), Ralph pioneered research on artificial intelligence (AI), cloud, mobile, neural science, and security technologies at the MIT Media Lab and Harvard-MIT Health Sciences and Technology (HST) departments.
Ralph studied for an Sc.D. in information systems and is a graduate of the management program GPMD-MBA at IESE Business School, Barcelona, Spain. He served in the United States Army during the Persian Gulf War in 1990 and was named Soldier of the Year by the 10th Mountain Division (Light Infantry) in 1987. Ralph holds a portfolio of 68 patents globally, including 37 issued U.S. patents, 2 additional U.S. patents pending, 4 international patents issued, and 27 other international applications pending. His innovations span identity verification, biometrics, deepfake detection, agentic-AI, and quantum-enhanced fraud prevention.
June 11, 2026
Encryption protects data only as well as the keys that govern access to it. In cloud and SaaS environments, enterprises need to understand whether encryption keys are provider-managed, customer-managed, imported through BYOK, or held externally under independent customer control. For identity and biometric data, that distinction affects data sovereignty, auditability, incident response, zero-trust alignment, and vendor risk. Customer-controlled encryption is not simply a technical feature. It is a governance model that gives enterprises stronger authority over who can decrypt sensitive data, when access can be revoked, and how control can be demonstrated to auditors, regulators, and enterprise customers.
Encryption Is Not the Same as Control
Encrypting your data and controlling your data are not the same thing. That distinction becomes critical when the data is identity data: biometric templates, identity documents, proofing records, authentication events, recovery artifacts, device signals, and risk intelligence.
A system can encrypt every byte and still leave the real control point somewhere else, because true data ownership turns on who can authorize use of the key, who can revoke that authorization, who can see the key-use audit trail, in which region that control sits, and whose policies govern the cryptographic root of trust.
Under the default cloud model, a cloud service provider often generates, stores, uses, rotates, and backs up encryption keys on behalf of the customer. That model can be operationally convenient and appropriate for lower-risk workloads. It is not automatically wrong, but it is provider-dependent. The customer benefits from encryption while the control plane (key use, enforcement, logging, and revocation) remains largely outside the customer’s independent authority.
The two are not interchangeable: encryption protects data from unauthorized disclosure, while key control determines who has the practical authority to make encrypted data readable.
The Key-Control Spectrum: PMK, CMK, BYOK, and HYOK
The industry often uses terms such as BYOK, customer-managed keys, customer-controlled keys, and hold-your-own-key as if they are interchangeable. They are not. Customer-controlled encryption exists on a spectrum, and the differences matter for risk, compliance, auditability, and procurement. The Cloud Security Alliance describes provider-managed keys, customer-managed keys, BYOK, HYOK, and hybrid models as distinct responsibility models.
| Model | What it means | Control implication |
|---|---|---|
| Provider-managed keys (PMK) | The provider generates, stores, uses, rotates, and backs up the keys. The customer typically configures encryption but does not manage key material or key operations directly. | Low customer operational burden; lower independent control. |
| Customer-managed keys (CMK / CMEK) | The customer manages policies, lifecycle, permissions, rotation, and revocation, often inside the provider’s KMS or HSM. Microsoft describes BYOK as one CMK scenario in which keys are imported into an Azure key-management service. | More governance control; provider infrastructure still performs key management functions. |
| Bring Your Own Key (BYOK) | The customer generates key material externally, often in an HSM or customer KMS, and imports it into the provider’s key-management environment. | Greater control over provenance and lifecycle, but not always full separation from provider infrastructure. |
| External key management / HYOK | The key material stays outside the provider’s environment, and cryptographic operations are authorized through a customer-controlled or third-party external key manager. AWS and Google Cloud both document external-key models in which key material remains outside the provider. | Strongest independent control, with greater operational responsibility. |
| Private, customer-hosted, or hybrid deployment | The customer controls infrastructure, key storage, operational access, logging, and policy enforcement, sometimes alongside SaaS or managed-service components. | Highest customization and governance control; typically, more operational responsibility. |
The message is simple: do not ask only whether a vendor supports BYOK. Ask where the key material resides, who can invoke cryptographic operations, who controls the policy, who receives the logs, and what happens when access is suspended or revoked.
Why Identity and Biometric Data Change the Stakes
For ordinary business data, strong provider-managed encryption may be sufficient. For identity data, the risk calculus changes. Identity systems store and process attributes that connect a person to high-value transactions, regulated services, benefits, accounts, devices, and authentication workflows.
Biometric data raises the stakes further. Passwords, payment cards, and API credentials can be replaced after exposure. A biometric template may be revocable or re-enrollable in some architectures, but the underlying biological trait — a face, fingerprint, iris, or voice cannot simply be reissued. NIST’s digital identity guidance also makes an important point that is often overlooked: biometric characteristics are not secrets and must be treated as sensitive personal information.
That is why key governance belongs in the same conversation as liveness detection, presentation-attack defense, injection-attack defense, consent, retention, auditability, and privacy-by-design. A biometric system is not protected just because the database is encrypted. It is protected when encryption, key control, access policy, monitoring, retention, and recovery all operate under a defensible governance model.
Compliance, Auditability, and Data Sovereignty
Regulations generally do not say, “You must use BYOK.” The more accurate point is that privacy, security, and payment frameworks increasingly require enterprises to demonstrate governance over sensitive data, i.e., who can access it, how access is authorized, how controls are monitored, how keys are protected, and how quickly access can be revoked.
GDPR Article 32 requires appropriate technical and organizational measures, including encryption where appropriate, to ensure that security is appropriate to risk. In healthcare, HIPAA’s Security Rule includes addressable encryption and decryption controls for electronic protected health information, as well as audit controls. Illinois’ BIPA imposes specific obligations on private entities that collect or possess biometric identifiers or biometric information. PCI DSS v4.x requires enterprises using cryptography to protect stored account data to define and implement key-management processes across the key lifecycle.
Customer-controlled encryption helps turn those obligations into evidence. It can support granular key-use logs, independent revocation, separation of duties, rotation policy, retention boundaries, customer-visible audit trails, and regional/geographic or contractual controls over where key operations occur. It also gives security and compliance teams a clearer story when auditors ask who controlled the path to decryption.
Data sovereignty makes the issue even sharper. If an enterprise cannot explain where key material resides, where key operations occur, and which legal or operational authorities can compel or authorize key use, it may struggle to demonstrate meaningful control over sensitive identity data in cross-border or highly regulated deployments.
Zero Trust Requires Cryptographic Governance
Zero trust has moved from architecture theory to a practical benchmark for modern security programs. NIST SP 800-207 states that zero trust assumes no implicit trust is granted to assets or user accounts based solely on network location or asset ownership. Executive Order 14028 pushed U.S. federal agencies toward zero-trust architecture and stronger encryption for data at rest and in transit.
Applied to encryption, zero trust asks a deeper question: is decryption authority explicitly governed, continuously auditable, and revocable by the enterprise that owns the risk? If the answer is no, then the enterprise may have encryption without cryptographic governance.
Customer-controlled key management aligns encryption with zero-trust principles by limiting implicit vendor trust, enforcing least privilege around key use, separating duties across administrators and systems, and creating independent evidence of when cryptographic operations occur. That does not eliminate the need to trust a provider. It narrows the trust boundary and makes it explicit.
BYOK in Practice: What Control Actually Looks Like
The practical implementation of BYOK does not require an enterprise to rebuild its cloud infrastructure. But it does require precision about the architecture. In an imported-key BYOK model, the customer may generate key material externally and import it into the provider’s KMS. In an external-key or HYOK model, the key material remains outside the provider’s environment, and cryptographic operations are routed through a customer-controlled or third-party key manager. Those two models differ.
The operational value is not just “owning a key.” The value is the ability to enforce policy over the key, i.e., who can use it, from where, for which workload, during which time window, under which approval path, and with what audit evidence.
Enterprises evaluating BYOK should ask vendors the uncomfortable questions early:
- Is key material generated by the customer, by the provider, or by a managed HSM?
- Does key material reside inside the provider’s KMS, or outside the provider’s infrastructure?
- Can the customer disable, suspend, rotate, or revoke key use independently?
- Are key-use logs visible to the customer and exportable to the customer’s SIEM or GRC environment?
- What happens to application availability if the key service becomes unreachable?
- What is the tested recovery procedure if a key is lost, corrupted, retired, or mistakenly disabled?
- Can key residency and cryptographic operations be mapped to contractual, regulatory, and geographic requirements?
What Good Key Control Looks Like
A mature customer-controlled encryption program is more than a checkbox in a vendor questionnaire. It should be observable, testable, and operationally owned.
| Control area | What readers should look for |
|---|---|
| Key generation | Customer-generated keys or documented provenance of key material, entropy source, HSM boundary, and administrative ownership. |
| Key storage | Use of a managed HSM, cloud HSM, external KMS, customer HSM, or other approved secure boundary aligned to risk and compliance requirements. |
| Access control | Least privilege, MFA, separation of duties, named custodians, break-glass governance, and no shared administrative accounts. |
| Key use | Policy-based authorization for encryption and decryption operations, with clear workload and environment boundaries. |
| Rotation | Documented rotation schedule, emergency rotation procedures, cryptoperiod definitions, and evidence that rotation has been tested. |
| Revocation | Ability to disable, suspend, or revoke key use without waiting for vendor-side manual intervention, subject to the selected architecture. |
| Logging | Customer-visible logs for key access, failed attempts, policy changes, administrative actions, and cryptographic operations. |
| Residency | Clear understanding of where key material resides, where key operations occur, and which parties can authorize or compel access. |
| Recovery | Tested backup, escrow, disaster-recovery, and key-destruction procedures that avoid both uncontrolled access and unrecoverable data. |
| Audit | Evidence package for regulators, enterprise customers, security teams, and internal risk committees. |
Control Comes With Responsibility
Customer-controlled encryption improves governance, but it also shifts responsibility to the customer. Poorly managed keys can create outages, failed audits, broken workflows, unrecoverable data, or emergency operational dependencies that appear only during an incident.
AWS warns that if an external key associated with an external key store is lost or deleted, ciphertext encrypted under the associated key is unrecoverable. Google Cloud similarly states that external key material is never exposed to Google, which is a security advantage, but also means the customer and external key manager carry real availability and recovery obligations.
A mature BYOK or external-key program therefore needs more than a key. It needs ownership. That means documented custodians, tested recovery, operational monitoring, service-level expectations, incident playbooks, and a clear decision about which datasets justify stronger independent control. NSA and CISA likewise note that customer-managed keys can provide greater flexibility over data-access controls, but require greater resources to perform key-management duties properly.
The goal is not maximum complexity. The goal is the right level of cryptographic control for the sensitivity of the data, the regulatory environment, the threat model, and the enterprise’s ability to operate the control reliably.
Why Daon’s Approach Matters
For enterprises managing identity verification (IDV), authentication, and biometric data, key control is a foundational part of the trust model. The enterprise responsible for the customer relationship, regulatory exposure, and breach response needs a direct role in governing the keys that protect identity data.
Daon’s identity verification and authentication platforms are built with this reality in mind. BYOK capabilities give enterprises control over encryption keys for stored biometric templates and identity data while supporting enterprise deployment models across SaaS, managed hosting, and customer-controlled environments. Gartner Research highlighted customer-controlled encryption keys as a standard capability in the identity verification market.
The business value is straightforward: enterprises can align identity assurance with their own data-governance model, respond more confidently to audit and procurement questions, reduce provider-dependency for sensitive datasets, and demonstrate that control over identity data is engineered, not assumed.
Taking Control of Your Cryptographic Infrastructure
Encryption key ownership is not a future-state capability. It is a present-day requirement for enterprises that handle regulated, sensitive, or biometric identity data at scale. The enterprises that will be best prepared are not the ones that simply ask whether data is encrypted. They are the ones that can explain who controls the key, who can use it, who can revoke it, and how that control is proven.
Daon helps enterprises move from provider-dependent encryption toward customer-controlled cryptographic governance without disrupting identity workflows or forcing unnecessary infrastructure overhauls. If your enterprise is evaluating encryption key management, data sovereignty, zero-trust alignment, or biometric-data governance, Daon can help you determine the right key-control model for your risk profile and deployment environment.
Sources:
- [1] Cloud Security Alliance, “Choosing the Right Key Responsibility Model”. https://cloudsecurityalliance.org/blog/2026/01/05/choosing-the-right-key-responsibility-model
- [2] Microsoft Learn, “Overview of Key Management in Azure”. https://learn.microsoft.com/en-us/azure/security/fundamentals/key-management
- [3] AWS Key Management Service Documentation, “External key stores”. https://docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html
- [4] Google Cloud Documentation, “Cloud External Key Manager”. https://docs.cloud.google.com/kms/docs/ekm
- [5] GDPR Article 32, “Security of processing”. https://gdpr-info.eu/art-32-gdpr/
- [6] 45 CFR § 164.312, HIPAA Security Rule Technical Safeguards. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312
- [7] Illinois General Assembly, Biometric Information Privacy Act, 740 ILCS 14. https://www.ilga.gov/Legislation/ILCS/Articles?ActID=3004&ChapterID=57&Print=True
- [8] PCI Security Standards Council, PCI DSS v4.x resource hub and official SAQ materials. https://blog.pcisecuritystandards.org/pci-dss-v4-0-resource-hub
- [9] NIST SP 800-207, “Zero Trust Architecture”. https://csrc.nist.gov/pubs/sp/800/207/final
- [10] Executive Order 14028, “Improving the Nation’s Cybersecurity”. https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity
- [11] NIST SP 800-63-4 Digital Identity Guidelines. https://pages.nist.gov/800-63-4/sp800-63.html
- [12] Daon, “Why Gartner Says Daon Stands Apart in Identity Verification”. https://www.daon.com/resource/why-gartner-says-daon-stands-apart-in-identity-verification/
- [13] NSA and CISA, “Use Secure Cloud Key Management Practices”. https://media.defense.gov/2024/Mar/07/2003407858/-1/-1/0/CSI-CloudTop10-Key-Management.PDF
