What encryption at rest actually protects you from

Encryption at rest is a stack applied at different depths, each with a different key holder and a different set of attackers it excludes. Every layer below field-level encryption shares one property: the storage layer hands plaintext to anything authorised to read, and the application is always authorised to read. Those layers are aimed at custody of physical media and at copies taken beneath the running system, which is a real risk and usually not the one you have.

Application-side envelope encryption is the first layer that changes what a database compromise means. The application encrypts the field with a data key, has a key service wrap that data key, and stores the wrapped key beside the ciphertext, so the store holds ciphertext and a key it cannot unwrap. An attacker with a full copy of the database, a valid credential or a backup file has bytes and nothing else.

It also converts decryption from an ambient capability into an event. Every decrypt becomes a call to a key service that authenticates the caller, can refuse, and writes a log line, which gives you a revocation point, an access record and a rate you can alarm on. A key service that normally issues a handful of unwraps a minute and suddenly issues thousands is visible in a way that a bulk read against an encrypted-at-rest database is not.

The primary datastore gets the attention and is rarely the weakest holder. The same records sit in nightly backups, storage snapshots, read replicas, a staging environment refreshed from production, an analytics warehouse, a search index, retained queue topics, a cache, and whatever the support tooling renders for staff. Each is a separate decision about encryption, key custody and retention, and in most systems none of them were decided at all. That list is the honest scope of the question when somebody asks whether your data is encrypted at rest.

Log stores are the most consistent offender. Fields carefully encrypted in the database turn up in plaintext in request logs, error payloads, third-party monitoring and stack traces carrying a serialised object. Encryption at rest on the log store does not help, because it decrypts for anyone authorised to search it, and that is a far broader group than the people who can query production. A field worth encrypting needs a redaction rule in the logging layer and a test asserting the value never appears, run against the real serialisation path instead of a hand-written example.

Field-level encryption carries one practical advantage here that gets ignored: the ciphertext travels. A value encrypted by the application arrives in the backup, the replica, the warehouse and the export already encrypted, because it was never plaintext outside the small part of the code holding the key. A control applied at the volume or inside the engine stops at that store's boundary, and the extract somebody generated last Tuesday carries none of it. It is also why the redaction rule still matters: the application is the one place the value is readable, and the logging call sits inside it.

Every layer above is defined less by its algorithm than by who holds the key and how that holder answers a decryption request. Implementations fail because the key sits beside the data it protects, or because it is held by a party whose default answer to a decryption request is yes, not because the cipher was broken. A platform-managed key gives you encryption at rest with no operational burden and no ability to revoke, because the provider generates it, rotates it on its own schedule, and decrypts transparently for any request the access policy permits.

A customer-managed key in a key service you control changes four things, and attacker resistance in the ordinary case is not among them. It gives you revocation, so withdrawing access renders the store unreadable once the caching window closes. It gives you an access record showing which principal asked for a decryption and when. It gives you destruction of the key as a deletion mechanism. It separates the party that stores your data from the party that authorises reading it, which is usually what a health or capital-markets buyer is asking about even when they phrase it as an encryption question.

You also gain a new way to have an outage. The key service becomes a hard dependency of the storage layer, a deleted or expired key version is an unrecoverable dataset, and a misconfigured key policy takes production down in a way that first looks like data loss. Holding the key outside the platform entirely gives the strongest separation and a key endpoint you have to keep highly available. Customer-managed keys are worth it when you need one of those four properties and can name which one, and where nobody can name it the platform key is the correct choice and the engineering effort belongs one layer up.

Field-level encryption is not everywhere because a properly encrypted column is opaque to the database. A randomised scheme produces different ciphertext for the same plaintext every time, which is the correct behaviour, and it means the column cannot be searched by partial match, range-queried, sorted, joined, usefully indexed or constrained unique. Every one of those capabilities has to be rebuilt elsewhere or deliberately given up.

Deterministic encryption is the first thing teams reach for. The same plaintext always produces the same ciphertext, so equality lookups, joins and grouping work directly on the ciphertext. The leak is equality itself, and equality on a low-cardinality column gets an attacker most of the way to the plaintext. A deterministically encrypted status, plan tier or diagnosis category is usually recoverable by counting, because the distribution across a few thousand rows compared against a known population distribution names the values without touching the cipher. It holds on a high-entropy identifier and falls over on a small value domain, so the cardinality of the column is the thing to check before choosing it.

A blind index is the controlled version of the same idea. Beside the randomised ciphertext you store a keyed hash of the normalised plaintext, index the hash, and search by hashing the term with the same key, which brings back exact-match lookup and uniqueness. It carries the equality leak plus one more: if the index key is exposed and the value domain is small and enumerable, which describes phone numbers, dates of birth and most government identifiers, an attacker computes the whole space offline and matches every row. The mitigation is to truncate the index to a few bits so that many plaintexts collide into each bucket, capping what it reveals and forcing the application to decrypt the bucket and filter. The bit width is a dial trading query cost against leakage, and it should be set against the size of the value domain.

