You could think about data-at-rest encryption a little like the OSI model we use for networks: a layered system where each tier plays a distinct role. You would not trust a network defended at only one layer, and storage is no different. Every layer has blind spots, but when those layers stack neatly on top of each other, they cover one another’s weaknesses. That is what turns ordinary encryption-at-rest into proper defence-in-depth.

Storage Encryption Layers

#

flowchart TB
    L0["0 - BIOS"]
    L1["1 - Drive Encryption"]
    L2["2 - RAID"]
    L3["3 - Volume(s)"]
    L4["4 - File System"]
    L5["5 - Application"]

    L0 --> L1 --> L2 --> L3 --> L4 --> L5

Detailed Breakdown

#

flowchart TB
    BIOS["BIOS
Ensures firmware integrity and a measured or secure boot path.

Examples: UEFI Secure Boot, TPM measured boot.

Strength: helps prevent early-boot tampering and enforces a trusted boot chain."]
    Drive["Drive
Provides full-disk or hardware-based encryption for physical drives.

Examples: BitLocker, LUKS, self-encrypting drives.

Strength: strong protection for lost or stolen drives, with transparent boot after unlock."]
    RAID["RAID
Encrypts at the controller or array level across multiple disks.

Example: controller-level RAID encryption.

Strength: protects data spread across disks and can remain transparent to the operating system."]
    Volumes["Volume(s)
Encrypts logical volumes or containers rather than raw disks.

Examples: VeraCrypt volumes, LVM with dm-crypt.

Strength: flexible targeting of specific volumes while remaining transparent to applications."]
    FileSystem["File System
Encrypts individual files or directories on the file system.

Examples: EFS on Windows, GnuPG, age.

Strength: offers granular control, per-file sharing, and key separation."]
    Application["Application
Encrypts sensitive fields, columns, or entire tables inside the application or database.

Examples: SQL Server TDE, MongoDB FLE, application-level cryptography.

Strength: protects data even if backups or disks are exposed, and supports granular access control."]

    BIOS --> Drive --> RAID --> Volumes --> FileSystem --> Application

Extended Considerations

#

Beyond the layers shown above, consider cloud object and blob storage encryption. Cloud providers often encrypt objects at rest, such as with S3 SSE or Azure Storage Service Encryption. Customers can usually bring their own keys (BYOK) for stronger control and clearer separation of duties.

Backups, snapshots, and archival media need their own encryption and key management, especially when they are held offsite or by third parties. They are often the forgotten copy of your production data, which makes them a particularly tempting target.

Swap and page files deserve attention too. Encrypt swap space, or use memory encryption features where they are available, to reduce the chance of sensitive data being written from RAM to disk in plain text.

Key management is where many otherwise sensible encryption designs fail. Use a dedicated KMS or HSM where appropriate, enforce least privilege, rotate keys deliberately, and audit access carefully.

Access controls and secrets management should sit alongside encryption rather than behind it. Strong IAM, managed secrets, and audit logging reduce the exposed attack surface and make misuse easier to spot.

Keys

#

There is little point in encrypting data if the keys that provide access to it live in the same system with the same trust boundary. Sometimes that is unavoidable, but it should be a conscious decision rather than an accident. Always consider the key-handling options available to you, and remember that if you lose the keys, it is unlikely you will get the data back. This is a large topic in its own right, but at minimum, make sure you have encrypted backups and a key-management process you trust.

Conclusion

#

Storage encryption is not just “turning on BitLocker”. Like the OSI model, each layer addresses different threats. By combining multiple layers with solid key management and access controls, you build a more resilient defence for data at rest.