Visit Website →
← Back to blog

Data Encryption at Rest: Choose the Layer, Then Secure the Keys

October 17, 2026
Data Encryption at Rest: Choose the Layer, Then Secure the Keys

Data encryption at rest means stored data is encoded so it is unreadable without the encryption key, which prevents disclosure if storage media or backups are stolen. OWASP and NIST both treat it as a baseline control, and our team at AccountNext-Nexus builds it into the managed environments we run. The hard part is not turning it on. It is choosing the right layer and protecting the keys.

TL;DR:

  • Volume encryption protects stolen devices and backups, but it cannot stop authorized sessions or attackers using valid credentials from seeing plaintext.
  • Use volume encryption against physical theft, database encryption for files and backups, and application level encryption when storage administrators must not read selected fields.
  • Use AES with a 256 bit key in GCM or CCM; generate keys and nonces securely, and never reuse a nonce with the same key.
  • Keep data encryption keys separate from stored data by wrapping them with keys held in a KMS or HSM; wrapper key rotation avoids reencrypting stores.
  • Before launch, load test encryption and rehearse restoring an encrypted backup; retain rotation records, access logs, and configuration evidence for audits.
AccountNext-Nexus
Bring Encryption Into a Unified Security Plan
Nexus brings cybersecurity, IT management, and compliance together, helping organizations manage stored data protection within a unified environment.
Explore Nexus security services

Table of Contents

What does data encryption at rest cover, and which threats does it stop?

Encryption at rest protects data that sits in storage rather than data moving across a network or being processed in memory. In practice, that scope is wider than most teams first assume. A realistic inventory includes:

  • Disks and volumes attached to servers, laptops and virtual machines
  • Object storage buckets and file shares
  • Snapshots and backups, including offsite and archived copies
  • Database files, transaction logs and temporary tables
  • Application storage such as uploaded documents, caches and exports

The threats it addresses are the ones where an attacker gets the bytes but not the keys. A stolen laptop, a decommissioned drive that was never wiped properly, a backup tape that leaves the building, or a snapshot copied to the wrong account all become much less damaging when the contents are ciphertext. It also reduces the risk from media remanence, where deleted data can still be recovered from physical storage.

The limits matter just as much. Encryption does not stop an authorised user, or an attacker holding that user's credentials, from reading plaintext through the application. If the keys are compromised, the protection collapses. And if keys live next to the data, one breach can expose both. OWASP's cryptographic storage guidance is blunt on this point: keep keys in a location separate from the data they encrypt, ideally a dedicated key management system, so that an attacker who reaches the database or storage does not automatically reach the keys.

Cloud providers reinforce the same model. Their documentation generally describes default or opt-in encryption of storage services, with keys held in a separate managed service. That arrangement is what makes encryption at rest meaningful, rather than a checkbox. Treat it as one control in a stack, aimed at a specific class of threat, and you will set expectations correctly with auditors and executives alike.

Privacy-sensitive data deserves extra attention when you scope this work. Identity and biometric records, for example, carry harm that cannot be undone by resetting a password, and operational controls around them are worth reading about in this partner analysis of biometric breach prevention.

Where should you apply encryption: application, database, filesystem or hardware?

Encryption can be applied at several layers, and each one answers a different threat model. Work through them in this order when deciding what you need.

  1. Application-level encryption. Your code encrypts fields or documents before they ever reach the database or file store. This gives the strongest protection against a database compromise or a curious administrator, because the storage tier only ever sees ciphertext. The cost is development effort: you own key handling, you lose easy server-side searching and sorting on encrypted fields, and mistakes are yours to make.
  2. Database-level encryption, often called Transparent Data Encryption (TDE). The database engine encrypts data files, logs and backups without application changes. It is the quickest way to cover a large estate and it protects against stolen files and backups. It does little against a privileged database user, since the engine decrypts data for any authorised session. Microsoft's documentation on TDE and filesystem-level tools such as BitLocker describes both controls and discusses combining them as defence in depth, along with performance considerations.
  3. Filesystem and device encryption. Tools such as BitLocker on Windows and LUKS on Linux encrypt whole volumes. This defends against physical theft of a machine or disk and is nearly invisible to applications. Once the volume is unlocked and mounted, though, any process with file access reads plaintext.
  4. Hardware protections. Self-encrypting SSDs add device-level safeguards, and hardware security modules (HSMs) protect the keys themselves inside tamper-resistant hardware. Drive-level encryption alone is a weak choice when the drive's key handling is opaque, so pair it with a layer you control.
  5. A combination of the above. No single layer covers every threat. A common pattern is volume encryption everywhere, TDE for databases, and application-level encryption for the few fields whose exposure would be severe.

