Apple Data Protection Classes and the Secure Enclave Explained

Apple's Data Protection encrypts every iPhone file with its own 256 bit key, wraps that key with one of four class keys, and lets the Secure Enclave unwrap a class key only when its rule is met. Class keys come from your passcode entangled with a device UID that never leaves the chip, so guessing must happen on the phone.

The rest of this post goes a level deeper, using Apple's Platform Security guide and support pages for Apple facts, Android's source documentation for Android facts and Samsung's Knox documentation for Samsung facts. It covers the Secure Enclave's parts, each Data Protection class, what "Before First Unlock" means for a stolen phone, how passcode and hardware keys combine, Advanced Data Protection, Stolen Device Protection, the inactivity reboot, Lockdown Mode, Android's equivalent, and what to put in mobile policy.

If you want the head to head comparison of the two phone platforms, read iPhone vs Samsung Galaxy security compared. If your question is whether a phone that looks switched off can still be found, read is an iPhone really off when Find My still works. For the Android boot side of the story, see Android Verified Boot and the chain of trust. This post stays on encryption at rest and the keys behind it.

Key takeaways

• The Secure Enclave is an isolated subsystem inside Apple's system on chip with its own processor, boot ROM, random number generator, AES engine and encrypted memory, running sepOS.
• Each device has a UID fused in at manufacture, generated inside the Secure Enclave from the A9 onward. Keys derived from it never leave the hardware AES engine, not even to sepOS.
• Every file gets its own 256 bit per file key. That key is wrapped with a class key, and the class decides when the file can be read: Class A only while unlocked, Class B can be written while locked, Class C after the first unlock since boot, Class D always (protected only by the UID).
• Class C is the default for third party app data. That is why the difference between Before First Unlock (BFU) and After First Unlock (AFU) matters so much: in AFU, most app data is decryptable while the phone sits locked on a table.
• The passcode is entangled with the UID at about 80 milliseconds per attempt, so guesses must run on the device, under Secure Enclave delays and, on newer devices, a counter lockbox.
• Advanced Data Protection moves most iCloud service keys off Apple's hardware security modules and onto your trusted devices. iCloud Mail, Contacts and Calendar stay outside it, and some metadata stays under standard protection.
• Stolen Device Protection (iOS 17.3 and later) adds a biometric requirement and a one hour security delay away from familiar places. Researchers reported in November 2024 that iOS 18.1 reboots a phone left locked for 72 hours, returning it to BFU; Apple had not documented it in the sources we checked.
• Android 7.0 and later uses file based encryption with per user Credential Encrypted (CE) and Device Encrypted (DE) storage. CE is roughly Apple's Class C and DE roughly Class D, with rate limiting in a TEE or a secure element. All devices launching with Android 10 and later must use it.

Timeline: the hardware and software milestones

Apple documents its security features by chip generation and operating system version rather than by calendar date, so most rows below give the version. Where a calendar date appears, it comes from the cited source.

What is the Secure Enclave, and what keys never leave it?

The Secure Enclave is, in Apple's words, a dedicated secure subsystem integrated into the Apple system on chip and isolated from the main processor. Its purpose is to keep sensitive user data secure even if the Application Processor kernel is compromised. It is present in iPhone 5s and later, iPad Air and later, every Mac with Apple silicon, Intel Macs with the T2 chip, Touch Bar MacBook Pros with the T1, Apple Watch Series 1 and later, Apple TV HD and later, Apple Vision Pro and HomePod.

What is inside it

Apple's Platform Security guide lists these parts.

A separate AES Engine sits in the direct memory access path between flash and main memory and encrypts every file as it is written. At boot, sepOS sends it an ephemeral wrapping key over dedicated wires, so the file system driver only ever handles wrapped per file keys, and Apple says the engine never exposes the unwrapped key to software.

UID and GID

Two root keys are burned into the chip.

• The UID is unique to each device and unrelated to any other identifier on it. Starting with A9, the Secure Enclave's own TRNG generates it during manufacturing and a process running entirely inside the Secure Enclave writes it to fuses. Apple's guide says this protects it from being visible outside the device during manufacturing, so it "isn't available for access or storage by Apple or any of its suppliers."
• The GID is shared by every device with the same chip, for example every A15 device.

