Encryption at rest protects stored data by making it unreadable without the correct key, even if disks, databases, or backups are copied. Security teams should confirm which data stores are covered, how keys are generated and rotated, who can access them, and whether the encryption also applies to snapshots and replicas.
What encryption at rest actually changes
Encryption at rest changes the value of stored data to an attacker or unauthorised insider. The file, table, volume, or backup still exists in usable form for approved systems, but the underlying ciphertext is only recoverable when the right key material is available and the access path is authorised.
That distinction matters because the control is about data exposure in the storage layer, not about preventing every form of misuse. If an application, database engine, or backup service can decrypt data during normal operation, encryption at rest does not stop abuse through those trusted paths.
In practice, this is why teams often treat storage encryption as one layer in a larger protection model. It is strongest when paired with access controls, key segregation, and sound backup handling, and weakest when everyone who can touch the data store can also reach the keys.
Where encryption at rest is usually applied
Encryption at rest is commonly used on disks, object stores, database files, snapshots, and archived backups. The exact scope depends on the platform, so the first question is whether the encryption covers only the primary data store or also the copies that are most likely to be overlooked.
For databases, there is an important difference between encrypting the storage engine and encrypting specific fields or columns. Full-disk or volume encryption helps protect the media, while field-level encryption can reduce exposure if only part of the dataset should be readable outside the application boundary.
Another practical detail is replica handling. If replicas inherit the same encrypted storage, the control remains consistent across environments. If they are created from snapshots, exports, or migration workflows, the encryption assumptions must be checked again rather than assumed from the primary system.
How keys make or break the control
The control works only as well as key generation, storage, access, and rotation. Stored data can remain technically encrypted while still being effectively exposed if the same administrative path can retrieve both the ciphertext and the decryption key.
Key custody is therefore the real control boundary. Good designs separate key management from routine storage administration, restrict who can decrypt, define rotation and revocation procedures, and preserve an auditable record of key use.
Encryption at rest also depends on lifecycle discipline. A long-lived key, an orphaned backup key, or a forgotten replica key can keep old data readable long after the system owner thinks access has been removed. Encryption Guide covers the relationship between storage encryption, envelope encryption, and key custody in more depth.
Risk and Threat Considerations
The main risk is overestimating what encryption at rest protects. It reduces exposure from lost media, copied backups, and some storage-layer compromise, but it does not automatically protect data that is already accessible to a running system, a privileged operator, or a compromised application account.
Failure mechanism: The protection fails when the attacker can reach decrypted data through the live workload, when key access is too broad, or when snapshots and replicas are not included in the encryption scope. In those cases, storage encryption exists but the practical confidentiality boundary has already been crossed.
Impact: Breaches can still expose regulated, sensitive, or high-value data even though the storage layer was encrypted. Recovery also becomes harder if key ownership, rotation, or backup decryption procedures were not designed and tested before an incident.
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 addresses the attack surface, NIST SP 800-57, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | Encryption at rest depends on key lifecycle, rotation, and custody. |
| Recommendation — Apply disciplined key lifecycle controls and rotate keys on a defined schedule. | ||
| NIST SP 800-53 Rev 5 | SC-28 — Protection of Information at Rest | Directly addresses protecting stored data from disclosure when media or backups are copied. |
| Recommendation — Encrypt stored data and verify protection extends to backups and replicas. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Cryptographic protection of stored data is central to this question. |
| Recommendation — Define cryptographic use, key handling, and scope for stored information. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Stored-data encryption is a core data protection safeguard. |
| Recommendation — Classify sensitive data and apply encryption to stored copies and backups. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Key custody and exposure determine whether encrypted data stays protected. |
| Recommendation — Protect encryption keys as secrets and restrict access to decrypt operations. | ||
Practitioner Guidance
What to verify: Confirm the complete data path, not just the primary volume or database. Check whether snapshots, replicas, export jobs, and backup repositories are encrypted under the same policy, and confirm whether the key holder set is narrower than the storage administrator set.
Decision rule: If the same team can administer the data store and retrieve the decryption key, treat the control as shared responsibility rather than strong separation. If you need stronger blast-radius reduction, move toward tighter key segregation, narrower decrypt rights, and application or field-level controls for the most sensitive data.
Practitioner takeaway: Encryption at rest is a storage-layer protection, not a complete confidentiality solution, so the real question is whether keys, backups, and replicas are controlled as carefully as the data itself.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org