Who holds your encryption keys?
Encryption at rest is table stakes. The question auditors, regulators, and sophisticated customers ask next is who controls the keys. Here is how to answer it.
“Is the data encrypted at rest?” used to be a hard question. Today the answer is almost always yes. Every major cloud provider encrypts storage by default. Every database has transparent data encryption. Every laptop ships with full-disk encryption. The checkbox is checked.
The question that matters now is the one underneath it: who holds the keys, and what can they do with them?
Sidechain has designed and operated key management for some of the largest companies in the world. This article is the short version of what we learned.
Encryption is only as strong as key control
Encrypting data and then storing the key next to it is a locked door with the key in the lock. It protects against someone walking off with a disk. It does not protect against anyone who can log in to the system, including the provider that operates it, an administrator whose credentials were phished, or an attacker who has compromised the platform.
Key control answers three questions:
- Who can use the key to decrypt data?
- Who can access or export the key itself?
- Who can revoke the key, making the data unrecoverable to everyone else?
The further those answers are from “the same people who can access the data,” the stronger the protection.
The spectrum of key ownership
Working from least control to most:
Provider-managed keys. The cloud or SaaS provider generates, stores, and uses the keys. You see a checkbox that says “encrypted.” The provider can decrypt your data, and so can anyone who compromises the provider’s key infrastructure or obtains a lawful order against them. This is the default almost everywhere, and it is fine for data that does not need to be protected from the provider.
Customer-managed keys in the provider’s KMS. You create keys in the provider’s key management service (AWS KMS, Azure Key Vault, Google Cloud KMS) and grant the provider’s services permission to use them. You control the key policy, you can audit every use, and you can revoke access. The key material still lives in the provider’s infrastructure. This is a meaningful step up and the right answer for most cloud workloads.
Bring Your Own Key (BYOK). You generate key material in your own hardware security module and import it into the provider’s KMS. You hold the original. If you stop trusting the provider, you can destroy your copy and theirs becomes useless on the next rotation. The provider still operates the key during use.
Hold Your Own Key (HYOK) or external key management. The key never enters the provider’s environment. Encryption and decryption calls go out to a key manager you operate, typically backed by an HSM. The provider processes your data only while you allow it, and you can cut access at any moment. This is the strongest model and the one that satisfies data sovereignty and “the provider cannot read our data” requirements. It also requires you to run key infrastructure with real availability, because if your key manager is down, so is your application.
What regulators and customers are actually asking
Different drivers push organizations along this spectrum.
HIPAA. The proposed Security Rule update makes encryption of ePHI required. It does not mandate a key ownership model, but a risk analysis that treats “the vendor can decrypt everything” as an acceptable risk needs to justify it.
PCI-DSS. Requirement 3 is explicit about key management: documented procedures, split knowledge and dual control for manual operations, secure key storage, rotation, and retirement. Tokenization is often the better answer, because it removes cardholder data from scope rather than protecting it in place.
Data sovereignty and contractual requirements. Enterprise customers increasingly require that their data be encrypted with keys they control, especially in financial services and government-adjacent work. BYOK is the usual answer; HYOK for the most sensitive cases.
Ransomware and insider risk. A compromised administrator with access to data and keys can exfiltrate both. Separating key administration from data administration limits what any one compromised account can do.
The operational reality
Key management is where good intentions go to die. We have inherited many deployments where the design was sound and the operation had drifted:
- Rotation schedules that were set once and never ran.
- Expired certificates on the key manager that nobody tracked, taking applications down.
- Encryption agents that silently stopped reporting, leaving systems unprotected for months.
- Access policies that accumulated exceptions until everyone was an administrator.
- A single HSM with no tested recovery, protecting data that could not be recovered without it.
This is why organizations hand key management to us as a managed service. The platform (Thales CipherTrust, Luna HSMs, Entrust, Utimaco, Fortanix, or the cloud KMS services) matters less than whether someone is operating it with discipline: monitoring, patching, policy review, rotation, tested recovery, and documentation an auditor can follow.
Where to start
Inventory your sensitive data, identify what encrypts it, and for each system answer the three questions: who can use the key, who can access it, who can revoke it. Where the answer to all three is “the same provider that holds the data,” decide whether that is acceptable for that data. Where it is not, move one step along the spectrum.
Sidechain’s encryption and key management practice designs, deploys, and operates every model described here. If you are already running Thales CipherTrust, a health check by a certified engineer is the fastest way to find out whether your deployment still matches its design.