Neither is reachable through JTAG or other debug interfaces. Because the file system key hierarchy includes the UID, moving the flash storage from one device into another leaves the files unreadable.

Which keys never leave the Secure Enclave

"Never leave" means different things for different keys, so it is worth being precise.

The hardware keys are the strongest case: software can ask for encryption or decryption with them, but it can never extract them.

The timeline above shows which chip generation added which protection; a phone first released before Fall 2020 lacks the counter lockbox described below even if a later model shares its chip name.

What are the four Data Protection classes, and when is each file readable?

Data Protection is Apple's per file encryption scheme on devices with an Apple SoC. When an app creates a file, it assigns a class, and the class decides when the class key, and therefore the file, can be unlocked. Apple's guide says system apps such as Calendar, Contacts, Mail, Messages and Photos, plus Health data, use Data Protection by default, and third party apps receive it automatically.

Per file keys first

Every time a file is created on the data volume, Data Protection generates a fresh 256 bit per file key and hands it to the AES Engine, which encrypts the file as it is written. On A14 through A18 and M1 or later, encryption is AES-256 in XTS mode, with the per file key run through a NIST SP 800-108 key derivation function. On A9 through A13 and S5 or later, it is AES-128 in XTS mode, with the 256 bit key split into a 128 bit tweak value and a 128 bit cipher key. APFS can go further and give different extents of one file different keys.

The per file key is wrapped with a class key and stored in the file's metadata. The metadata itself is encrypted with the file system key. So reading a file needs three things: the file system key, the right class key, and the Secure Enclave's cooperation to unwrap.

The four classes

Class A keys are protected with a key derived from the passcode and the UID. Shortly after locking, the decrypted class key is thrown away. Unlocking with the passcode or biometrics brings it back.

Class B solves a real problem: some files must be written while the phone is locked. Apple uses One-Pass Diffie-Hellman over Curve25519 (NIST SP 800-56A): the per file key is wrapped with a key agreed between an ephemeral key pair and the class public key, and the ephemeral public key is stored alongside. Writing needs only the always available public key; reading later needs the class private key, available only when unlocked. As soon as the file is closed, its per file key is wiped from memory.

Class C behaves like Class A except the decrypted class key is not removed when the device locks. Apple compares its protection to desktop full volume encryption: it defends against attacks that involve a reboot. Because this is the default for third party apps, most app data on a phone in daily use is in this class.

Class D keys are protected only with the UID and kept in Effaceable Storage. All the keys needed are on the device, so the encryption's main benefit is fast remote wipe: destroy the key, and the data is gone. Even a file with no class assigned is still stored encrypted.

The Mac is different

On a Mac with Apple silicon, Class D is not supported, and the security boundary is logging in and out rather than locking and unlocking. Data Protection defaults to Class C but uses a volume key rather than per file keys, which recreates FileVault's model. Apple's guide says that on macOS 26.4 or later FileVault is on by default, entangling the key hierarchy with the user's password, and users can opt out. Developers can still opt into a higher class with per file or per extent keys.

The keychain has its own classes

Passwords, tokens and keys usually live in the keychain, not files. The keychain is a SQLite database where each item has two AES-256-GCM keys: a metadata key cached in the Application Processor for fast queries, and a per row secret key that always needs a round trip through the Secure Enclave. Its accessibility classes mirror the file classes.

The WhenPasscodeSetThisDeviceOnly class is the strictest. Items in it do not sync to iCloud Keychain, are not backed up, are not included in escrow keybags, and become useless if the passcode is removed or reset because the class keys are discarded. Every other class has a "ThisDeviceOnly" variant that stays wrapped with the UID in backups, so it cannot be restored to another device.

Apple's guide lists the classes it uses for system items. Wi-Fi passwords, VPN passwords, mail account credentials, iMessage keys and the iCloud token are "after first unlock". Safari passwords are "when unlocked". The push notification token and Bluetooth keys are "always, nonmigratory". That list is a good reality check: a lot of credential material is available in AFU so the phone can keep working while locked in your pocket.

What do Before First Unlock and After First Unlock mean for a seized or stolen phone?

These two terms are not Apple marketing labels; they are the practical consequence of Class A and Class C.

