What the Secure Enclave Actually Protects

The Secure Enclave is a separate chip that guards encryption keys and biometric data, and enforces passcode attempts. It’s genuinely strong, and it protects the boundary of the device rather than the contents. Once the phone is unlocked in someone’s hand, it has already done everything it can do.

The short answer

People invoke the Secure Enclave the way they invoke military-grade encryption, as a phrase that ends the conversation. It deserves more respect than that, because it’s real engineering that solves a hard problem well.

It also has a precise job. It protects secrets that must never be readable by software, primarily cryptographic keys and biometric templates, and it polices attempts to unlock the device. Those are the things it does, and it does them very well.

What it does not do is decide who is allowed to look at your camera roll on a phone that’s already open. That’s a different problem, on the other side of a boundary the Secure Enclave doesn’t cross, and confusing the two is why people are surprised by how visible their photos are.

What it physically is

The Secure Enclave is a dedicated subsystem built into Apple’s chips, isolated from the main processor. Calling it a coprocessor undersells how separate it is.

It has its own boot ROM, runs its own operating system called sepOS, has its own AES hardware for encryption, and uses memory the main processor cannot read. Communication happens through a narrow mailbox interface, so the rest of the system asks it questions and receives answers rather than reaching into it. There’s a small amount of flash storage, around 4MB, used specifically for 256-bit elliptic curve private keys.

The design goal is simple: even if an attacker fully compromises iOS, including kernel-level access, the secrets inside the enclave stay inside. The main OS never handles them, so there’s nothing to steal at that layer.

What it actually protects

Three things, and it’s worth naming them precisely because the list is shorter than the reputation suggests.

• Cryptographic keys. Device keys are generated and stored inside the enclave, and used there. Software asks the enclave to perform an operation with a key rather than being handed the key.
• Biometric templates. The mathematical representation of your face or fingerprint is processed and stored by the Secure Enclave. It never leaves the device, isn’t sent to Apple, and isn’t in your backups.
• Passcode attempts. It verifies the passcode, enforces escalating delays between failures, and applies the erase-after-ten-failures setting when you’ve enabled it.

There’s a fourth item that’s really a consequence of the first: the device’s unique identifier, the UID, is fused into the silicon during manufacturing and isn’t readable by software, including by Apple. Encryption keys derive from it, which is what ties your data cryptographically to that specific physical device rather than to a copy of your data elsewhere.

Notice what isn’t on the list. Your files aren’t in there; there’s nowhere near enough room. They sit in ordinary storage, encrypted, with the keys protected by the enclave.

The connection between the two runs through a system Apple calls Data Protection. Every file gets its own encryption key, and that key is itself encrypted by a class key, and the class keys are tied to the passcode and the hardware. The classes are the interesting part, because they decide when data becomes readable. Some files are available only after the first unlock following a reboot and stay available from then on, which is why background apps keep working while your phone sits locked in a pocket. Others are locked again the moment the screen locks. That’s the mechanism behind a familiar detail: a message notification can arrive on a locked phone, but the app can’t necessarily read its full history until you unlock. Same chip, different class, different availability.

Why “your face isn’t stored” is true

The Face ID claim sounds like marketing and happens to be accurate, and the Secure Enclave is the reason.

When you enrol, the sensor captures depth data, and the enclave converts it into a mathematical representation. That representation, not an image, is what’s stored, and it’s stored inside the enclave. When you unlock, the new scan is compared against it inside the enclave too. The rest of iOS receives one bit back: match or no match.

That architecture is why a compromised app cannot exfiltrate your face, why Apple genuinely doesn’t have it, and why it isn’t in an iCloud backup. We went through the practical strengths and limits of Face ID itself in how secure is Face ID.

The part that makes a 6-digit passcode viable

Here’s the Secure Enclave’s most underrated contribution, and it’s the one that changes the maths on your passcode.

Six digits is a million combinations. As raw entropy that’s terrible; a computer that could test them freely would finish in well under a second. It works anyway, because nothing can test them freely.

