What Is Data Encryption at Rest?

Encryption at rest is the most widely deployed and most widely misunderstood security control in use. Nearly every organisation has it, nearly every compliance regime accepts it, and in its default form it defends against a threat that almost never occurs.

The threat it addresses is physical: someone obtaining the storage media. Against a compromised credential, an over-permissive role or a misconfigured storage container — which is how data actually leaves organisations — default encryption at rest provides no protection, because the platform decrypts transparently for anyone authorised to read.

The layers, and what each one covers

Full-disk encryption protects a powered-off device. It is genuinely valuable for laptops and portable media, where loss and theft are real and common. On a running server it protects almost nothing, because the disk is unlocked.

Database or storage-level encryption is transparent to the application and protects the files underneath. Any authorised query still returns plaintext, so it defends against access to the storage layer rather than against misuse of the database.

Field or application-level encryption encrypts specific values before storage, so the database never holds plaintext. It provides genuine protection against database compromise and costs real functionality — you generally cannot search, sort or index encrypted fields normally.

Making it mean something

The decisive variable is key control. When using the key is a distinct permission from reading the data, administered by different people and logged separately, a stolen data-layer credential is no longer sufficient and unusual decryption volume becomes a detection signal.

For most organisations the sensible position is full-disk everywhere as a baseline, storage-level encryption with customer-managed keys for production data, and field-level encryption reserved for the small number of values — identifiers, payment data, particularly sensitive health fields — where the functional cost is justified.

What it does and does not satisfy

Compliance regimes generally accept encryption at rest in its default form, which is why it is so widely deployed and why it is so often mistaken for meaningful protection. Meeting the requirement is a configuration setting; reducing the risk is a key management project.

It does provide one genuine and frequently overlooked benefit: secure disposal. Destroying the key renders the data unreadable without physically wiping the media, which matters for cloud storage you cannot physically access and for devices leaving the organisation.

That property makes encryption at rest a retention and disposal control as much as a confidentiality one — and crypto-erasure is frequently the only practical way to demonstrate destruction of data held by a third party.

Worth confirming separately: whether encryption is actually enabled on every store rather than on the ones anyone checked. Default-on varies by service and by region, and older resources frequently predate the policy that would have enforced it.

Where to start

Check whether your backups are encrypted with the same rigour as the production data, and who can restore them. A restore permission is a read permission on everything, and it frequently sits outside the access reviews that cover the live system.

See encryption everywhere. GuardsArm runs security risk assessments.