What are the key Encryption at Rest best practices?

What encryption at rest actually has to cover

The first practice is scope, because encryption only helps if it protects every stored copy of the data you care about. That includes databases, object storage, file systems, backups, snapshots, replicas, exports, caches, and removable media. A sound design also separates key custody from the encrypted data itself, so a storage compromise does not automatically reveal the contents.

Algorithm choice matters, but the more common failure is partial coverage or inconsistent implementation. A strong standard cipher is still weakened if one subsystem writes plaintext, a backup path is missed, or a recovery process bypasses the normal encryption controls. For a practical overview of storage encryption patterns, Encryption Guide is the most complete starting point.

Key management and access control are the real control layer

Encryption at rest is only as strong as the protection around the keys. Centralised key management lets you control who can decrypt, rotate keys without scattering secrets across systems, and keep an audit trail of key use. In practice, that means key access should be tightly limited, separately logged, and reviewed with the same care as privileged access to the data platform itself.

Rotation should be routine for operational hygiene and immediate after suspected exposure, but rotation alone does not fix a bad trust model. If a service, operator, or application can always reach the key with no meaningful restriction, the encryption layer is mostly cosmetic. Teams that manage encryption key as a lifecycle asset should align that work with a formal key management process such as Cryptographic Key Management Guide and compare it with the guidance in NIST SP 800-57 Key Management.

Where encryption at rest still fails in practice

The main misconception is that encrypted storage makes data safe in every situation. It does not protect data that is already available to a trusted system, an authenticated user, or a compromised application that can request decryption. It also does not help if keys are stored with the same blast radius as the data, or if replicas and backups are encrypted but the restore process exposes the plaintext too broadly.

Operationally, this is why incidents involving backups or secret material often become data exposure events even when encryption was present. The lesson from backup theft and key exposure cases is that encrypted copies are still recoverable by an attacker who can obtain the right key material or session path. That is why readers should treat backup protection as part of the same control surface as primary storage, not as a separate problem. Examples like GoTo breach 2023 and LastPass breach 2022 show why backup access and key custody must be designed together.

Risk and Threat Considerations

Encryption at rest reduces exposure from lost media, cloud storage compromise, and accidental disclosure, but it can create a false sense of safety if key access, restore paths, or privileged users are overtrusted. The highest-risk pattern is not broken crypto, it is broken custody, where attackers or insiders reach both the ciphertext and the means to decrypt it.

Failure mechanism: An attacker, insider, or compromised service obtains key material, tokenised access to a KMS, or a restore path that reveals plaintext after decryption. If backups, snapshots, replicas, or exports sit outside the same access controls as production data, the control fails at the point of recovery rather than at storage.

Impact: Sensitive records can be reconstructed even when the underlying store was encrypted, which turns a storage incident into a full confidentiality breach. In regulated environments, that can also mean loss of trust in backup integrity, broader incident response scope, and emergency credential or key rotation across dependent systems.

Practitioner Guidance

What to verify: Confirm that encryption covers every data copy, not just the primary database or volume. Restore tests should prove that backups and snapshots are decryptable only by the right operators and that revoked access actually breaks the recovery path.

What to prioritise: Put the strongest controls around key access, rotation, and audit logging before optimising cipher choice. The usual mistake is spending effort on algorithm language while leaving backup buckets, admin roles, and automation accounts able to decrypt too broadly.

Practitioner takeaway: Treat encryption at rest as a custody problem, not just a storage feature. If the key path, restore path, or privileged access path is weak, the encryption itself will not prevent exposure.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• What are the key Endpoint Encryption best practices?
• What are the key disk encryption recovery best practices?
• What are the key PGP Encryption best practices?