Before First Unlock (BFU) is the state after a restart and before anyone has entered the passcode. No class key that depends on the passcode has been unwrapped. Class A, B and C data is unreadable, which covers nearly all user content. The phone can still do things that rely on Class D and system data: show the Lock Screen, ring an alarm, accept an incoming call. Researcher Jiska Classen, quoted by heise, describes how in BFU contacts are not yet decrypted and notifications appear without content.

After First Unlock (AFU) is the state after the first passcode entry since boot. The Class C key is now in the Secure Enclave and stays there until the next reboot, even while the screen is locked. Class A data is locked again a few seconds after the screen locks, but Class C data, which is the default for third party apps, remains decryptable by the running system. Classen's description, as reported by heise, compares AFU to a key safe left open while iOS is running.

What this means in practice:

The lesson for defenders is short. In BFU, an attacker faces the full cost of guessing the passcode on the device. In AFU, the attacker's best path is a flaw in the running software that lets them ask the system for data it can already decrypt. That is why the security of a locked but powered phone depends on patch level as much as on cryptography, and why features that push a phone back to BFU matter.

How do the passcode, UID key and class keys combine?

Here is the hierarchy Apple describes, simplified to show who holds what.

passcode (user)  +  UID (fused, inside AES Engine)  [+ SKP measurements, A10 and later]
        |
        v
passcode-derived key  (tuned to ~80 ms per attempt, only computable on this device)
        |
        +--> counter lockbox entropy (Secure Storage Component, gen 2) 
        |
        v
unwraps class keys in the user keybag  (Class A, B private, C)
        |
        v
class key unwraps per-file key  (stored in file metadata, wrapped)
        |
        v
per-file key -> AES Engine (wrapped with the boot-time ephemeral key) -> file contents

Four ideas make this work.

1. Entanglement with the UID

Apple's guide says the passcode is "entangled with the device's UID, so brute-force attempts need to be performed on the device under attack." Because the UID derived key never leaves the AES Engine, an attacker who copies the flash to a cluster of GPUs gets ciphertext and no way to test guesses. Every guess must go through this specific chip.

2. A deliberately slow derivation

The iteration count is calibrated so one attempt takes about 80 milliseconds. That is fast enough that you do not notice it at unlock, and slow enough to make exhaustive search painful even before any other control.

3. Escalating delays enforced by the Secure Enclave

On iPhone and iPad, Apple's guide lists the Lock Screen delays by attempt number.

The delays are enforced by the Secure Enclave, and a restart during a delay does not skip it: the timer starts over for the current period. If Erase Data is turned on, 10 consecutive wrong attempts erase all content and settings. Repeating the same wrong passcode does not count toward the limit.

4. Counter lockboxes

On devices first released in Fall 2020 or later, the second generation Secure Storage Component holds counter lockboxes. Each one stores a 128 bit salt, a 128 bit passcode verifier, an 8 bit counter and an 8 bit maximum attempt value. To unlock, the Secure Enclave derives passcode entropy from the passcode and its UID and sends it to the Secure Storage Component. That component first increments the counter. If the counter is over the limit, it erases the lockbox. Otherwise it checks the verifier and, on a match, returns the lockbox entropy and resets the counter to zero. Apple's guide gives 10 attempts on iPhone as the example limit. The Secure Storage Component and Secure Enclave talk over an encrypted, authenticated protocol, so the passcode cannot be learned through unlock attempts from any source other than the paired Secure Enclave.

The order matters: incrementing before checking means cutting power mid attempt cannot get a free guess.

Worked example 1: what 80 milliseconds buys

Ignore the delays and lockbox for a moment and only count the derivation cost Apple states.

The third row reproduces Apple's own statement that trying every six character lowercase alphanumeric passcode would take more than five and a half years. The first two rows show why the derivation cost alone is not enough for short numeric passcodes. A six digit code falls in under a day if the only cost is 80 ms per try. That is exactly why the Secure Enclave adds delays and why the lockbox exists.

Worked example 2: what the delays and lockbox add

Now add the Lock Screen delays from Apple's table. Summing the waits after attempts 4 through 9 gives 1 + 5 + 15 + 60 + 180 + 480 = 741 minutes, about 12.4 hours, to get through 9 attempts. At attempt 10 the device locks and needs a computer, and with Erase Data on, the content is gone. On a device with a counter lockbox, the Secure Storage Component erases the entropy once the maximum is passed whether or not the operating system is behaving.

