Encryption at rest answers fewer questions than you think

What platform encryption actually covers

Turn on encryption at rest for a managed database and something specific happens: the storage volume is encrypted with a key the platform manages, and the data is decrypted transparently whenever the database engine reads it.

The threat this addresses is well defined and real. If a physical disk leaves the data centre, if a storage volume is decommissioned improperly, if a backup file is copied to somewhere it should not be, the data on it is not readable. Media handling has historically been a genuine source of breaches, and this control closes it cheaply.

What it does not do follows from how it works. Because the engine must be able to read the data on every query, the key is available to the engine at all times. Any party who can make the engine execute a query—a compromised application, a stolen database credential, an over-broad support role, an administrator—receives plaintext. The encryption is not bypassed in these cases; it is simply not relevant to them.

The threats that remain open

Set the common compromise scenarios against what platform encryption at rest covers:

The pattern is clear: encryption at rest covers the data when it is not being used and covers nothing about who may use it. Almost every incident that organisations actually experience falls into the uncovered rows, because attackers use the authorised query path rather than the disk.

This is not an argument against the control. It is an argument against letting it stand in for a data-protection strategy, which is what happens when “is the data encrypted?” is the only question asked.

Match the layer to the compromise

Different encryption layers address different rows in that table, and the choice should be driven by which row you are worried about.

• Storage-level encryption addresses media loss. Enable it; expect nothing more.
• Transport encryption addresses network observation and interception. Also table stakes, and separate.
• Application-level field encryption, with keys held in a key service the database cannot reach, addresses a compromised database, a leaked database credential, an over-broad database role and most support-tooling exposure. It does not address a compromised application, because the application must decrypt.
• Encryption with keys held in a hardware module and per-operation authorisation narrows a compromised application to online use and produces an audit record of every decryption, which changes detection and forensics materially.
• Client-held keys, where the server never possesses plaintext or key, address server compromise entirely and remove the server’s ability to process the data at all. HPKE is the standard construction where the recipient holds the private key.

The trade increases in both directions: each layer addresses more scenarios and removes more capability from the server. There is no configuration that protects against everything and still lets you run a reporting query.

Customer-managed keys are a governance control

Customer-managed keys occupy a specific and often misunderstood position. When a customer supplies and controls the key-encryption key, they gain two real things: an audit trail showing when the provider’s services used the key, and the ability to revoke access by disabling it.

What they do not gain is protection while the workload is running. The provider’s service, having been granted use of the key, decrypts the data in order to serve it. A customer who believes the arrangement prevents provider-side access has misread the guarantee.

The honest framing is that customer-managed keys shift a governance property rather than a cryptographic one: key use becomes observable and revocable by the data owner. That is genuinely valuable for contractual assurance and for the ability to terminate access on demand, and both are worth the operational cost in the right context. Describing it as protection against the provider is not accurate, and it tends to be discovered during a due-diligence conversation.

NIST SP 800-57 is useful here because it forces the question of who holds and who may use each key at each stage of its life. Answering it for a customer-managed arrangement makes the actual boundary visible. Where a validated module is part of the assurance argument, FIPS 140-3 defines what the module itself guarantees—which is about key extraction, not about authorised use.

Encrypt fields, not databases

Application-level encryption applied to an entire database is usually impractical, because it breaks every query, index and aggregation. Applied to selected fields, it is both practical and considerably more useful than the whole-database version would have been.

The selection is the work. Identify the fields whose exposure would be individually serious—government identifiers, health details, financial account numbers, authentication secrets, free-text notes that tend to accumulate sensitive content—and encrypt those with keys the database cannot reach.

Then accept the consequences deliberately. An encrypted field cannot be searched by equality unless you add a deterministic index, which leaks equality. It cannot be range-queried. It cannot be used in a join. Reporting over it requires either a separate pipeline that holds the key or an aggregate computed at write time. Each of these is a design decision, and making them consciously for ten fields is far better than avoiding them for a thousand.

The same reasoning drives the arrangement NIST’s zero trust architecture describes: protection attaches to the resource and the per-request decision rather than to the location the data sits in.

The questions a regulator tends to ask

Data-protection supervision has moved past asking whether data is encrypted. The questions now tend to be about proportionality and about what the measure achieves: which risk was identified, which measure was chosen, why it is appropriate to that risk, and who can access the data in practice.

The UK regulator’s risk toolkit illustrates the structure, working from identified risks to the controls that address them rather than from a control list. A documented statement that platform encryption covers media handling, that field-level encryption covers database compromise, and that a named residual risk is accepted with a compensating control, is a far stronger position than an assertion that everything is encrypted.

The difference matters most after an incident, when the question becomes what the organisation understood about its own exposure beforehand.

A short way to audit your own claim

Take a sensitive table and trace the key. For each layer of encryption, write down where the key is, which components hold or can request it, and therefore which of the scenarios in the earlier table the layer covers.

Then find the exceptions. The analytics replica that was created with a different configuration. The backup copy in another region. The support tool with a read-only role over everything. The log line that contains the field body. The staging environment populated from production. In practice most data reaches one of these, and the weakest path determines the real protection.

The exercise usually takes an afternoon and its output is a single honest sentence about what your encryption achieves. That sentence is more valuable than the configuration itself, because it tells you what to build next.