Encryption at rest is the protection of stored data by encrypting it, so a file sitting on a phone, laptop, USB stick or server is unreadable without the right key.
"At rest" just means "not moving." Your passport scan in a folder is at rest. The same scan attached to an email, flying across the internet, is "in transit." Security people care about the difference because the threats are different: someone intercepting a connection is one problem, someone picking up a lost phone or a stolen laptop is another.
A phone is where your insurance card, your lease and your tax return photos end up, and phones get lost. Encryption at rest is the lock on that drawer.
What encryption at rest is
NIST, the US standards agency, defines encryption as the transformation of readable data, called plaintext, into a form, called ciphertext, that conceals the data's original meaning to prevent it from being known or used. If the transformation is reversible, the reversal is called decryption. The key is what makes it reversible: no key, no reading.
NIST's guide to storage encryption on end user devices, SP 800-111, describes it as using encryption and authentication to restrict access to and use of stored information. It names three common approaches: full disk encryption, volume and virtual disk encryption, and file or folder encryption. The right choice, it says, depends mainly on the type of storage, how much information needs protecting, where the storage will be kept, and the threats you're trying to stop.
Apple's approach on iPhone is the file-level kind. Apple's security guide says Data Protection assigns each file to a class, and a file's accessibility depends on whether that class's keys have been unlocked. Each time a file is created on the data volume, Data Protection creates a new 256-bit key for it and hands it to a hardware encryption engine, which encrypts the file as it's written to flash storage.
What it looks like
Encryption at rest isn't a thing you see. It shows up in a few places, and the table below separates what it covers from what it doesn't.
| Situation | Covered by encryption at rest? | What to check |
|---|---|---|
| Phone lost or stolen while locked | Yes, that's the case it's designed for | Use a strong passcode and a short auto-lock |
| Phone handed over while unlocked | No | Short auto-lock; Face ID on sensitive apps |
| File emailed or uploaded | No (that's encryption in transit) | Use a secure link or an encrypted attachment |
| Laptop drive removed and read elsewhere | Yes, with full disk encryption on | Confirm it's turned on in system settings |
| Cloud backup or sync | Depends on the provider and the settings | Read the provider's description of what is encrypted |
| Paper printout | No | Shred it (shredding) |
The honest limit is the second row. Encryption at rest protects stored data from someone who has the device or the storage but not the key. It does nothing against someone who is already inside an unlocked session, or against a person you gave the file to.
What to keep and for how long
Encryption isn't a document, so there's nothing to file. What's worth keeping is the habit and a few facts.
- Your passcode and recovery info. If you lose the key, encrypted data may be gone for good. Store recovery details somewhere safe and separate, such as your digital emergency binder.
- An encrypted backup. Encryption doesn't replace one. See how to back up important documents.
- A note of where sensitive files live, and which apps protect them. How long to keep the documents themselves is a separate question: see document retention.
One tip worth knowing: some formats are built to be readable decades from now and ban encryption inside the file. PDF/A, the archival PDF standard, is one. The usual answer is to protect the storage, not the file.
Where Paperlock fits: its documents are stored encrypted on the phone using iOS Data Protection, and the app adds a Face ID or passcode lock on top. That's the same at-rest layer described above, plus a lock for the unlocked-phone case.