So the real budget against a current iPhone in BFU is around ten guesses, not a million. The policy question becomes whether one of the first ten guesses is likely to be right: a birth date or 123456 fails, a random six digit code mostly passes, and a longer alphanumeric passcode insures against any future flaw that removes the limit.

Keybags: where class keys are stored

Apple's guide describes five keybags.

Two details catch people out. The backup keybag is not device bound, so Apple notes a parallel brute force attack against an encrypted local backup is possible in theory; only a strong backup password stops it. And the device side of the escrow keybag is in Class C, which is why a phone must be unlocked once after reboot before a computer can back it up.

Sealed Key Protection

On A10 and later, the Public Key Accelerator supports OS-bound keys, which Apple calls Sealed Key Protection (SKP). These keys combine the UID with a hash of the sepOS that booted, recorded by the Secure Enclave Boot ROM or, from A13, the Boot Monitor. Apple's SKP page says the key that results from entangling the user password, the long term SKP key and the UID is called the password derived key, and it protects the user keybag. If someone changes the measured firmware or, on a Mac, the security policy without authorisation, the measurements change, the derived keys change, and the data stays sealed. Legitimate updates work because the signed manifest already contains the expected future measurements.

How does Advanced Data Protection change iCloud encryption, and what stays outside it?

Everything above is about data on the device. Advanced Data Protection (ADP) is about the copy in iCloud.

Under standard data protection, the default, iCloud data is encrypted in transit and at rest, but the keys for most categories are held in Apple's data centres, in what Apple's guide calls available-after-authentication iCloud hardware security modules. That is what lets Apple help you recover data after a forgotten password. A smaller set of categories, including Health data and passwords in iCloud Keychain, is end to end encrypted even under standard protection.

When you turn on ADP, your device does two things. It records the choice in iCloud Keychain device metadata, signed by device local keys so Apple's servers cannot alter or roll it back. Then it starts deleting the CloudKit service keys from those HSMs. Apple's guide calls the deletion "immediate, permanent, and irrevocable". The device then rotates to new service keys that were never available to Apple, retrying until rotation succeeds. New data is written under keys only your trusted devices hold.

What ADP adds, and what it does not

Apple's guide gives the number of end to end encrypted categories as rising from 14 to 23 with ADP. Apple's separate support article, "iCloud data security overview", says 15 categories under standard protection rising to 25 with ADP. The difference most likely reflects categories added since one page was written; check the support article's table for the current list rather than relying on either number.

Requirements and trade offs

ADP needs two factor authentication, a passcode on trusted devices, every signed in device on iOS 16.2, macOS 13.1 or equivalent versions or later (an older OS could re-upload the new keys to the HSMs), and at least one recovery contact or recovery key. Managed Apple Accounts and some child accounts cannot use ADP, and Apple notes it may not be available in all countries or regions.

The trade off is real. If you lose every trusted device and your recovery methods fail, Apple says it cannot help you recover end to end encrypted data. Turning ADP off later uploads both old and new service keys back to the HSMs and returns the account to standard protection.

For organisations, the Managed Apple Account exclusion is the key point. ADP is a personal account control. Corporate data on corporate devices is normally governed by device management and by where the organisation chooses to store it, not by ADP.

What do Stolen Device Protection, inactivity reboot and Lockdown Mode add?

These three features target different threats. Data Protection already covers a phone that is off. These cover a thief who knows your passcode, a phone that sits in AFU too long, and a targeted attacker using sophisticated exploits.

Stolen Device Protection

Stolen Device Protection is for a specific, common crime: someone watches you type your passcode, then takes the phone. With the passcode, they could otherwise change your Apple Account password, turn off Find My and read saved passwords.

According to Apple's support article, when the iPhone is away from familiar locations such as home or work:

• Some actions, such as using saved passwords and payment cards, require Face ID or Touch ID with no passcode fallback.
• Critical changes, such as changing the Apple Account password or adding or removing a trusted device, recovery key or recovery contact, need a biometric check, a one hour Security Delay, then a second biometric check.
• These security settings cannot be changed on the web at account.apple.com while it is on.

