Data-at-rest encryption helps keep stored information confidential if a laptop, server, backup, snapshot, or removable drive is lost, stolen, or accessed outside its intended controls. It is not a complete security boundary: an authorized process can still read decrypted data, and encryption at rest does not protect information while it is being transmitted or processed.
What counts as data at rest?
Data at rest is information stored on a system component rather than actively being processed or sent over a network. It includes user files and system information on internal or external drives, storage-area networks, databases, cloud objects, snapshots, backups, and removable media. NIST discusses this scope in its security control SC-28 and in its storage-security guidance, SP 800-209.
Encryption transforms readable plaintext into ciphertext. A person or system without the appropriate decryption key should not be able to readily understand the protected information. In practice, encryption reduces the chance that access to the storage itself will expose its contents; its protection depends on where encryption is applied and who can use the keys.
What risk does encryption at rest reduce—and what does it leave exposed?
It is especially useful against disclosure when storage media or copies of data escape their normal controls—for example, a stolen laptop, a misplaced backup drive, or an improperly accessed snapshot. NSA and CISA describe encryption at rest and in transit as “an imperative for sensitive data.”
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
#1 Best Overall
Encryption does not prevent every breach. If an attacker takes over an account, service, or administrator role that is allowed to decrypt the data, that attacker may be able to read it in plaintext. Encryption also does not protect data while an application is processing it, or while it travels across a network. Use TLS for data in transit, and pair encryption with access controls, monitoring, patching, backup-integrity safeguards, and incident response.
Which type of storage encryption fits the job?
The options protect different boundaries. NIST SP 800-111 groups storage encryption into major classes that include full-disk, volume, and file- or folder-level approaches; database and cloud services add application- and provider-specific choices.
| Approach | Protection scope | Useful when | Key and operational considerations |
|---|---|---|---|
| Endpoint full-disk encryption (FDE) | Encrypts an endpoint drive, including operating-system and temporary files. It is intended to protect the drive when the device is powered off or locked. | Protecting laptops and other endpoint devices against loss or theft. | Plan how users authenticate at startup or unlock, and how an administrator can recover access if a device or user credential is unavailable. Once the system is unlocked, authorized processes can access data. |
| Volume or virtual-disk encryption | Protects a logical volume or virtual disk rather than necessarily covering every storage location on a host. | Servers, virtual machines, and removable media where a defined storage volume is the practical boundary. | Map which volumes are covered and make sure separate disks, exports, snapshots, and backups are not overlooked. Restoration depends on access to the relevant keys and configuration. |
| File, folder, or application-layer encryption | Protects selected files, folders, or records, allowing more targeted protection than encrypting an entire drive. | Sharing or carrying selected sensitive data across systems, or limiting access to particular records. | Track copies and related material such as logs, indexes, and temporary files. Granular protection can create more key, permission, and compatibility work. |
| Database encryption | Transparent data encryption can protect database files and snapshots; application- or column-level encryption can narrow protection to selected data. | Protecting stored database contents, with finer-grained controls where the application and use case support them. | Determine which database files, snapshots, exports, logs, and replicas are covered. More granular designs require careful handling of how applications access and use protected fields. |
| Cloud-provider encryption | May protect provider-managed storage such as cloud objects, database storage, and snapshots; exact coverage varies by service and configuration. | Cloud workloads where storage encryption is configured through the provider or integrated key-management services. | Establish who controls the keys, what services and regions are included, and whether backups, replicas, snapshots, logs, and exports are encrypted. Do not assume every service has the same defaults. |
These methods can be combined. For example, a server volume may be encrypted while an application separately encrypts a particularly sensitive field. Choose based on the data and threat model, not the assumption that one encryption setting automatically covers every copy or use.
How should you cover laptops, servers, databases, backups, and cloud storage?
Start by identifying the data and all the places it is stored. NIST’s 2024 NCCoE practice guide treats confidentiality as an asset-identification and breach-protection problem: encryption belongs alongside data classification, access control, segmentation, detection, retention, and recovery—not in place of them.
Rank #3
- Laptops: Use full-disk encryption to cover the endpoint drive, including system and temporary files. Confirm that the unlocking and recovery arrangements work for both users and administrators.
- Servers and virtual machines: Decide whether host-level, volume, or virtual-disk encryption best matches the storage layout. Inventory attached storage and separately check snapshots, exports, and backups.
- Databases: Consider transparent encryption for database files and snapshots. If certain records need tighter access boundaries, assess application- or column-level encryption and account for how the application will use those fields.
- Backups and removable media: Encrypt them as storage in their own right, not merely because the source system is encrypted. Include off-site copies and any exported or copied data. For removable media, a hardware-encrypted USB flash drive is one option; check a current product’s capacity, operating-system support, certification, and recovery features before relying on it.
- Cloud services: Verify encryption for primary data, replicas, snapshots, logs, exports, and backups. Check the applicable service, region, key owner, and configuration rather than treating “cloud encryption” as a single setting.
A useful coverage check is to trace a sensitive data set from creation through use, copying, backup, retention, and deletion. For every stored copy, identify the encryption boundary and the key that unlocks it. NSA and CISA recommend approved encryption mechanisms for sensitive cloud data; the UK NCSC advises providers to encrypt customer data at rest using appropriately configured algorithms and notes that full-disk and application-layer encryption can be combined. For web connections, NSA and CISA recommend TLS 1.2 or higher.
Why key management determines whether encryption works
Encryption is only as dependable as the lifecycle of its keys. NIST treats key management as a fundamental requirement. A lost key can make a legitimate backup unreadable; an exposed key can defeat the protection encryption was meant to provide.
Define who can create, distribute, use, recover, rotate or replace, revoke, and destroy keys. Restrict key administrators separately from data administrators where practical, log key use, and protect key backups. NIST SP 800-111 discusses authenticators such as passwords, smart cards, tokens, centralized servers, and hardware-protected storage.
- Document key ownership, permitted uses, and the people or services responsible for recovery.
- Protect key backups or escrow so a storage failure does not make valid data unrecoverable; test restoration rather than assuming it will work.
- Plan emergency access and separation of duties, including what happens if a key administrator is unavailable.
- Use hardware-backed or non-exportable key storage where it fits the threat model, while accounting for dependence on that hardware or service and on its recovery process.
- Set a process for rotation or replacement, revocation after suspected exposure, and secure destruction when keys are no longer needed.
How to choose and verify an implementation
- Classify the data and identify copies. Record the sensitive information, its storage locations, who needs it, and where it is replicated, logged, exported, or backed up.
- Choose the encryption boundary. Use device- or volume-level encryption for broad storage coverage; use file-, application-, or database-level controls when selected data needs more granular access or sharing.
- Set key ownership and recovery before deployment. Decide who controls keys, how access is authenticated, how recovery is authorized, and how restoration will be tested.
- Verify the actual service configuration. Check the current documentation and settings for the chosen operating system, database, storage platform, or cloud service. Confirm the regions and data types covered, including copies and metadata that matter to your deployment.
- Test ordinary access and recovery. Confirm that authorized users and services can work as intended, and that an approved recovery path can restore data without bypassing the intended controls.
- Monitor and revisit coverage. Log key use and review encryption when storage, services, data sensitivity, ownership, or recovery arrangements change.
Cloud providers offer different combinations of server-side encryption, client-side encryption, customer-managed keys, and key-management services. AWS documentation, for example, covers S3 default encryption, KMS policies and rotation, CloudHSM, and RDS database and snapshot encryption. These are platform-specific implementation options, not evidence that another provider—or every AWS service and configuration—has identical defaults or coverage.
Quick Recap
Common gaps to avoid
- Encrypting the primary disk but not its copies: Backups, exports, snapshots, replicas, and removable media need their own coverage checks.
- Assuming encryption stops an authorized account: Review identity permissions and service access, because permitted decryption can expose plaintext.
- Treating storage encryption as transport security: Protect network connections separately; encryption at rest does not replace TLS.
- Enabling a cloud setting without checking its boundary: Confirm relevant services, regions, keys, metadata, and secondary copies rather than relying on a provider-wide assumption.
- Failing to test key recovery: A control that prevents unauthorized reading can also block legitimate restoration if key access is lost.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
