How can you tell if a photo vault app is safe?

Check the app on the phone you'll actually use. Ask five questions: are the files themselves encrypted, who can unlock them, which permissions does it want, what happens to the originals, and how would you get everything back if you lost your phone? A store listing or the word “encrypted” doesn't answer those on its own.

For NullVault, start with the security architecture, security limitations and encrypted backup design. These are the product disclosures of the TAD team at Think Aloud Design, not an independent security audit. For other apps, use the same questions and their own documentation.

What “safe” has to mean before the question is answerable

“Safe” collapses several different promises into one word. A vault app can be safe in the sense that it encrypts stored files, and unsafe in the sense that it keeps a readable thumbnail cache, or leaks filenames, or has no recovery path when you forget the credential.

Split the question before answering it. Ask what is encrypted, what authorizes decryption, what remains readable while the vault is open, and what happens to your data if the app is deleted or the company disappears. Those four answers describe most of the real risk.

What a cipher name does not tell you

Seeing “AES-256” in a store listing establishes very little. The same algorithm protects everything from a well-designed vault to one that reuses a nonce, derives a key from an unsalted PIN, or stores that key beside the ciphertext it protects.

The design questions that matter sit around the cipher rather than in it: how the key is derived from what you type, where the derived key lives while the app is closed, whether filenames and previews are encrypted alongside the file, and whether altered data is detected rather than silently decrypted.

The risk moves when the vault is open

Encryption at rest describes stored vault records while the vault is locked. While you are viewing a photo, displayed or decrypted copies can exist in memory, on screen, in a screenshot, a recording, or an operating-system preview; assess those session risks separately.

This is why automatic locking and short sessions matter more than they look, and why a compromised device defeats a vault regardless of the algorithm. A vault narrows the window; it does not remove it.

Test the whole lifecycle, not the lock screen

Most evaluations stop at whether the app opens with the right credential. The failures that lose data happen elsewhere — at import, export, backup, and restore.

  • Read the technical documentation and the stated limitations before installing.
  • Import a non-sensitive test file, lock the app fully, and reopen it from a cold start.
  • Export that file and confirm it opens intact outside the vault.
  • Create a backup, restore it on a second device or after a reinstall, and open real content — not just a thumbnail.
  • Review the store privacy disclosure and the permissions the app actually requests.

Permissions and disclosures are evidence you can check

A vault that requests contacts, location, or broad network access deserves an explanation. Compare what the app asks for against what its stated function needs, and treat a gap as a question rather than a verdict.

Store privacy disclosures are self-reported, so they are a starting point rather than proof. They are still useful: a declared “no data collected” label is a public commitment that can be checked against observed network behavior.

Signals that should lower your confidence

  • Marketing language like “military-grade” standing in for a documented design.
  • No published limitations page, or a claim that the app protects against everything.
  • No recovery documentation, or recovery that depends entirely on the vendor.
  • An app ranked highly by a review that shows no evidence of hands-on testing.
  • Long gaps in update history on a platform that has since changed its storage or permission model.

What no vault app can promise

No vault protects a photo that already exists somewhere else. Copies in a cloud library, a message thread, a downloads folder, or a system backup are outside its boundary and have to be handled separately.

No vault protects a device that is already compromised, and none can promise that data written to flash storage has been physically erased. An app that claims otherwise is describing marketing, not engineering.

Common mistakes

  • Trusting 'military-grade' without a design
  • Ranking apps without current hands-on testing

What this workflow does not change

  • Encryption at rest does not protect content visible in an unlocked session.
  • A vault does not control originals, exports or backups held by other apps.
  • Product disclosures and a successful sample import do not replace an independent security audit.

Questions people ask

Does a calculator disguise prove security?

No. Camouflage and encryption are separate properties.

Sources and further reading