It is available on iOS 17.3 or later, must be turned on before the phone is lost, and needs two factor authentication, a passcode, Face ID or Touch ID, Significant Locations and Find My. You cannot turn Find My off while it is enabled. You can choose "Always" so the delay applies even at home. Apple says it might be on by default; check rather than assume.

Inactivity reboot

The inactivity reboot is the one feature in this post that Apple's own pages we checked do not describe. TechCrunch reported on 14 November 2024 that researchers had confirmed iOS 18.1 reboots an iPhone that has not been unlocked for 72 hours, citing a video by Jiska Classen. heise reported that Apple had neither confirmed nor denied it, that the code appears in iOS 18.1, and, from Classen's analysis, that the Secure Enclave counts the 72 hours and that if a process blocks the kernel from rebooting, a kernel panic forces the reboot anyway.

The value is simple: a phone sitting in AFU in a thief's drawer drops back to BFU, discarding the Class C key, and the attacker is back to on device passcode guessing under the delays above.

Android is following. 9to5Google reported on 16 April 2025 that the Google Play services 25.14 release notes described a phone automatically restarting if locked for three consecutive days, and that Google then revised the entry to call it a future optional security feature. Treat the Android timing and availability as unconfirmed until Google's own documentation states it for your devices.

Lockdown Mode

Lockdown Mode, per Apple's support article, is "an optional, extreme protection" for the few people who might be personally targeted by mercenary spyware. It reduces attack surface rather than strengthening encryption. Notable effects:

• Most message attachment types are blocked except certain images, video and audio; links and link previews are off.
• Certain complex web technologies are blocked, and FaceTime calls from people you have not called in 30 days are blocked.
• The iPhone or iPad must be unlocked to connect to an accessory or computer.
• 2G and 3G cellular support is turned off, and the device will not auto join non-secure Wi-Fi.
• Configuration profiles cannot be installed, and the device cannot be enrolled in device management while Lockdown Mode is on. A device enrolled before Lockdown Mode stays managed.

It is available in iOS 16 and later, iPadOS 16, watchOS 10 and macOS Ventura, with more protections from iOS 17. Apple states it is not a configurable option for device management administrators. That matters for policy: an organisation can recommend it to at risk staff but cannot push it.

How does Android's file-based encryption with CE and DE storage compare?

Android's model, documented at source.android.com, solves the same problem in a different way.

Credential Encrypted and Device Encrypted storage

Android 7.0 introduced file based encryption (FBE) and Direct Boot, which lets an encrypted phone boot to the Lock Screen. All devices launching with Android 10 or later are required to use FBE. On an FBE device each user gets two storage locations:

• Credential Encrypted (CE) storage is the default and is available only after the user has unlocked the device. Android's Direct Boot documentation says it stays available until the user restarts the device, which is the AFU behaviour again.
• Device Encrypted (DE) storage is available both in Direct Boot mode and after unlock. Alarms, the phone app and accessibility services use it so they work before first unlock.

Android's documentation is blunt: "Whenever possible, files should reside in CE storage." Each user and each work profile gets its own CE and DE keys, so unlocking one user does not unlock another.

There is also a system DE key for data not tied to any user, per boot keys for ephemeral files, and, from Android 9, metadata encryption that protects file system metadata the per file keys do not cover. For devices launching on Android 11 or later, metadata encryption must be enabled.

How the CE key is protected

Android's chain is worth reading closely because it shows where the hardware does the heavy lifting.

1. Each user has a synthetic password, an immutable high entropy secret generated at random.
2. Each CE key for internal storage is encrypted with AES-256-GCM using a key derived from the synthetic password.
3. LockSettingsService protects the synthetic password with the user's PIN, pattern or password, which Android calls the Lock Screen Knowledge Factor (LSKF). It first stretches the LSKF with scrypt, targeting about 25 ms and about 2 MiB of memory. Android's docs admit that since LSKFs are usually short, this step "usually does not provide much security."
4. The real protection is rate limiting in a secure element or TEE. If the device implements the Weaver HAL, the stretched LSKF is mapped to a high entropy secret stored in the secure element or TEE. If not, the stretched LSKF is used as a Gatekeeper password in the TEE, which throttles repeated failures.
5. All other FBE keys are encrypted with AES-256-GCM under their own Keystore key that never leaves the TEE, so they cannot be unlocked unless a trusted OS booted, as enforced by Verified Boot.

