What is the difference between encryption at rest and encryption in transit?

They protect different moments in a data item's life. Encryption in transit protects bytes while they move across a network — TLS on a web session, a site-to-site VPN, an encrypted replication link — and stops interception between two endpoints. Encryption at rest protects bytes while they sit on storage and stops anyone who obtains the medium from reading it. Neither substitutes for the other, and a third category, protection of data in use, covers memory while a process is actively working on it. Most compliance frameworks name at least the first two separately, so a control that satisfies one will not close a finding written against the other.

Is a self-encrypting drive better than software full-disk encryption?

Each wins on a different axis. A self-encrypting drive performs the work in its own controller, so there is no host CPU cost, encryption covers everything written with no way to provision an unprotected volume, and cryptographic erase makes disposal fast. Software encryption is auditable, portable across hardware, centrally manageable through familiar tooling, and independent of any one vendor's firmware quality — which matters, because the 2018 research into flawed SSD implementations is the reason BitLocker stopped defaulting to hardware encryption. Many organizations run software encryption as the standard and reserve validated SEDs for cases where cryptographic erase or CPU headroom genuinely drives the decision.

What does FIPS 140-3 validation actually mean for a drive or appliance?

It means the cryptographic module inside the product — a defined boundary of hardware, firmware, or software, not the whole product — was tested by an accredited laboratory and issued a numbered certificate by the Cryptographic Module Validation Program. The certificate names the module, the version, and the security level it met, from Level 1 (approved algorithms, no specific physical protection) to Level 4 (robust physical and environmental attack resistance). It does not certify the product as secure overall, and it says nothing about how the product is deployed. Ask for the certificate number and check that it covers the exact model and firmware you are being quoted.

What happens to FIPS 140-2 validated equipment we already own?

Nothing operationally. CMVP moves the remaining FIPS 140-2 certificates to its Historical list on September 21, 2026, and that change is not retroactive — deployed systems keep running and CMVP explicitly supports the continued use of those modules in existing systems. What changes is the evidence value going forward: the program's guidance is that federal agencies should not include Historical modules in new procurements, while agencies may make their own risk determination about continuing to use what they already have. The practical effect lands on the purchasing side rather than the operations side, which is why it is worth checking before a refresh rather than after.

Does encrypting data at rest protect us from ransomware?

Not meaningfully, and the assumption that it does is a common planning error. Ransomware runs as an authorized process on a running machine where the volume is already unlocked, so it reads your files exactly as any other program would and encrypts them a second time under its own key. Encryption at rest defends against possession of the medium, not against execution on the host. The controls that address ransomware are elsewhere: segmentation, endpoint detection, least privilege, and above all backups the attacker cannot alter — immutable copies with a retention lock the backup administrator's own credentials cannot revoke, plus tested restores.

Where should encryption keys be stored?

Anywhere other than alongside the data they protect, and ideally somewhere that enforces separation of duties. For endpoints, the Trusted Platform Module already fitted to most business-class machines is the intended anchor: it seals the volume key to the measured boot state so a drive moved to another machine stays unreadable. For servers, databases, and certificate authorities, a key-management system backed by a hardware security module is the usual pattern, because it keeps key material inside a validated boundary and produces the audit trail an assessor asks for. Whatever the mechanism, plan escrow and recovery deliberately — recovery keys saved into the same directory service they protect is the failure mode that shows up most often.

Data-at-Rest Encryption: FDE, SEDs and FIPS

By Uniqcli Team

Data-at-rest encryption is the protection applied to data while it is stored rather than while it is moving across a network or being processed in memory. In practice it means the bytes written to a disk, an array, a tape, or a backup target are ciphertext, and reading them requires a key held somewhere the medium itself does not carry. The threat it is built for is possession: a drive pulled from a decommissioned server, a laptop left in a car, an array that leaves a building on a pallet, a backup tape that never arrives.