Order-preserving and order-revealing schemes restore ranges and sorting, and they leak the ordering of every value, which for a balance, a salary or a score is close to leaking the value. Sorting and paging inside the application is the other answer, and it holds until the result set is too large to pull and decrypt inside a request, at which point the design has to change instead of stretch. Work out where that break point sits against a real row count before you encrypt the column, because finding it afterwards means a second migration.

Rotation is where the shape of the key hierarchy shows up. Rotating the key encryption key means unwrapping and rewrapping the data keys, a metadata operation over a small table that touches no ciphertext at all. Rotating a data key means decrypting and re-encrypting everything that key covers. Data key granularity therefore decides whether rotation is a background job or a migration, and per-tenant or per-subject keys are usually the right unit because they make revocation and deletion granular at the same time.

Every stored ciphertext has to carry the identity of the key and the algorithm that produced it. A bare ciphertext with no version header cannot be rotated incrementally, cannot move to a different cipher, and forces an all-at-once cutover the first time either becomes necessary. A small structured envelope holding a key identifier, a key version, an algorithm identifier, the nonce and the ciphertext costs a few bytes per record, and it is the most common omission in a first implementation because nothing depends on it until the day rotation does.

Key destruction is a deletion mechanism and often the only workable one, because immutable or offsite backups cannot be selectively edited to remove one person's records. Destroying a per-subject data key makes the ciphertext in every one of those copies unrecoverable, and the claim is only as strong as your certainty that no other copy of that key exists, so expect questions about in-memory caches, escrow copies and archived key backups. The opposite failure is worse: a backup encrypted with a key you no longer hold contains no recoverable data, and teams find that out mid-restore, so restore drills have to run against an archived key version rather than the current one. The key service is also an availability dependency in the request path, so most implementations cache unwrapped data keys for a short lifetime, and that cache is exactly the window in which a revoked key still works.

No Australian privacy obligation prescribes an encryption method. The Privacy Act requires reasonable steps in the circumstances to protect personal information from misuse, interference and loss, and from unauthorised access, modification and disclosure. What counts as reasonable scales with the sensitivity of the information, the volume held and the harm that would follow, so health and financial records sit at the top of that scale. The same Act requires personal information to be destroyed or de-identified once the organisation no longer needs it for any permitted purpose and no Australian law or court order requires it to be kept, and that is the obligation key destruction answers.

The Notifiable Data Breaches scheme is where the distinction between the layers matters most. A breach is notifiable when unauthorised access, unauthorised disclosure or loss is likely to result in serious harm to an affected individual, and the security measures protecting the information, together with how likely those measures are to be overcome, are among the matters the Act directs you to weigh. A lost backup drive encrypted with a key the finder does not hold is a materially different assessment from the same drive unencrypted. Remedial action taken quickly enough that serious harm is no longer likely can remove the obligation to notify, so revocation speed is worth measuring before you need it.

That benefit applies to one shape of incident. Where an attacker used a valid credential, a stolen session or an application flaw, the data was decrypted for them by design and the state of your encryption is not a factor in the assessment. Field-level encryption with a separate key custody path is the only version of this control that changes that answer, and only where the compromised path did not carry the decryption right with it. It is also worth knowing what the frameworks leave out: none of the eight mitigation strategies in the Essential Eight is an encryption control, so a maturity rating against it says nothing about how any of your data is stored.

The yes or no field on a vendor questionnaire is close to information-free, because on a managed platform the honest answer is yes and it required nothing of you. Reviewers who understand that are reading the free-text box for whether you know your own architecture. An answer naming the layer, the custody model and the decryption path is worth more than a longer one that repeats the word encryption.

The answer that fails says yes on the strength of a platform default while the surrounding narrative implies field-level encryption. An auditor reading the architecture finds that gap in an afternoon, and a reviewer who catches one overstated control re-tests every other answer on the form. Where the same claim has been carried into the security schedule of a contract, the overstatement becomes a representation the business has to stand behind. Naming the gap and the date it closes costs a follow-up question and nothing else.

We build and operate systems that hold this class of data. Aurii, our own clinical software venture, is Australian-hosted on Azure and carries tenant health data with tamper-evident audit trails. The operations and compliance portal we built and run for GRM LAW, a Brisbane law firm, holds matter and client intake data over an append-only audit ledger. In both, the storage-level encryption was the straightforward part, and the design work went into which identities can cause a decryption to occur and what record it leaves when they do.

Our secure code review and Azure security work finds the same three things in the same order: the platform encryption is on and configured correctly, the sensitive field is duplicated into a log store and an analytics copy that appeared on nobody's list, and the key custody model was never decided by anyone in particular. The fix almost never involves a stronger cipher, and it almost always involves an accounting of every copy of the data, a named owner for the key, and a decryption path that leaves a record somebody can read later. A questionnaire answer that covers the six points below survives the architecture review that follows it.