File contents default to AES-256-XTS. Filenames use AES-256-CTS by default, with AES-HCTR2 preferred since Android 14 on devices with crypto acceleration, and Adiantum available for devices without AES acceleration. Since Android 11, new devices must use version 2 fscrypt policies, which derive keys with HKDF-SHA512. Devices whose inline encryption hardware supports it can make FBE keys hardware wrapped.

Samsung Knox Vault

Samsung's Knox documentation describes Knox Vault, on select devices from the Galaxy S21 onward, as an isolated, tamper resistant subsystem with its own processor, memory and dedicated nonvolatile secure storage, independent from the main application processor. Samsung says it protects hardware backed Keystore keys and biometric data, and runs Samsung's Weaver with a binary exponential back off on a non bypassable secure timer. It is the Samsung counterpart to the Secure Enclave plus Secure Storage Component, built on Android's Weaver and StrongBox interfaces.

Side by side

The pattern is the same on both: an always available tier for what must work before unlock, a credential bound tier for everything else, and hardware that keeps passcode guessing slow and on device. Apple's Class A and Class B add finer per file control.

Step by step: checking and enforcing the right protection

These steps are for developers who store sensitive data and for administrators who set policy. None of them change or erase data on a device.

Step 1: set the file protection class in an iOS app

Pick the class by when the app needs the data: Class C for caches, Class A for tokens and personal records unless a background task needs them.

import Foundation

// Write a file that is unreadable whenever the device is locked (Class A).
let url = FileManager.default
    .urls(for: .applicationSupportDirectory, in: .userDomainMask)[0]
    .appendingPathComponent("records.json")
try data.write(to: url, options: [.atomic, .completeFileProtection])

// Change the class of an existing file.
try FileManager.default.setAttributes(
    [.protectionKey: FileProtectionType.complete],
    ofItemAtPath: url.path)

// Read it back to check what the system applied.
let attrs = try FileManager.default.attributesOfItem(atPath: url.path)
print(attrs[.protectionKey] ?? "none")

To raise the default class for the whole app, add the Data Protection capability in Xcode, which sets the com.apple.developer.default-data-protection entitlement, and choose NSFileProtectionComplete. Test background tasks afterwards: a background fetch that tries to read a Class A file while the phone is locked will fail, by design.

Step 2: choose the keychain accessibility class

import Security

let query: [String: Any] = [
    kSecClass as String: kSecClassGenericPassword,
    kSecAttrService as String: "com.example.api",
    kSecAttrAccount as String: "refresh-token",
    kSecValueData as String: tokenData,
    // Readable only while unlocked, never leaves this device, not in backups.
    kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlockedThisDeviceOnly
]
let status = SecItemAdd(query as CFDictionary, nil)

Use kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly only for items a background task genuinely needs while locked. Avoid kSecAttrAccessibleAlways, which leaves the item readable at any time. For the highest assurance, kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly makes the item disappear if the user removes the passcode.

Step 3: keep Android data in CE storage, and DE only when needed

<!-- AndroidManifest.xml: only components that must run before first unlock -->
<receiver
    android:name=".AlarmReceiver"
    android:directBootAware="true"
    android:exported="false">
    <intent-filter>
        <action android:name="android.intent.action.LOCKED_BOOT_COMPLETED" />
    </intent-filter>
</receiver>

// Use DE storage only for the minimum data needed before unlock.
val deContext = applicationContext.createDeviceProtectedStorageContext()
val alarmPrefs = deContext.getSharedPreferences("alarms", Context.MODE_PRIVATE)

// Everything else waits for CE storage.
val userManager = getSystemService(UserManager::class.java)
if (userManager.isUserUnlocked) {
    // safe to read normal (CE) files and preferences
}

Android's Direct Boot guide also offers ACTION_USER_UNLOCKED to learn when CE storage becomes available. Do not put tokens, messages or personal data in DE storage.

Step 4: confirm FBE on an Android test device

Android's validation guidance lists two properties to check. These commands only read properties.

adb shell getprop ro.crypto.state   # expected: encrypted
adb shell getprop ro.crypto.type    # expected: file