The reason the term needs explaining is that the encryption can live at four different layers, and the layer decides what is actually protected. Full-disk encryption run by the operating system protects the volume when the machine is off. A self-encrypting drive does the same work inside the drive's own controller. Transparent database encryption protects the database files without touching the application above them. Application-layer or field-level encryption protects specific values so that even a database administrator with full access reads ciphertext. These are not competing products so much as different blast radii, and the compliance requirement you are answering usually determines which one counts.

The four places encryption can sit

Full-disk encryption (FDE) is implemented in software by the operating system and covers an entire volume, including the swap file and temporary data that file-level tools miss. It is the standard control for endpoints, and on modern hardware it leans on a Trusted Platform Module to hold the volume key so that a drive removed and mounted elsewhere stays unreadable. A self-encrypting drive (SED) performs the equivalent work in the drive's own controller, encrypting everything written to the media as a matter of course, with the drive's data-encryption key protected by an authentication key supplied at unlock. The TCG Opal specification covers client SEDs and the TCG Enterprise specification covers enterprise SAS and similar drives.

Above the block layer, transparent data encryption (TDE) is a database feature that encrypts data files, log files, and backups on disk while remaining invisible to the queries running above it — useful precisely because it requires no application change, and limited for the same reason, since any session authorized to query the database reads plaintext. Application-layer or field-level encryption goes further by encrypting specific values before they are ever handed to the database, which is the only one of the four that protects a record from a privileged database operator. File and folder encryption sits alongside these for selective protection of individual documents. Most real environments run several of these at once for different data.

Self-encrypting drives: what they buy, and one caution

The practical arguments for a SED are performance, coverage, and disposal. Encryption happens in dedicated silicon in the drive's controller, so there is no measurable host CPU cost and no throughput penalty on the general-purpose processor. Coverage is total by construction: the drive encrypts everything it writes, with no possibility of a volume being provisioned without protection because someone skipped a step. And because all data on the media is already ciphertext under a key the drive holds, changing that key renders the entire drive unreadable in seconds. Cryptographic erase is recognized as a sanitization method in NIST SP 800-88 Revision 1, and it is why SEDs are common in fleets where drives are returned under warranty or disposed of at scale.

The caution is worth stating plainly because it is a matter of public record. In 2018, researchers at Radboud University published flaws in the hardware encryption implementations of several widely sold consumer SSDs, tracked as CVE-2018-12037 and CVE-2018-12038, in which the user password was not cryptographically bound to the key protecting the data. Microsoft's response was to stop deferring to the drive: a September 2019 Windows update (KB4516071) changed BitLocker's default so that newly encrypted drives use software encryption, with hardware encryption available only if an administrator deliberately re-enables it by policy. The lesson generalizes beyond those specific drives. Hardware encryption is a firmware implementation, its quality varies by product line, and the way to have confidence in a particular one is an independent validation of the module rather than the presence of the feature on a datasheet.

What FIPS validation actually certifies

In federal work, "encrypted" and "encrypted with validated cryptography" are different claims. The Cryptographic Module Validation Program (CMVP), run jointly by NIST and the Canadian Centre for Cyber Security, tests cryptographic modules against FIPS 140 and issues a numbered certificate to those that pass. FIPS 140-3, which adopts ISO/IEC 19790 by reference, is the current standard and defines four ascending security levels: Level 1 requires approved algorithms with no specific physical protections, Level 2 adds tamper evidence and role-based authentication, Level 3 adds active tamper response that zeroizes keys, and Level 4 adds robust protection against environmental and physical attack.

Three details cause most of the confusion. First, a certificate covers a cryptographic module — a defined boundary of hardware, firmware, or software — not the whole product, so a drive or appliance is validated in respect of the component that performs the cryptography, at a named model and firmware version. Second, "FIPS compliant" is marketing language with no defined meaning, while "FIPS validated" corresponds to a certificate you can look up in CMVP's validated-modules list; asking for the certificate number is a reasonable request and the only way to verify the claim. Third, the transition currently in progress has a date on it: CMVP moves the remaining FIPS 140-2 certificates to its Historical list on September 21, 2026, after which agencies should not include those modules in new procurements, though nothing already deployed stops working and existing systems may continue to operate.

