Is Vaultumi safe, and has it been audited?
Vaultumi asks you to trust it with private photos, so the honest answer to “is it safe” has to include what nobody outside the project has checked. This page gives the short answer first, then the detail.
Quick answer
Vaultumi uses standard Apple encryption and keeps everything on your iPhone, but it has not been independently audited, reviewed or certified. Its hand-written scrypt and secret-sharing code have not had an external review. Treat it as one sensible layer, not a guarantee.
- Every item is encrypted on the device with AES-256-GCM under its own key. There is no account, no server and no analytics.
- The project has reviewed its own code and published the notes, but that is not an outside audit.
- Features added after those reviews are not covered by them.
What is it built to protect?
The confidentiality and integrity of your vault data at rest, in app storage and in backup files, against five kinds of person: a casual snooper with brief access, someone who knows your habits and may guess likely PINs, a thief holding a locked phone, someone who knows your device passcode, and someone who holds a copy of your vault files with unlimited offline compute but without the device-only secret.
It is also built to survive crashes and corrupted files without silent data loss, and never to leak data to the network. The algorithms and key handling are laid out in the security summary and, in full, in the architecture document.
What does it not protect against?
- A compromised, jailbroken or malware-infected iPhone, and anyone who can read the app’s memory or Keychain.
- Someone watching you enter your PIN, or forcing you to unlock the phone.
- Forensic analysis of the device. There is no secure erase of flash storage.
- A weak backup passphrase, and a 6-digit PIN against an attacker who has both the vault files and the device-only secret: for that person it falls in hours to days.
- Screenshots, exported files, and originals that remain in Photos or iCloud.
The full list, with the reasoning for each item, is in the threat model.
Has anyone reviewed it?
The project ran two separate read-only reviews of its code at build 2: an adversarial security review and a robustness review. They are published as the security review notes. They found one blocker (a stale in-memory header that could bring back an old recovery code after a PIN change), which was fixed. Of the eleven high-severity rows, seven were fixed, three mitigated and one accepted. No critical finding was recorded.
These reviews were of the project’s own code. They are not an external audit, and the notes themselves say they are not a substitute for one. They were done at build 2, and Vault Drop, the Intruder log, documents with text search, similar photos, Legacy Kit, the backup safety check and backup reminders came later. None of those is covered.
What still needs outside review?
- An independent cryptographic review, above all of the hand-written scrypt and the hand-written Shamir secret sharing, plus the media file format, key wrapping and the backup format.
- A review of Keychain and biometric usage, including behaviour across a restore or migration.
- A penetration test of the running app on a physical device: temporary-file residue, app-switcher snapshots, logs and memory after lock.
- Legal review of export-control classification, the privacy policy and the terms.
Until those are done, claims stronger than “encrypted with standard Apple primitives” would be unfounded.
Does it phone home, and can the developer see your photos?
As of the last source check on 30 October 2026, the code makes no network requests of its own, uses no web views and has no analytics, advertising or crash-reporting code, and no third-party packages. The only network traffic is Apple’s StoreKit and the App Store, for purchases. That check is repeated before each release. It does not cover what iOS itself does, such as iCloud device backup if you have it on.
The developer holds no keys and no copy of your data, so there is nothing to hand over and no way to reset your vault. That is also why a lost PIN, recovery code and backup cannot be rescued. The privacy policy says the same in legal terms.
How can you judge it yourself?
- Read the threat model and decide whether your risk is on its list of things it covers.
- Check that the claims on the security page are specific and that the limits are as prominent as the strengths.
- Compare it with the criteria in the photo vault app checklist.
- Test the recovery path before you rely on it: make a backup file and run the Backup safety check.
How should you use it, given all this?
Keep the copies that matter in more than one place, including a tested backup file. Use it for the photos that need a separate lock, not as the only home of anything irreplaceable. Pair it with a strong device passcode and current iOS. If you find a security problem, the report address is on the security page, and good-faith research is welcome.
Sources
Primary sources behind the statements about iOS and cryptography on this page. The linked pages are in English.
- Apple Developer: CryptoKit
- NIST SP 800-38D: Galois/Counter Mode (GCM) and GMAC
- RFC 7914: The scrypt Password-Based Key Derivation Function
- Apple Platform Security: Keychain data protection
More guides
Photo vault app checklist
Eight checks on encryption claims, accounts, backup, export and terms.
Are photo vault apps safe?
How vault apps fail, six checks before you trust one, and what no vault fixes.
Choose a PIN and passphrase
Which of the three secrets must be strong, and where each one should live.