On a userdebug or eng build, Android's docs suggest setting a PIN, rebooting, and listing the main user's CE directory before unlocking to confirm names are encrypted. Production devices will not allow adb root, which is expected.

Step 5: enforce passcode policy through device management

Apple's legacy Passcode payload keys (minLength, maxInactivity, maxGracePeriod and others) are marked deprecated from iOS 27 in Apple's device management reference. The replacement is the declarative configuration com.apple.configuration.passcode.settings, available from iOS 15 and macOS 13. A minimal declaration looks like this.

{
  "Type": "com.apple.configuration.passcode.settings",
  "Identifier": "com.example.passcode.policy",
  "Payload": {
    "RequirePasscode": true,
    "MinimumLength": 6,
    "MaximumFailedAttempts": 10,
    "MaximumInactivityInMinutes": 5,
    "MaximumGracePeriodInMinutes": 0
  }
}

MaximumGracePeriodInMinutes of 0 means the passcode is needed immediately after lock, which is also the setting that gives Class A its roughly 10 second discard window. Apple's device management reference says delays begin after the sixth failed attempt and that if the maximum is six or lower, the device erases or locks as soon as the limit is passed. That wording differs from the Platform Security guide's Lock Screen table, which shows the first delay at the fourth attempt, so test the behaviour on your OS version before you write it into a policy.

What should an organisation require in mobile policy?

NIST SP 800-124 Rev. 2, published in May 2023, is the reference for managing mobile devices in the enterprise across deployment, use and disposal, for both organisation provided and personally owned devices. Its recommendations are general. The mechanisms above let you turn them into specific rules.

One caution: a policy that only checks encryption is "on" is incomplete, because on current iPhones and Android 10 and later devices it always is. What you control is when data is decryptable, how many guesses an attacker gets, and how current the software guarding AFU is.

Where Safeguard fits, honestly

Safeguard does not manage phones, enforce passcodes, inspect firmware or protect endpoints, and nothing in this post is something Safeguard does on a device. The honest connection is the software your organisation builds for those devices. A mobile app that stores tokens in the wrong keychain class or files in the wrong protection class is a code problem, and the open source libraries inside that app, and inside the backend it talks to, are a dependency problem. Safeguard scans repositories, container images and SBOM files for vulnerable components, shows which projects carry a given component and version, ranks findings with reachability analysis, and can open fix pull requests when you switch that on. Reviewing which protection class your own code requests is still a job for your developers and your code review.

Common mistakes

• Assuming "encrypted" means "unreadable when locked". On iOS, Class C is the default for third party apps and is readable in AFU. On Android, CE storage is readable until reboot.
• Storing tokens with kSecAttrAccessibleAfterFirstUnlock by habit. Use it only when a background task needs the item while locked, and prefer the ThisDeviceOnly variant.
• Putting user data in Android DE storage to make Direct Boot work. Only the minimum needed before unlock belongs there.
• Relying on short numeric passcodes because "the hardware protects it". The hardware limits guesses to about ten; a common code can be among them.
• Leaving the grace period above zero. Class A data stays readable for the grace period after the screen locks.
• Treating ADP as a corporate control. It is not available for Managed Apple Accounts, and Mail, Contacts and Calendar stay outside it anyway.
• Forgetting encrypted local backups. The backup keybag is protected by the backup password and is not device bound.
• Expecting to push Lockdown Mode. Apple does not offer it as a device management setting; and a device in Lockdown Mode cannot be newly enrolled.
• Citing the inactivity reboot as an Apple guarantee. It is reported by researchers and not documented in the Apple pages we checked; do not build a control around its exact timing.

FAQ

What is the Secure Enclave on iPhone?

It is a dedicated security subsystem inside Apple's system on chip with its own processor running sepOS, its own boot ROM, random number generator, AES engine and encrypted memory. It holds and uses keys derived from a device unique UID, enforces passcode attempt limits and handles biometric data, and it is designed to stay secure even if iOS itself is compromised.

What are iOS Data Protection classes?

They are four rules that decide when a file's key can be unwrapped: Complete Protection (Class A, only while unlocked), Protected Unless Open (Class B, writable while locked), Protected Until First User Authentication (Class C, after first unlock until reboot) and No Protection (Class D, always, protected by the device UID). Apps assign a class per file.