Where the requirement comes from

For controlled unclassified information, NIST SP 800-171 requires protecting the confidentiality of CUI at rest and, where cryptography is the mechanism used to protect confidentiality, employing FIPS-validated cryptography — requirements 3.13.16 and 3.13.11 in Revision 2, which remains the revision CMMC assessments benchmark against as of mid-2026. NIST SP 800-111 is the general reference for storage encryption on end-user devices and is the document most often cited when a requirement needs a technical basis rather than a product name.

In healthcare, encryption of electronic protected health information at rest is an addressable implementation specification under the HIPAA Security Rule. Addressable does not mean optional: it means an organization either implements the control or documents a reasoned, equivalent alternative, and in practice most implement it because the alternatives rarely survive scrutiny. There is a second incentive as well — under HHS guidance, protected health information rendered unusable, unreadable, or indecipherable to unauthorized individuals through methods the guidance recognizes is not treated as a breach requiring notification, which converts a lost laptop from a reportable event into an inventory problem. Similar reasoning appears in state breach-notification statutes, though the specific safe-harbor language varies and is worth reading rather than assuming.

What encryption at rest does not protect you from

A running system with the volume unlocked offers no protection to an attacker who is already authenticated on it. Full-disk encryption defends a powered-off machine and a removed drive; it does nothing against malware executing as a logged-in user, ransomware encrypting files a second time, or an administrator copying data out through a legitimate interface. The same holds one layer up: transparent database encryption protects the files, not the query. Any control that is transparent to authorized access is, by definition, transparent to a compromised authorized account.

Key management is where these programs actually succeed or fail. Keys have to be generated somewhere trustworthy, stored somewhere the encrypted data is not, rotated on a schedule, escrowed so that a departing administrator or a failed motherboard does not destroy the data along with the access, and destroyed deliberately at end of life. Recovery keys stored in the same directory as the systems they protect are a common and quiet failure. For estates where the key material itself needs hardware protection and an audit trail, a hardware security module is the usual answer, and for endpoints the TPM already fitted to the machine is the anchor most organizations underuse rather than lack.

What to specify when buying

Write down which layer the requirement is satisfied at before comparing products, because a specification that says only "data must be encrypted at rest" will be answered by four different things at four different prices. If a validated module is genuinely required, ask for the CMVP certificate number and confirm it names the model and firmware version you are buying rather than a sibling product or an earlier release. If cryptographic erase is part of the disposal plan, confirm the drive supports it and that the sanitization method is one your policy recognizes.

Then account for the operational surface that arrives with the control: where keys live, who can recover them, how a drive is unlocked in an unattended reboot, and what happens when a controller fails and an array has to be rebuilt on replacement hardware. Those questions have hardware consequences — TPM presence and version, drive families that carry the validated firmware, and the management software that has to be licensed alongside them — so they belong in the bill of materials rather than in the deployment runbook. Uniqcli quotes storage, endpoints, and the licensing that governs them through authorized US distribution; sending the requirement, not just the part numbers, is what lets the quote match the control you are actually being held to.

Key takeaways

Data-at-rest encryption protects stored bytes against possession of the medium — a stolen laptop, a decommissioned drive, a tape that never arrived — not against an attacker already authenticated on a running system.
It can sit at four layers: OS full-disk encryption, a self-encrypting drive's own controller, transparent database encryption, or the application. The layer determines what is actually protected.
Self-encrypting drives cost no host CPU, cover everything written by construction, and support cryptographic erase, which NIST SP 800-88 Rev. 1 recognizes as a sanitization method.
Hardware encryption quality varies by firmware: 2018 research (CVE-2018-12037/12038) led Microsoft to change BitLocker's default in KB4516071 so new drives use software encryption unless policy says otherwise.
"FIPS validated" means a CMVP certificate exists for a named module at a named firmware version; "FIPS compliant" means nothing. Remaining FIPS 140-2 certificates go Historical on September 21, 2026.
NIST SP 800-171 requires CUI at rest to be protected and FIPS-validated cryptography where cryptography is the protection; HIPAA treats encryption as addressable, meaning implement or justify an equivalent.