Passcode verification happens inside the Secure Enclave, which enforces increasing delays after wrong guesses and cannot be bypassed by asking faster or from a different source. An attacker can’t lift the encrypted storage and brute-force it offline either, because the keys derive from the hardware UID that never leaves the chip. The guessing has to happen on that one device, at the pace the enclave allows.

So a six-digit passcode isn’t secure because it’s hard to guess. It’s secure because the hardware limits how often you may try, which is a completely different kind of protection. We ran the numbers on that in is a 6-digit passcode enough.

Where it helps and where it doesn’t

Situation	Does the Secure Enclave help?
Phone lost or stolen while locked	Yes, this is its core purpose
Someone trying passcodes by hand	Yes, delays make it impractical
Attacker imaging your storage chip	Yes, keys are tied to hardware
Malware trying to read your keys	Yes, keys never enter the main OS
Someone stealing your Face ID data	Yes, it never leaves the chip
A friend scrolling your unlocked phone	No
Someone who knows your passcode	No
An app you granted photo access to	No
Photos synced to a compromised account	No
You handing over the phone at a border	No

The top half and the bottom half are different worlds. Everything the Secure Enclave handles concerns a device that is locked or under attack from software. Everything it doesn’t concerns an unlocked device and an ordinary human situation.

The boundary it doesn’t cross

This is the part worth internalising. When you unlock your iPhone, the system unwraps the keys it needs to read your data, and from that point your files are readable by the operating system and by anything running with the right permissions.

That’s not a flaw. It’s what unlocking means. A phone that stayed encrypted after you unlocked it would be a phone that couldn’t show you anything. But it has a consequence people rarely follow through: your camera roll is protected by the Secure Enclave exactly as long as your phone is locked, and not one moment longer.

So for the scenarios that actually happen to most people, a friend borrowing your phone, a partner who knows your passcode, a repair technician, someone reaching over your shoulder, the strongest chip in the device contributes nothing. Not because it’s weak, but because those situations are on the far side of its boundary.

Hardware generation matters at the edges, too. A boot ROM vulnerability known as checkm8 affects chips up to the A11, and because it lives in read-only memory it can’t be patched by a software update. In practice that means an iPhone X or older sits in a weaker position against an attacker with physical possession and time than anything from the A12 onward. It isn’t a reason to panic about an old device, and it is a reason not to treat every iPhone as equivalent when the phone itself might fall into someone else’s hands.

Why an app-level vault is a separate layer

Once you see the boundary, the reason for a second layer is obvious. Hardware security protects the device. Application-level encryption protects specific data inside the device, including from someone holding it unlocked.

The mechanism is different too. A vault encrypts individual files with a key derived from a secret you enter, so the files stay unreadable until you supply it, unlock state notwithstanding. That’s a smaller, sharper guarantee than full-device encryption, and it covers precisely the gap the Secure Enclave leaves open.

The two aren’t in competition and neither replaces the other. Device encryption without a vault leaves everything visible once you’ve unlocked. A vault on a device without hardware protection would be much easier to attack from underneath. Together they cover both sides of the line.

Where Arca fits

Arca operates on the far side of that boundary. Photos you move into it are encrypted individually with AES-256-GCM, and the key comes from your PIN through Argon2id, a deliberately slow key-derivation function that makes guessing that PIN expensive rather than instant. That matters here because Arca can’t lean on the Secure Enclave’s rate limiting for its own PIN, so the slowness has to come from the maths instead.

Everything stays in the app’s own container on your device. There’s no server and no account, so there’s no cloud copy, nothing on our side to breach, and nothing to hand over. For situations where you might be pressured to unlock, there’s a decoy vault. The full model is on our security page.

The limits, stated plainly as always: a vault protects the photos you actually move into it, not the ones still in your camera roll. It protects them at rest, not while the vault is open in front of someone. And because Arca keeps nothing on a server, it can’t recover your photos if you forget your PIN, so keep your own backup of anything irreplaceable.

Your iPhone has excellent security for the problem it was built to solve. Knowing where that problem ends is what tells you whether you need anything else.

Get Arca on the App Store to keep your private photos encrypted with AES-256-GCM on your device, with no server in the loop.