A private vault.
Clear boundaries.

A pattern that protects the encryption key

New vaults use an ordered pattern on a 5×5 grid with at least eight distinct dots and at least two direction changes. PBKDF2-HMAC-SHA512, with a random salt and 600,000 rounds, stretches the pattern. HKDF then mixes in a random 256-bit secret that exists only in this iPhone’s Keychain, and the result wraps a randomly generated 256-bit vault master key using AES-256-GCM. The pattern is not just a screen lock, and the iPhone passcode alone cannot release a pattern vault’s master key.

The device secret is stored as a this-device-only Keychain item: it is never synced, never included in iPhone or iCloud backups and never leaves the phone. A copied vault folder therefore cannot be guessed offline from the files alone; an attacker would also have to extract this iPhone’s Keychain. On the phone itself, wrong patterns trigger escalating delays of up to 15 minutes per attempt. Patterns can still be observed or guessed, so avoid predictable shapes and drawing where someone can watch.

Your recovery code does not depend on the device secret. If the secret is lost, for example after a Keychain reset, the recovery code still opens the vault and you choose a new pattern. Vaults created before this protection are upgraded automatically the next time their pattern opens them.

Hidden vaults, decoy and duress

Each vault has its own pattern, random master key and recovery code. Sanctum opens to a pattern grid, never a list of vaults: a drawn pattern is tried against every vault at once, and the app waits for every attempt before answering, so the delay does not hint at which vault matched or how many exist. Two vaults cannot share a pattern. One vault’s credentials do not unlock the others, and opening one locks the previous one.

A decoy is an ordinary second vault with its own encryption. A duress vault (Pro) opens like any other, and at that moment replaces the pattern wrappers of the other vaults on this iPhone so their patterns stop working. Their files and recovery wrappers are left intact, so each one reopens with its recovery code; nothing is deleted. Only a pattern unlock triggers duress, never a recovery code.

This hides vaults from anyone using the app, not from forensic analysis. Someone who extracts the app’s storage from an unlocked iPhone could count encrypted vault folders; their names are random identifiers and reveal no patterns, titles or contents. That Sanctum is installed stays visible, even with a disguised Home Screen icon. Automatic iCloud backup starts off for vaults you add, because a second backup file would show that a second vault exists. More on hidden vaults.

Media, documents, notes and metadata are encrypted

The random master key protects photos, videos, documents, notes, thumbnails and the collection index with AES-256-GCM. Titles, albums, favorites and Recently Deleted status are part of the encrypted index. Authenticated encryption checks integrity as well as confidentiality. Video playback decrypts authenticated, bounded chunks without a full app-managed plaintext movie; deliberately exporting an original is a separate action.

The private camera saves photos and videos straight into the vault, so nothing is written to your camera roll. Imports from Photos and Files create encrypted copies. Originals remain at the chosen source until you delete them, and system pickers can create temporary plaintext transfer files. After an import Sanctum offers to delete the originals from Photos; iOS keeps them in Recently Deleted for up to 30 days unless you empty it. App-owned staging uses complete iOS file protection and cleanup. Encryption inside Sanctum does not protect copies outside it.

Encrypted sharing without accounts

With Pro, selected photos and videos are re-encrypted chunk by chunk into a single .sanctumshare file under a fresh key. That key is derived with HKDF-SHA256 from a one-time code of 120 random bits, shown as 24 characters, and a random salt. No plaintext copy is written while sending. Every frame authenticates the header and its position, titles are inside the encryption, and a footer proves the file is complete.

You send the file by AirDrop, Messages or any app, and the code separately. Anyone with Sanctum can open it for free and the items are encrypted into their own vault. An optional expiry of 1, 7 or 30 days is sealed inside the authenticated encryption, so it cannot be edited, and Sanctum refuses to open the share afterwards. Expiry relies on the receiving iPhone’s clock and Sanctum’s own check: it cannot recall a file already opened, and anyone who has both the file and the code can read it before then. No server is involved, so shares cannot be revoked or limited to a number of opens.

Original exports leave the encrypted boundary

Export original to Files warns that the saved photo or video is plaintext, not encrypted by Sanctum. The vault item stays encrypted and unchanged. Destination providers may upload or cache the saved copy outside Sanctum; the app cannot recall it, and locking or deleting a vault does not remove it. Temporary app-owned export copies use complete iOS file protection and cleanup after dismissal, not a secure-wipe guarantee. A provider accepting a save does not prove a remote upload has finished. This is not an encrypted backup.

A separate recovery envelope

Setup generates a random 256-bit recovery code and requires full re-entry before vault creation. A key derived from this code wraps the same master key in a separate, authenticated envelope. Plaintext patterns and recovery codes are not persisted by Sanctum. Someone with your recovery code and matching vault data can unlock the vault: treat the code as a credential, not as a backup.

There is no operator-held decryption key or reset service. If the pattern and recovery code are both lost, Sanctum cannot unlock the collection for you.

Encrypted backups with authenticated restoration

A .sanctumbackup archive includes encrypted originals, thumbnails, metadata and retained Recently Deleted items. Its outer encryption uses a separate recovery-code-derived key, a random archive salt and sequential AES-GCM frames. The header and frame positions are authenticated, and restoration checks a terminal footer and all content in protected staging before publishing into a new, absent vault slot. Other vaults can remain on the phone. Restoration rejects a backup of a vault already present and never duplicates, merges with or overwrites existing vaults.

Automatic backup is on by default for the first vault and off for vaults you add; each vault has its own switch. Automatic backups to the app’s iCloud Drive folder use the same archive format with one difference: frames are keyed from the vault’s master key, and the header carries the vault’s existing recovery wrapper, so the app can write them without asking for the code while restoring still requires it. They run only while the vault is open and replace the previous copy; there is no live sync between devices. Local vault storage is excluded from ordinary device backups. Each backup needs the recovery code that was current when it was made. Later credential changes or local deletions do not revoke or update earlier copies. A Files provider accepting a save does not prove remote upload has finished.

iPhone protection and older vaults

An iPhone passcode is required for protected local storage. Older device-authenticated vaults keep their original device-only, user-presence-protected Keychain key until an explicit upgrade to pattern access. The new key envelope is committed before the legacy key is removed. Until that upgrade and cleanup complete, do not assume the older authentication route has been replaced.

Limits while the vault is open

Sanctum locks on backgrounding or loss of protected-data access, shields app-switcher snapshots and blocks access during detected screen recording or mirroring. iOS does not offer universal screenshot prevention. Decrypted previews and keys exist in memory during use, and perfect memory erasure or forensic erasure from flash storage is not promised. Keep your iPhone and credentials secure even when using an encrypted vault.

For practical steps, read the recovery and backup guides. The privacy policy explains the separate boundaries for purchase services, chosen storage providers and this website.