TL;DR: Cloud encryption is only as strong as key custody, and Daon says BYOK shifts encryption keys from provider control back to the enterprise so organisations can manage lifecycles, enforce sovereignty requirements, and revoke access instantly without giving up cloud scalability. That makes key governance a security control, not a compliance afterthought.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Daon's blog post: BYOK moves encryption key control back to the customer, making key lifecycle governance central to cloud security, sovereignty and revocation.
Why it matters: IAM and security teams need to treat key custody as a governance decision because encryption strength depends on who can rotate, revoke and recover the keys, not just on where the data sits.
Context
Bring Your Own Key is a cloud encryption model in which the customer controls the cryptographic keys while the provider stores and processes encrypted data. That separation matters because default provider-managed encryption reduces operational friction but also narrows customer control over access, revocation and key lifecycle decisions.
For identity and access teams, BYOK is less about encryption mechanics than about custody, delegated authority and recovery responsibility. It also intersects with cryptographic key management because the operational question is who can generate, rotate, audit and destroy keys under policy.
The starting position described here is typical for enterprises that are trying to balance compliance, portability and cloud adoption, but it becomes unusual when organisations claim strong control while leaving key governance mostly to the provider.
Key questions
Q: How should teams decide between BYOK and provider-managed encryption?
A: Choose BYOK when your security or compliance team must control key creation, rotation, revocation, and audit evidence, and when the cloud provider should not be able to use the key independently. Use provider-managed encryption when operational simplicity matters more than key custody and you accept the provider controlling the encryption keys. The decision turns on who holds the key, who can revoke it, and who can prove control.
Q: Why does customer-managed encryption reduce cloud breach impact?
A: Customer-managed encryption reduces cloud breach impact because stolen data remains encrypted unless the attacker also compromises the key management boundary. With customer control over the keys, the provider or an intruder in the cloud control plane cannot usually decrypt protected data without access to the customer-held keys, key policy, or HSM-backed authority. It narrows the blast radius by separating data storage from key custody.
Q: How do I rotate cloud encryption keys without breaking applications?
A: Rotate cloud encryption keys by creating a new key version, updating the key alias or reference used by the application, and allowing decrypt operations for older ciphertext during a transition window. Keep the same key material accessible until re-encryption or re-wrapping is complete, then retire the old version. Test dependencies on database, object storage, and client-side caching before cutting over.
Q: What happens if customer-managed encryption keys are lost?
A: If customer-managed encryption keys are lost, encrypted data usually becomes unreadable and may be unrecoverable, because the provider cannot decrypt it without those keys. Recovery depends on having a backup key, a wrapped copy, escrow, or an intact key recovery process. Without one of those controls, the data remains locked even if the storage itself is intact.
Technical breakdown
How BYOK changes the cloud encryption trust model
BYOK splits data custody from key custody. The cloud provider can store encrypted data and apply keys under customer policy, but it cannot independently use those keys without the customer’s governance decisions. That changes the trust boundary from provider assurance to customer-controlled cryptographic authority. In practice, the value of BYOK is not that encryption exists, but that the enterprise controls the conditions under which decryption can happen. This matters most when organisations need demonstrable control for sovereignty, auditability or breach containment. See the Cryptographic Key Management Guide.
Practical implication: Map each cloud workload to a named key owner and approval path so decryption authority is explicit rather than assumed.
Direct upload, key wrapping and external key management
The article describes three common patterns. Direct key upload places customer-generated keys into the provider’s key service. Key wrapping keeps a key encryption key under customer control while using wrapped data encryption keys in the cloud. External key management goes further by keeping keys outside the provider environment and requiring authenticated requests for decryption. These are not equivalent choices. They differ in where trust is concentrated, how availability is protected and how much operational complexity the customer assumes. See the BYOK, HYOK and External Key Management Guide.
Practical implication: Choose the key custody model that matches your risk tolerance, then test availability, recovery and failure modes before production use.
Why key lifecycle, not just encryption, is the control plane
BYOK only works when key lifecycle operations are governed end to end. Generation, rotation, backup, recovery and revocation are the real control points, because losing the key can mean permanent data loss while retaining it too long can preserve exposure after compromise. This is why customer-managed encryption is as much an identity and privilege problem as it is a cryptography problem: systems and administrators need narrowly scoped, auditable authority over keys and decryption requests.
Practical implication: Define rotation, backup and revocation procedures for keys with the same rigour you apply to privileged access and recovery accounts.
Threat narrative
Attacker objective: The objective is to convert protected cloud data into usable plaintext or to force irreversible data loss by abusing key governance rather than storage access.
- Entry occurs when attackers compromise cloud infrastructure, a provider account or an integration path that would normally be trusted to access encrypted data.
- Credential access is limited because the keys remain under customer control, so the attacker must target the key lifecycle, an operator, or a decryption workflow rather than only the storage layer.
- Impact follows when key governance fails, because exposed or mismanaged keys can turn encrypted data into readable data or make recovery impossible after deletion.
Breaches seen in the wild
- Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
BYOK is a governance control, not a checkbox encryption pattern. The real issue is who can authorise decryption, revoke access and recover from compromise. Once key authority moves back to the enterprise, cloud encryption becomes part of access governance rather than a passive storage feature.
Customer-controlled keys create a new form of operational blast-radius control. If provider infrastructure is compromised, encrypted data remains unreadable unless the attacker can also influence customer-held key material or decryption policy. That makes key custody one of the few cloud controls that can directly reduce the value of a provider-side compromise.
Key lifecycle failure is the hidden risk in customer-managed encryption. BYOK increases control, but it also raises the cost of mistakes, because key loss, stale rotation or weak recovery planning can create permanent unavailability. The security model only holds when lifecycle ownership is explicit and auditable.
Cloud sovereignty claims only hold when key authority is independent. Organisations that rely on provider-managed defaults may meet technical encryption requirements while still lacking meaningful control over cross-border access, audit evidence or emergency revocation. In regulated environments, that gap is often the difference between plausible assurance and provable control.
Cloud key custody is becoming a machine-identity problem. The systems that request, wrap, rotate and revoke keys act like privileged non-human identities, so they need the same inventory, scope control and audit discipline as any other high-risk credential. Without that, customer-managed encryption can inherit the same governance gaps as unmanaged service accounts.
What this signals
Cloud key custody is moving toward identity-style governance. The systems that generate, wrap, request and revoke keys now behave like privileged non-human actors, so the programme question is not whether encryption exists but whether decryption authority is bounded, auditable and recoverable.
BYOK exposes a governance gap many programmes still understate. Teams often focus on whether the provider supports customer-managed keys, but the harder question is whether they can prove key ownership, lifecycle control and emergency revocation under pressure. That is where cloud encryption either becomes defensible or remains largely symbolic.
For practitioners
- Define a named key owner for every workload Assign accountable ownership for generation, rotation, recovery and revocation so each BYOK deployment has a clear governance chain.
- Test revocation before production cutover Validate that key revocation actually blocks decryption, then document the operational impact on dependent applications and recovery procedures.
- Separate backup of keys from backup of data Store key recovery material under independent controls and verify that restoring the data alone does not restore access without policy approval.
- Review provider and customer responsibilities Map which party handles rotation, logging, incident response and emergency access for each encryption model before approving deployment. See the Cloud Security Guide.
- Assess whether HYOK is justified Use the stricter external-key model only where sovereignty, regulatory pressure or exposure to provider-side compromise justify the added complexity.
Key takeaways
- BYOK changes cloud encryption from a provider-default setting into an enterprise governance decision about who can decrypt, rotate and revoke.
- The main risk is no longer only external compromise of storage, but failure to control the key lifecycle and recovery path.
- Enterprises should treat key custody as a privileged control surface and verify that revocation, backup and restoration work before relying on BYOK in production.
Related NHI Mgmt Group resources: Cryptographic Key Management Guide · BYOK, HYOK and External Key Management Guide · Cloud Security Guide · Internet Archive breach 2024
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | BYOK hinges on controlling the lifecycle of cryptographic keys, not leaving them effectively permanent. |
| NHI-02 — Secret Leakage | Customer-controlled keys must be protected from exposure in export, backup and operational workflows. | |
| Recommendation — Inventory cloud keys, enforce rotation and remove any keys that remain valid beyond their intended lifecycle. Scan key handling workflows for exposure points and revoke any secret material that leaves approved custody. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Key lifecycle governance is an authenticator-management problem for systems that decrypt or sign on behalf of the enterprise. |
| Recommendation — Apply IA-5 to govern creation, rotation and revocation of cloud encryption credentials and key material. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | BYOK is fundamentally about limiting who and what can use encryption authority. |
| Recommendation — Restrict decryption permissions to approved service accounts, operators and workflows under explicit policy. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Attackers seeking encrypted data often pivot from storage access to credentials or key workflows. |
| Recommendation — Hunt for credential-access activity targeting key services, backup stores and administrative decryption paths. | ||
Key terms
- 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 life cycle: Key life cycle is the full set of stages a cryptographic key goes through, from generation and distribution to storage, rotation, suspension, revocation, and destruction. Weak control at any stage can expose data or identities. Practitioners define ownership, automated rotation, expiry, and secure deletion requirements.
- Customer-Managed Encryption: 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.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management in the context of real operational controls. It helps security and IAM teams connect identity governance to the privileged systems that underpin cloud security decisions.
Published by the NHIMG editorial team on November 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org