← Back to blog
·7 min read

Photo Encryption on iPhone: What It Actually Means

iOS encrypts your photos by default — but that protection disappears when you unlock. What iPhone encryption covers and why app-level CryptoKit encryption matters.

TL;DR

Your iPhone encrypts every file on disk. But the default protection class makes files accessible as soon as the device is unlocked — which is most of the time. App-level encryption with a separate key is the only way to keep photos protected on an unlocked device. Understanding the difference between OS encryption and app encryption is the key to understanding what "encrypted" actually means on your phone.

"Encrypted" is one of the most overused words in app marketing. Every vault app claims it. Every cloud service mentions it. Apple says your iPhone is encrypted. All of these statements are technically true — and all of them mean something different.

iOS encryption: strong, but conditional

Every modern iPhone uses hardware-backed encryption. Files are encrypted on the flash storage chip using keys derived from the device passcode and hardware keys burned into the Secure Enclave processor. Apple's platform security guide describes this system in detail.

iOS defines four data protection classes, each determining when files can be decrypted:

NSFileProtectionComplete

Files are encrypted and completely inaccessible when the device is locked. The decryption key is purged from memory when you lock the screen. This is the strongest protection level — but very few apps use it because it means the app can't do anything in the background while the phone is locked. No notifications based on file content, no background sync, no background processing.

NSFileProtectionCompleteUnlessOpen

Files are encrypted when the device is locked, but files that were already open remain accessible. Used by apps that need to finish writing a file after the device locks.

NSFileProtectionCompleteUntilFirstUserAuthentication

This is the default for most apps. Files are encrypted on disk but become accessible after the first unlock and stay accessible until the device restarts. In practice, this means files are decrypted in memory for as long as the phone is powered on and has been unlocked at least once.

This is the protection class used by the Photos app.

NSFileProtectionNone

Files are encrypted with device-bound keys but accessible at any time, even before the first unlock after a restart. Least protective.

The Photos app uses NSFileProtectionCompleteUntilFirstUserAuthentication. In plain language: your photos are encrypted on disk, but accessible in memory from the moment you unlock your phone in the morning until you restart it. A stolen phone that hasn't been restarted has your photos accessible.

What "encryption at rest" actually protects

iOS file encryption protects against one specific scenario: someone extracting the flash storage chip from the device and trying to read the raw data. Without the hardware keys from the Secure Enclave, the encrypted data is unreadable.

This is genuinely strong protection against hardware-level attacks. It's why law enforcement sometimes can't access locked iPhones — the encryption is real. Elcomsoft's forensic analysis details the challenges of accessing data on locked devices.

But encryption at rest doesn't protect against:

  • Someone with your passcode: Everything decrypts.
  • Apps with photo access: Any app with Full Access to your photo library can read all your photos while the device is unlocked.
  • A running, unlocked phone: The default protection class leaves files accessible in memory.
  • iCloud backups: Photos synced to iCloud are encrypted with keys Apple holds (unless ADP is enabled).

The "military-grade encryption" problem

"Military-grade encryption" typically refers to AES-256, the encryption standard used by the US government. It's a real algorithm and genuinely strong. The problem is that the phrase says nothing about implementation.

AES-256 securing data on a server where the company holds the keys is technically "military-grade encryption." It's also meaningless from a privacy perspective — the company can decrypt your data at any time.

Questions that actually matter:

  1. Who holds the decryption key? If the answer is "the app developer" or "the cloud provider," your data is accessible to them regardless of the algorithm used.
  2. When are files decrypted? If files are in decrypted form in memory whenever the device is unlocked, the encryption protects against hardware extraction but nothing else.
  3. Is each file encrypted individually? Or is there a single key that unlocks everything? Per-file encryption limits the blast radius of a key compromise.
  4. How is the key derived? A key derived from a 4-digit PIN has 10,000 possibilities. A key derived from a 6-character alphanumeric PIN with PBKDF2 and 100,000 iterations is exponentially harder to brute-force.

"Military-grade encryption" tells you the algorithm. It tells you nothing about key management, implementation, or who can actually decrypt your data. The algorithm is the easy part. Key ownership is what matters.

App-level encryption: a different approach

App-level encryption operates independently of iOS file protection. Instead of relying on the device passcode and OS-managed keys, the app encrypts each file with its own key, derived from a separate PIN or passphrase.

Here's how it works in a well-designed vault app:

  1. User sets a PIN specific to the vault (different from the device passcode)
  2. A cryptographic key is derived from that PIN using a key derivation function like PBKDF2 with a high iteration count (100,000+), making brute-force impractical
  3. Each photo is encrypted individually using an authenticated encryption algorithm like ChaCha20-Poly1305
  4. The key exists only in memory while the vault is open. When the vault is locked, the key is purged. The encrypted files on disk are unreadable.

This means:

  • Device unlocked, vault locked: Photos are encrypted. Inaccessible.
  • Device unlocked, vault open: Photos are decrypted in memory, visible in the app.
  • Device locked: Photos are encrypted (both by the vault and by iOS file protection).

The vault key is independent of the device passcode. Someone who knows your iPhone passcode cannot open the vault without also knowing the vault PIN.

The physical safe analogy

Think of your iPhone as an apartment. The device passcode is the front door key. iOS encryption at rest is like having steel walls — nobody can drill through from outside.

But once someone has the front door key, they're inside. Every room is open. Every drawer, every photo album.

An encrypted vault is a physical safe inside the apartment. Different combination. Different lock. Even if someone has your apartment key, the safe contents remain locked. They can see the safe exists, but the contents are unreadable without the combination.

That's the difference between OS-level encryption and app-level encryption. One protects the building. The other protects what's inside.

Inner Gallery uses Apple's CryptoKit framework — the same cryptographic library Apple builds into iOS. Each space in the app has its own PIN and its own encryption key. Photos are encrypted individually with ChaCha20-Poly1305 (RFC 8439).

No servers. No cloud storage. No analytics. The encryption key never leaves the device. If the vault PIN is forgotten, the data is unrecoverable — because nobody else has the key. As explained in Why Inner Gallery Works Without a Server, this architecture eliminates the need for accounts, servers, and the recurring costs that come with them.

For a practical guide to setting up photo privacy on your iPhone, see The iPhone Photo Privacy Checklist.

✅
iOS encryption protects your photos against hardware-level attacks. App-level encryption with a separate key protects your photos against everything else — including someone with your device passcode. If you have photos worth encrypting, the question to ask is: who holds the key?

Inner Gallery is coming soon — join the waitlist.

Join the waitlist