The Secure Enclave, explained
It is not a folder, a keychain, or a feature flag. It is a second computer on the die that your Mac or iPhone cannot read out of — only ask questions of.
The Secure Enclave is a separate subsystem inside Apple silicon with its own boot ROM, its own AES engine, and memory the main application processor cannot address. It runs its own small operating system, sepOS, verified by that immutable boot ROM at every start. The practical consequence is the part people skip: even a fully compromised kernel does not get to read what the Enclave holds.
What it holds is key material. Face ID and Touch ID templates never leave it — the sensor sends data over a channel keyed to the Enclave, matching happens inside, and what comes back out is essentially a yes or a no. Your file class keys live there too, which is why Data Protection is meaningful rather than decorative: a file encrypted under a class that requires the device be unlocked genuinely cannot be decrypted while it is locked, because the key is not resident anywhere the rest of the system can reach.
SEP — the Secure Enclave Processor, a peer, not a peripheral.
UID — a key fused at manufacture, never exported, not known to Apple.
The passcode is the hinge, and it is why the Enclave needs a friend. A six-digit passcode is trivially brute-forceable if you can try guesses at silicon speed, so attempt counting has to be tamper-evident and non-rewindable. That is the job of the Secure Storage Component, a separate chip holding entropy and enforcing anti-replay over an encrypted, authenticated link. Restore the flash, roll back the state, replay an old response: the counters disagree, and the key is never derived.
The useful habit when reading an advisory is to ask which side of the Enclave boundary the bug lives on. A kernel arbitrary write is severe, and it gets an attacker the running device. It still does not get them the class keys of a phone sitting locked in an evidence bag, and that difference is the whole design.