What is the difference between BFU and AFU on iPhone?

BFU, Before First Unlock, is the state after a restart before the passcode has been entered; almost all user data is unreadable. AFU, After First Unlock, is after the first passcode entry; Class C data, the default for third party apps, stays decryptable until the next restart even while the screen is locked.

Can Apple decrypt my iPhone?

Apple's guide says the UID is generated inside the Secure Enclave and is not available to Apple or its suppliers, and that the passcode is entangled with it, so data on the device cannot be decrypted without the passcode on that device. iCloud is different: under standard data protection Apple holds keys for most categories; with Advanced Data Protection it does not hold them for most categories.

How long would it take to brute force an iPhone passcode?

Apple calibrates each attempt to about 80 milliseconds, so ignoring other limits a six digit code takes up to about 22 hours and a six character lowercase alphanumeric code more than five and a half years. In practice the Secure Enclave's escalating delays and, on newer devices, the counter lockbox limit an attacker to around ten attempts.

Does Advanced Data Protection encrypt iCloud Mail and Contacts?

No. Apple says iCloud Mail, Contacts and Calendar are not end to end encrypted because they must interoperate with global email, CardDAV and CalDAV. Some metadata, such as modification dates and file checksums, also stays under standard protection.

Does Stolen Device Protection stop a thief who knows my passcode?

It limits what they can do away from your familiar locations. Saved passwords and payment cards need Face ID or Touch ID with no passcode fallback, and changes like the Apple Account password need biometrics, a one hour delay and biometrics again. It must be turned on before the phone is stolen.

Can an MDM force Lockdown Mode on employee iPhones?

No. Apple's support article states Lockdown Mode is not a configurable option for device management administrators. A device already enrolled before the user turns it on stays managed, but a device in Lockdown Mode cannot be newly enrolled.

Fix it without waiting for upstream

A phone's encryption is only as good as the software asking for keys, and every corporate mobile app and the backend behind it is built from open source components that need patching like anything else. The fit here is indirect, since none of what follows touches the Secure Enclave or a device, but it does keep the code your teams ship to those devices current.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos touch a phone's encryption; they show how the software around it gets kept current with a person approving each step. You can download the CLI from https://safeguard.sh/download and read the setup guide at https://docs.safeguard.sh/docs/cli .

The first demo is a real CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repo, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to the backend or build tooling of a mobile app: a dependency gets moved to a fixed version, tests run, and nothing happens without your say.

Click through it at your own pace, or open it full screen.

The second demo is a real Android session: you send work to a computer running the CLI and approve each command on the phone with Allow once, Allow for turn or Deny. It is a fitting pair for this post. The phone in your hand is the approval point, and the work runs on the computer where the code lives.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Granting only the tools a task needs is the same thinking as choosing kSecAttrAccessibleWhenUnlockedThisDeviceOnly over kSecAttrAccessibleAlways: give access only when and where it is needed.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Apple Platform Security: The Secure Enclave
• Apple Platform Security: Data Protection overview
• Apple Platform Security: Data Protection classes
• Apple Platform Security: Keybags for Data Protection
• Apple Platform Security: Passcodes and passwords
• Apple Platform Security: Keychain data protection
• Apple Platform Security: Sealed Key Protection (SKP)
• Apple Platform Security: Advanced Data Protection for iCloud
• Apple Support: iCloud data security overview
• Apple Support: About Stolen Device Protection for iPhone
• Apple Support: About Lockdown Mode
• Apple Developer: Passcode payload (device management)
• Apple Developer: PasscodeSettings declarative configuration
• Android Open Source Project: File-based encryption
• Android Open Source Project: Metadata encryption
• Android Open Source Project: Gatekeeper
• Android Developers: Support Direct Boot mode
• Samsung Knox documentation: Knox Vault
• NIST SP 800-124 Rev. 2: Guidelines for Managing the Security of Mobile Devices in the Enterprise
• TechCrunch: New Apple security feature reboots iPhones after 3 days, researchers confirm (14 November 2024)
• heise: Reboot after inactivity, how Apple's new iOS security feature works
• 9to5Google: Android auto restart security feature (16 April 2025)

Last reviewed: 24 October 2026. Apple and Google change these features between releases; check the linked Platform Security guide and Android documentation for your OS version before setting policy.