Two different states, two different threats
Encryption at rest describes stored data while the vault is locked. It is the property most people mean when they say a vault is encrypted, and it is genuinely valuable — it is what protects a lost or seized device.
The moment you unlock, that property stops describing your situation. The app must decrypt enough to display the content, so the relevant risks become the screen, the running process, and whatever else the device is doing.
What no storage design can do
A strong at-rest design cannot make a photo unreadable to the person looking at the screen. That is not a flaw; it is what displaying a photo means.
It follows that compromised operating systems, accessibility-service abuse, screen recording, a camera pointed at the display, and deliberate exports all sit outside the boundary that encryption defines. No cipher addresses any of them.
Session length is the control you actually hold
Since the unlocked window is where the exposure lives, the practical lever is making that window short. Automatic locking on backgrounding, on screen-off, and after a timeout each reduce the time an unattended device can retain an open vault.
Short sessions reduce the time that visible or temporarily decrypted content is exposed. Stored files can remain encrypted while the vault is open; session controls address the additional exposure created by viewing and processing them.
Practical handling while unlocked
- Keep sessions short and leave automatic locking enabled.
- Avoid unlocking in physical environments where the screen is observable.
- Review screenshot, screen-recording, and app-switcher preview protections.
- Lock deliberately before switching apps or handing the device to anyone.
- Delete decrypted exports once they have served their purpose.
Assumptions that cause trouble
- Assuming encryption still applies while content is on screen.
- Leaving decrypted exports in a downloads folder after sharing.
- Treating device compromise as out of scope because the storage is encrypted.
- Believing a locked app icon means the session behind it is closed.
How to describe the guarantee honestly
A locked vault can help protect stored data, depending on its key protection, credential strength, and the integrity of the device. Evaluate these conditions rather than treating a locked state as an unconditional guarantee.
It does not protect content you are currently viewing, copies you have exported, or a device an attacker already controls. A vendor that states this plainly is more trustworthy than one that lets the ambiguity stand.
A fictional example
Jonas starts with a non-sensitive test: “Keep vault sessions short and enable automatic locking.” Next, Jonas follows the second check: “Avoid unlocking in untrusted physical environments.” This fictional scenario demonstrates the decision process; it is not a report of product testing.
Common mistakes
- Assuming encryption remains opaque while content is visible
- Leaving decrypted exports behind
- Ignoring device compromise
What this workflow does not change
- Assuming encryption remains opaque while content is visible
- Leaving decrypted exports behind
- Ignoring device compromise
Questions people ask
Can an app block every capture method?
No. Platform controls cannot prevent an external camera or all compromised-device behavior.
Why auto-lock on background?
It narrows the time that an active session and decrypted presentation remain available.