Cloud encryption protects data at rest in storage, in transit across networks, and sometimes in use. Encryption itself is rarely the weak point. The key question is who holds the keys: the provider, you through a key service, or you outside the provider entirely.
What are the three states of data?
At rest. Stored data such as disks, databases and object storage. NIST SP 800-111 is the guide to storage encryption technologies for end user devices, and its concepts carry over to server and cloud storage.
In transit. Data moving between client and service, or between services. The standard here is TLS. RFC 8446 defines TLS 1.3, and NIST SP 800-52 Revision 2 gives guidelines for selecting and configuring TLS in government systems, which many companies use as a reference.
In use. Data being processed in memory. This is the hardest state to protect, and special hardware features exist for it. Treat it as an advanced requirement, not a default.
Who holds the keys?
Encryption is only as strong as the control of its keys. NIST SP 800-57 Part 1 covers general key management: generating, storing, using, rotating and destroying keys, and limiting who may use them.
There are broadly three models.
- Provider-managed keys. The service encrypts for you. Easy, no extra work, and the provider controls the key.
- Customer-managed keys. You create and control the key in the provider's key service. You set who may use it and can disable it.
- Keys you hold outside the provider. Data is encrypted before it reaches the cloud, or the key lives in a system you run. Strongest separation, more work, and loss of the key means loss of the data.
Which one fits depends on your threat model. If the risk is a stolen disk or a misconfigured snapshot, provider-managed keys help. If the risk is a compromised cloud account, whoever can use the key through that account still reads the data, so access policy on the key matters as much as the key itself.
What does a constructed mistake look like?
A team encrypts its database with a customer-managed key and feels covered. The key policy lets any administrator in the account use it. An attacker steals an admin token and decrypts everything through the normal service. Encryption worked as designed. The key policy was the gap.
What does encryption not cover?
Encryption does not stop an authorised caller from reading data, and it does not help with flaws in the application that serves the data. A web application that returns any record to any logged-in user will happily decrypt it for them. It also does not replace backups: ransomware that encrypts your data with the attacker's key is encryption working against you. Treat encryption as one layer, alongside access control, logging and tested recovery.
How should you think about performance and cost?
Encryption at rest is usually switched on with a setting and adds little noticeable delay. Customer-managed keys add calls to a key service, and those calls can have rate limits and charges, so check them before you encrypt something accessed millions of times a day. Envelope encryption, where a data key encrypts the data and a master key protects the data key, is the usual design to limit those calls.
How to check or apply this
- Classify the data you hold, so you know what needs which protection.
- Confirm encryption at rest is on for every store, including backups and snapshots.
- Require current TLS versions between users and services, and between internal services.
- Choose a key model per data class and write down why.
- Restrict key use to named roles and services, and log every use.
- Set a rotation schedule and test that rotation does not break applications.
- Plan key recovery and deletion. Test that a deleted key cannot be restored by mistake.
- Check that secrets and tokens are not stored in code or images.
Quick check
Is data safe if it is encrypted at rest?
Only against threats like stolen media. Someone with legitimate access to the key through a compromised account can still read it.
Should you always hold your own keys?
Not always. It adds work and the risk of losing data. Choose by threat model and regulatory need.
Sources
- NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
- NIST SP 800-111, Guide to Storage Encryption Technologies for End User Devices
- NIST SP 800-52 Rev. 2, Guidelines for TLS Implementations
- RFC 8446, TLS 1.3
Last reviewed: 18 October 2026.
