Encryption at rest

NIST SP 800-111 frames storage encryption as the control for data residing on a device. The same idea applies to a server volume or an object store. The file is not moving. The threat is someone who gets the media later.

This does not encrypt the upload. A client can send a file over plain FTP, and the server can encrypt it on write. The path was exposed. The disk is not. The reverse is common too: TLS on the way in, plaintext on the volume. Questionnaires that ask for one control and accept the other are mixing phases. Encryption in transit covers the session. At rest covers the stored object.

Who holds the key changes the claim. Server-side encryption with a key the provider manages stops a stolen disk from being useful. It does not stop the provider, or anyone with that key, from reading the file. Client-side or zero-knowledge encryption encrypts before the upload, so the store holds ciphertext it cannot open. SP 800-57 is the key-management text behind either design: generation, rotation, and retirement decide whether the stored ciphertext stays protected after a leak or a staff change.

A transfer service stores a 15 GB project archive in a bucket with server-side AES-256 and a provider-managed key. A laptop with a synced copy of the same archive has full-disk encryption, the case SP 800-111 actually addresses. An attacker who images the bucket disks gets ciphertext. An attacker who phishes the service admin gets the object through the API, because the service decrypts for an authorized call. At-rest encryption did not fail. It was never a control on the admin path.

Turning the feature on is not a rotation policy. A key created in 2022 and never retired still decrypts every archive it wrapped. Managed file transfer products advertise both at-rest and in-transit options because auditors ask for both rows, not because they are the same switch.