Fundamentals

Encryption at Rest: What It Protects and Why Keys Matter

By Daniel Sardá · Published on October 22, 2026

6 min read1,240 words

Encryption at rest reduces the risk of stored data being exposed, but its protection depends on the chosen layer, the system's state, and who controls the keys.

A laptop is lost at an airport. A backup is exposed on a server. A hard drive is removed from a computer and connected to another machine. In all three cases, the problem is not that information is traveling across the internet: it is stored somewhere. Encryption at rest aims to ensure that data cannot be understood without the appropriate key.

It is an important safeguard, but not a promise of invulnerability. It can protect very effectively against the loss of a device while still failing to stop a compromised but authorized account from viewing information. Understanding that difference requires looking at three elements: the state of the data, where encryption is applied, and who controls the keys.

What it means for data to be “at rest”

Data is at rest when it remains stored and is not being actively transmitted between systems. It may sit on a laptop drive, in a database, on external storage, in a file, or in a backup.

Encryption turns that content into a representation that is unreadable to anyone without the necessary cryptographic material. NIST’s storage encryption guidance presents it as a measure for restricting access to stored information, especially when a storage medium is lost, stolen, or directly accessed.

Consider a laptop that is powered off and properly encrypted. Someone who removes its drive should not be able to read its documents as ordinary files. But if the device is found powered on, unlocked, and running an active session, the situation changes: the system may already be using the key and displaying decrypted data.

Key idea: Encryption at rest protects stored content against specific threats; it does not make an entire system secure in every circumstance.

At rest, in transit, and in use: three different moments

The same information changes state in everyday use. A file is at rest when it is stored; in transit when it travels across a network; and in use when an application processes it or a person consults it.

Each state requires different controls. Encrypting a disk does not by itself protect a file as it crosses an insecure network. Encrypting a connection does not prevent someone from reading a drive removed from a powered-off machine. And both protections can be bypassed if an attacker controls a legitimate session in which the data is already displayed in decrypted form.

That is why encryption is best understood as part of an architecture of privacy and digital security, not as an isolated solution. Authentication verifies an identity; authorization determines what that identity may do; integrity controls help detect changes; and backups make recovery possible. These functions are related, but they are not interchangeable.

The encryption layer should match the risk

Encryption can be applied at different layers. The useful starting point is not to ask which technology is the most sophisticated, but which threat needs to be reduced.

• Device or full-disk encryption: protects physical storage, for example if a powered-off laptop is stolen.
• Volume or file-system encryption: confines protection to part of the storage and can separate environments with different needs.
• Database encryption: protects structured information and may be applied to the whole database or to specific fields.
• File or application encryption: makes it possible to encrypt particular data before storage and, depending on the design, retain more control over when it is decrypted.

OWASP’s Cryptographic Storage Cheat Sheet stresses that the appropriate layer depends on the threat model. Hardware encryption may help against physical theft but not necessarily against a remote intrusion into a running server. Encrypting within the application can provide more precise separation, though it demands more careful key management.

There is not always one correct layer. Defense in depth can combine several, provided each has a defined purpose and accumulation is not mistaken for automatic security.

Keys are central to protection

Encrypted data and a key serve different roles: one holds the protected information; the other makes it possible to recover it. If both are exposed together under the same permissions, much of the advantage disappears.

Key management includes generating, storing, distributing, rotating, retiring, and recovering keys. NIST’s key-management guidance addresses that life cycle because security does not depend only on applying a cryptographic operation. It also depends on who can invoke a key, under what conditions, and with what record of that use.

Keeping keys separate from data reduces the chance that a single exposure gives someone everything needed to read the information. But that separation has limits: if a compromised application retains permission to request decryption, an attacker may use it without extracting the key.

The opposite risk also exists. If the only key is lost and there is no protected recovery mechanism, the data may become inaccessible even to its owner. Responsible custody must prevent improper access without turning an operational failure into a permanent loss.

Key idea: The decisive question is not only “Is it encrypted?” but “Who can decrypt it, when, and through which controls?”

What encryption does not solve

Three misunderstandings are especially common.

First, encryption is not the same as access control. Encryption makes content unreadable without the key; authorization decides whether a user or service may request it. A compromised account may query an encrypted database if it retains effective permission to receive decrypted results.

Second, encryption does not guarantee integrity. Not every encryption mechanism detects that a file has been altered. Confidentiality—preventing improper reading—and integrity—detecting modification—are different properties.

Third, encryption is not a substitute for backups. It does not recover files that have been deleted, damaged, or held hostage by an attack. A backup can restore them, while encryption reduces their exposure. Moreover, an encrypted backup depends on its keys being kept securely and recoverably.

Encryption should not be confused with anonymity, authentication, or secure deletion either. It may support privacy, but it does not by itself demonstrate that a system complies with a rule or that the data subject has exclusive control over their information.

How to assess a solution without getting lost in the technical details

Before comparing products or algorithms, a few simple questions reveal a great deal about the real protection:

• What data is encrypted, and in which states does it fall outside that coverage?
• Does the chosen layer address physical theft, storage exposure, or another defined threat?
• Who controls the keys: the user, an organization, a provider, or several parties?
• What happens when a device is unlocked or an authorized account is compromised?
• Are there protected processes for rotation, recovery, and key backups?
• What complementary controls protect access, integrity, availability, and activity records?

These questions also clarify an institutional dimension. Owning the server or paying for the service does not necessarily mean controlling decryption. Autonomy over information depends on verifiable rules for custody, permissions, and accountability, as well as on formal ownership.

Key idea: Encryption’s value is measured against a defined risk and within a system of controls, not by the mere presence of an “encrypted data” label.

Encryption at rest is a specific barrier: it makes it harder for an exposed drive, file, or database to reveal its contents. Its reach ends where other problems begin, such as an open session, compromised credentials, undetected alterations, or the loss of the only key. Mature protection acknowledges those limits. It encrypts what should be encrypted, keeps keys under clear rules, and completes the defense with access controls, integrity safeguards, recovery, and oversight.