The ACM SIGMOD overview of database encryption frames the underlying design question well: where encryption happens, how finely it is applied, and where keys are stored all trade security against performance and complexity. Start from your threat model, not from the product that is easiest to enable.

Which algorithms and modes should you use for stored data?

Algorithm choice is the part of this topic with the clearest answers, so follow them rather than inventing your own. NIST's cryptographic publications, including guidance on transitioning algorithms and key lengths, are the reference point for acceptable algorithms and key sizes, and they apply directly to long-term storage.

  • AES-256 is the default for data you expect to keep for years. AES-128 remains acceptable in many legacy contexts, but there is little reason to choose it for new systems when the cost difference is small.
  • Use authenticated modes such as AES-GCM or AES-CCM. These provide integrity and authenticity as well as confidentiality, so tampering with stored ciphertext is detected rather than silently producing garbage or, worse, attacker-influenced plaintext. Unauthenticated modes should not be used for new designs.
  • Use elliptic-curve cryptography for key wrapping where it fits. If you use RSA instead, choose at least 2048 bits with OAEP padding, and avoid older padding schemes.
  • Generate keys and nonces from a cryptographically secure random source. Never derive keys from predictable values or reuse an IV or nonce with the same key. In GCM, nonce reuse under one key is a serious failure that can expose plaintext and break authentication.

NIST is the authority on which algorithms and key sizes are acceptable, so check its publications rather than relying on vendor marketing or forum advice.

A practical habit: wrap your cryptography in a single, well-reviewed library or service, and ban direct use of low-level primitives elsewhere in the codebase. Most real-world encryption failures come from misuse of sound algorithms, not from weak ones.

How do you manage keys: envelope encryption, KMS, HSM and rotation?

Key management is where encryption at rest succeeds or fails. The standard pattern is envelope encryption, built on two kinds of keys.

  • A data encryption key (DEK) encrypts the actual data. It is often generated per object, per file or per database, which limits the damage if one is exposed.
  • A key encryption key (KEK) encrypts the DEKs. The encrypted DEK is stored alongside the data, while the KEK stays in a key management system or HSM.

This design pays off in several ways. Rotating a KEK means re-wrapping small keys rather than re-encrypting terabytes. Access to the KEK can be audited and restricted separately from access to the data. And a stolen copy of the data is useless without a call to the key service. This is the separation that OWASP's cryptographic storage guidance recommends: keys kept apart from the data, with central key management where possible.

Choosing between a managed KMS, a virtual HSM and a dedicated HSM is mostly a trade-off between cost, control and compliance:

  • Managed KMS: the lowest effort and cost, integrated with cloud services, with the provider operating the underlying hardware. Suits most workloads.
  • Virtual or cloud HSM: stronger isolation and customer-controlled key material, at a higher price and with more operational responsibility.
  • Dedicated HSM: maximum control and the clearest story for strict compliance regimes, but the highest cost and the most operational work, including procurement, firmware and redundancy.

Whichever you choose, certain operational controls are not optional:

  • Automated key rotation on a defined schedule, since OWASP notes that organisations frequently fail to rotate keys and recommends automation to limit exposure when a key version is compromised
  • Tight access policies that separate who can administer keys from who can use them
  • Audit logging of every key operation
  • Secure, tested backups of key material, because losing a key means losing the data permanently