Shop it at Uniqcli

Samsung SSDs Seagate drives Storage arrays Get a quote

Frequently asked

What is the difference between encryption at rest and encryption in transit?: They protect different moments in a data item's life. Encryption in transit protects bytes while they move across a network — TLS on a web session, a site-to-site VPN, an encrypted replication link — and stops interception between two endpoints. Encryption at rest protects bytes while they sit on storage and stops anyone who obtains the medium from reading it. Neither substitutes for the other, and a third category, protection of data in use, covers memory while a process is actively working on it. Most compliance frameworks name at least the first two separately, so a control that satisfies one will not close a finding written against the other.
Is a self-encrypting drive better than software full-disk encryption?: Each wins on a different axis. A self-encrypting drive performs the work in its own controller, so there is no host CPU cost, encryption covers everything written with no way to provision an unprotected volume, and cryptographic erase makes disposal fast. Software encryption is auditable, portable across hardware, centrally manageable through familiar tooling, and independent of any one vendor's firmware quality — which matters, because the 2018 research into flawed SSD implementations is the reason BitLocker stopped defaulting to hardware encryption. Many organizations run software encryption as the standard and reserve validated SEDs for cases where cryptographic erase or CPU headroom genuinely drives the decision.
What does FIPS 140-3 validation actually mean for a drive or appliance?: It means the cryptographic module inside the product — a defined boundary of hardware, firmware, or software, not the whole product — was tested by an accredited laboratory and issued a numbered certificate by the Cryptographic Module Validation Program. The certificate names the module, the version, and the security level it met, from Level 1 (approved algorithms, no specific physical protection) to Level 4 (robust physical and environmental attack resistance). It does not certify the product as secure overall, and it says nothing about how the product is deployed. Ask for the certificate number and check that it covers the exact model and firmware you are being quoted.
What happens to FIPS 140-2 validated equipment we already own?: Nothing operationally. CMVP moves the remaining FIPS 140-2 certificates to its Historical list on September 21, 2026, and that change is not retroactive — deployed systems keep running and CMVP explicitly supports the continued use of those modules in existing systems. What changes is the evidence value going forward: the program's guidance is that federal agencies should not include Historical modules in new procurements, while agencies may make their own risk determination about continuing to use what they already have. The practical effect lands on the purchasing side rather than the operations side, which is why it is worth checking before a refresh rather than after.
Does encrypting data at rest protect us from ransomware?: Not meaningfully, and the assumption that it does is a common planning error. Ransomware runs as an authorized process on a running machine where the volume is already unlocked, so it reads your files exactly as any other program would and encrypts them a second time under its own key. Encryption at rest defends against possession of the medium, not against execution on the host. The controls that address ransomware are elsewhere: segmentation, endpoint detection, least privilege, and above all backups the attacker cannot alter — immutable copies with a retention lock the backup administrator's own credentials cannot revoke, plus tested restores.
Where should encryption keys be stored?: Anywhere other than alongside the data they protect, and ideally somewhere that enforces separation of duties. For endpoints, the Trusted Platform Module already fitted to most business-class machines is the intended anchor: it seals the volume key to the measured boot state so a drive moved to another machine stays unreadable. For servers, databases, and certificate authorities, a key-management system backed by a hardware security module is the usual pattern, because it keeps key material inside a validated boundary and produces the audit trail an assessor asks for. Whatever the mechanism, plan escrow and recovery deliberately — recovery keys saved into the same directory service they protect is the failure mode that shows up most often.

Keep reading

Symmetric vs asymmetric encryption What is a TPM chip?What is an HSM?The FIPS 140-2 sunset Data encryption and loss prevention

What Is Data-at-Rest Encryption? FDE, SEDs and FIPS