For deeper operational detail, our guide on audit-ready encryption key management walks through rotation and policy practices, and our piece on cloud secrets management covers vault patterns and keeping secrets away from data.

What operational practices make encryption at rest effective and auditable?

Encryption without policy is a configuration that someone will eventually turn off. These practices turn it into a control you can rely on and prove.

  • Start from data classification. Decide which data classes must be encrypted and at which layer, then make encryption the default for new storage. A rule like "every new volume, bucket and database is encrypted at creation" removes the need to remember.
  • Apply least privilege and role separation. The people who administer keys should not be the same people who administer the data stores, and applications should hold only the permissions they need. Prefer short-lived credentials to long-lived secrets wherever your platform supports them.
  • Monitor key use. Alert on unusual decryption volume, key access from unexpected locations or identities, disabled keys, and changes to key policies. A sudden spike in decrypt calls is often the earliest visible sign of data theft. Our guide to logging in cloud security covers how to collect and use that telemetry.
  • Keep evidence. Retain configuration exports, key policies, rotation records and access logs so you can show an auditor what was in place and when.
  • Know what encryption does for compliance. Frameworks such as PCI DSS, HIPAA and SOC 2 expect protection of stored sensitive data, and encryption at rest with sound key management is a common way to meet that expectation. It is a supporting control, not a guarantee of compliance, and requirements differ by framework and situation, so confirm specifics with your assessor or counsel. For healthcare settings, see our notes on patient data encryption and HIPAA audit readiness.

What does encryption at rest cost in performance and money?

Encryption has a price, but on modern systems it is usually modest and predictable if you plan for it.

Overhead shows up in a few places. CPU time rises for encrypting and decrypting data, I/O can grow when encrypted payloads are larger, and searching or indexing encrypted fields becomes harder, since you cannot sort or range-scan ciphertext the way you can plaintext. The ACM overview of database encryption lists performance trade-offs among the central design challenges, and the Microsoft documentation likewise discusses performance considerations for TDE and volume encryption.

You face a real choice between encrypting selectively and encrypting everything by default. Always-on encryption is simpler to govern and leaves no gaps, while field-level encryption concentrates cost and effort on the data that matters most. Many teams use both: default volume or database encryption for coverage, plus application-level encryption for a short list of high-risk fields.

Practical mitigations include:

  • Use hardware acceleration for AES, which current server processors support
  • Cache decrypted data carefully in memory where policy allows, rather than decrypting repeatedly
  • Encrypt only sensitive fields, not entire records, when the rest is low risk
  • Use blind indexes or tokenisation to allow lookups on encrypted values without exposing them

Budget for money as well as milliseconds. Managed KMS charges typically accrue per key and per API call, HSMs involve rental or purchase and specialist operation, and monitoring adds storage and staff time. Run a load test with encryption enabled before launch, not after.

How does encryption at rest differ from encryption in transit and in use?

The three states of data call for three different controls, and each one covers a gap the others leave open.

Encryption at rest protects stored data, as covered above. Encryption in transit protects data moving between systems, typically through TLS on API calls, database connections and replication links, so that someone on the network path cannot read or alter it. Encryption in use protects data while it is being processed, when it must exist in plaintext in memory. Approaches here include confidential computing with hardware-isolated environments, and they are still maturing for many workloads.

Three encryption states and their protection targets

Consider what each one stops. A database backup copied to a drive is a job for encryption at rest. An API request carrying customer records across the internet needs encryption in transit. A memory dump taken from a compromised host is the territory of encryption in use, and of access controls that limit who can reach the host at all.

Teams get into trouble by assuming one control implies another. A fully encrypted disk does nothing for traffic sent over plain HTTP, and TLS offers no protection for a stolen backup. The controls also interact: data is decrypted at the boundary of each state, so the keys and permissions at those handoffs become the weak points. Design for all three states, then check the transitions between them.

How do you deploy encryption at rest, step by step?

Use this ordered checklist to turn the guidance above into a plan.

  1. Classify your data and decide what must be encrypted first. Start with regulated data and anything whose exposure would cause serious harm.
  2. Inventory storage locations, including backups, snapshots, logs and exports that are easy to forget.
  3. Choose your layers based on your threat model, and decide between managed KMS, virtual HSM or dedicated HSM for key custody.
  4. Design key hierarchy and rotation: DEKs and KEKs, rotation schedules, and who may administer versus use each key.
  5. Enable encryption by default for new storage so that gaps do not reappear.
  6. Turn on logging and alerting for key operations and unusual decryption activity.
  7. Test performance and recovery. Load test with encryption enabled, then restore from an encrypted backup using only your written procedure.
  8. Document policies and keep evidence for audits, including configurations, rotation records and access reviews.

Small teams can get most of the value quickly: enable default encryption on cloud storage and databases, use a managed KMS, automate rotation, and turn on key-use logging. Larger organisations should add application-level encryption for the most sensitive fields, formal key custody roles and regular recovery drills.

Our view: why managed, unified security operations make encryption easier

Most encryption failures we see are operational, not cryptographic. The algorithm is fine. The key was never rotated, the alert nobody watches never fired, or the backup was excluded from the policy. Those are problems of ownership, and ownership gets harder as tools and providers multiply.

That is why we favour a unified managed approach. When key management, continuous monitoring and compliance support sit with one team, an anomaly in key use reaches someone who can act on it, rather than bouncing between a cloud team, a security vendor and an auditor. Our team works with managed key management services and HSM integration, monitors continuously, and supports compliance readiness for frameworks such as SOC 2, HIPAA and PCI DSS. We also keep pricing transparent, which helps when encryption costs have to be justified.

The contrarian point is this: stronger algorithms are rarely your best investment. Once you are on AES with an authenticated mode, the returns come from rotation discipline, key separation and monitoring. If you are unsure where your own encryption posture stands, review those three areas first.

How can we help you manage keys and encrypt stored data?

AccountNext-Nexus

If you would rather not run key management, rotation and monitoring yourself, we can do it with you. Our team handles managed key management and HSM integration, continuous monitoring of key and access activity, and compliance readiness work for stored data, with predictable monthly pricing. You get seasoned IT professionals and a single point of accountability instead of a patchwork of vendors. Current prices are on our pricing page.

The practical next step is an encryption readiness assessment: we review where your data sits, which layers protect it, and how your keys are handled. Browse our cybersecurity and managed services to see what we cover, then contact us to book the assessment.

FAQ

How is data encrypted at rest?

Data is encrypted at rest by running it through a cryptographic algorithm, usually AES, with a secret key before it is written to storage. The encryption can happen in the application, the database engine, the filesystem or the storage hardware. The key is kept separately, typically in a key management system.

What is the best encryption for data at rest?

AES-256 in an authenticated mode such as GCM is the usual choice for long-term storage, and NIST's cryptographic guidance is the reference for acceptable algorithms and key sizes. Strong key management matters as much as the algorithm.

What type of encryption is usually used with data at rest?

Symmetric encryption, most often AES, encrypts the data itself because it is fast on large volumes. Asymmetric methods such as RSA or elliptic-curve cryptography are typically used to wrap and protect the symmetric keys.

What are the three levels of encryption for data at rest?

People usually mean application-level, database-level and filesystem or device-level encryption. Each protects against different threats, and many organisations combine them. Hardware modules for key protection sit underneath all three.

Sources

Authoritative standards and vendor documentation to consult

These are the references we return to when planning or reviewing encryption at rest. Start with OWASP's cryptographic storage guidance for practical rules on key separation and rotation, then use NIST's cryptographic publications to confirm algorithm and key size choices. The ACM SIGMOD overview of database encryption explains the design trade-offs behind the layers, and Microsoft's TDE and BitLocker documentation shows how those controls work together. Also read your own cloud provider's encryption documentation for service-specific defaults and limits.