Encryption in Mobile Devices: iOS and Android Standards

Mobile device encryption governs how smartphones and tablets protect stored data, transmitted communications, and authentication credentials from unauthorized access. Both Apple's iOS and Google's Android platforms implement encryption at the hardware and software levels, but the two systems follow distinct architectural models, use different default configurations, and are subject to overlapping US federal and sector-specific compliance requirements. This page describes the encryption frameworks used in each platform, the mechanisms by which they operate, the scenarios in which each applies, and the decision boundaries professionals encounter when evaluating mobile encryption for regulated environments.

Definition and scope

Mobile device encryption is the application of cryptographic algorithms to data stored on a handset or tablet — including user files, application data, credentials, and system state — so that the data remains unintelligible without the correct key material. The scope extends beyond storage to encompass data in transit (email, messaging, VPN tunnels) and data tied to biometric or PIN-based authentication unlock sequences.

Both iOS and Android platforms mandate full-disk or file-based encryption as a baseline on hardware meeting modern specifications. The National Institute of Standards and Technology (NIST) addresses mobile cryptographic requirements in NIST SP 800-124 Rev. 2, "Guidelines for Managing the Security of Mobile Devices in the Enterprise," which sets out baseline cryptographic controls for federal agency device management. At the sector level, the Health Insurance Portability and Accountability Act Security Rule (45 CFR § 164.312(a)(2)(iv)) and the Payment Card Industry Data Security Standard (PCI DSS) both reference device-level encryption as an addressable or required safeguard, depending on the data classification involved.

For professionals navigating the broader field of cryptographic standards, the encryption providers catalogued on this platform include service providers and compliance specialists operating across mobile and enterprise contexts.

How it works

iOS Encryption Architecture

Apple implements a layered cryptographic architecture built around a dedicated security subsystem — the Secure Enclave — present in all iPhone and iPad models using Apple A-series chips (from the A7 onward, introduced with the iPhone 5s in 2013). The Secure Enclave is a hardware-isolated coprocessor that generates, holds, and never exposes device-unique encryption keys to the main application processor.

iOS uses file-based encryption (FBE), introduced with iOS 9 and made the default from iOS 10 onward. Under FBE, each file is encrypted with a unique per-file key, which is itself wrapped by a class key. Apple defines four protection classes:

1. Complete Protection — key discarded when device locks; file inaccessible until unlock
2. Protected Unless Open — key held in memory if a file was open before lock
3. Protected Until First User Authentication — key held from first unlock until reboot
4. No Protection — encrypted but key accessible at any device state

The encryption algorithm is AES-256 for file content, conforming to FIPS 197 (the AES standard published by NIST). The full technical specification is documented in the Apple Platform Security Guide, updated with each major OS release.

Android Encryption Architecture

Android adopted full-disk encryption (FDE) as a requirement for most new devices beginning with Android 6.0 (2015), then transitioned to file-based encryption (FBE) as the mandatory standard from Android 10 onward (Android Security Documentation, Google). Android's FBE implementation uses the Linux kernel's fscrypt framework.

Android defines two storage areas under FBE:

1. Credential Encrypted (CE) storage — decrypted only after the user authenticates with PIN, password, or biometric
2. Device Encrypted (DE) storage — accessible immediately after boot, used for system functions that must operate before unlock (e.g., alarm clocks, accessibility services)

The required cipher suite is AES-256-XTS for file content encryption and AES-256-CBC or AES-256-HEH for file name encryption, per Android Compatibility Definition Document (CDD) requirements. Devices with dedicated cryptographic accelerators may additionally use hardware-backed keystore operations through Android's StrongBox Keymaster, a tamper-resistant hardware security module analogous in function to Apple's Secure Enclave.

iOS vs. Android: Structural Contrast

A key structural difference is OEM fragmentation on Android: while Google's own Pixel line ships with the Titan M security chip, other manufacturers implement hardware security at varying levels of capability. iOS enforces a single hardware security model across all supported devices.

Common scenarios

Enterprise Device Management
Organizations deploying managed mobile fleets under Mobile Device Management (MDM) platforms — such as those governed by NIST SP 800-124 Rev. 2 — rely on both platforms' encryption models to enforce remote-wipe capabilities and data container separation. iOS enforces managed app data in separate encrypted containers; Android Enterprise enforces a work profile with independent key material from personal storage.

Healthcare and HIPAA-Covered Entities
Under 45 CFR § 164.312(a)(2)(iv), covered entities must implement encryption where required and document their rationale where they do not. Mobile devices accessing electronic protected health information (ePHI) fall within scope. Both iOS's Complete Protection class and Android's CE storage mode satisfy the technical requirement when properly configured with strong PINs or passwords.

Law Enforcement and Legal Access
Both platforms' encryption architectures have been subjects of federal legal proceedings. The FBI's 2016 dispute with Apple over access to an iPhone 5c running iOS 9 established that hardware-backed encryption, absent a backdoor, renders device content inaccessible even to the manufacturer. Android devices present a more variable posture depending on OEM hardware security implementation.

Federal Agency Deployments
The Federal Risk and Authorization Management Program (FedRAMP) and Department of Defense (DoD) Unified Capabilities Requirements both reference NIST SP 800-124 when evaluating mobile platform suitability. Agencies procuring mobile solutions consult the framework to identify vendors holding relevant compliance attestations.

Decision boundaries

The choice between iOS and Android for a regulated deployment, or the configuration depth required within either platform, depends on four structural criteria:

1. Hardware security consistency requirement — If the compliance framework requires uniform, auditable hardware-backed key storage across all deployed devices, iOS provides a single consistent architecture. Android's hardware security posture is a function of the specific OEM and device SKU.

2. Data classification and protection class selection — Not all applications require Complete Protection (iOS) or CE storage (Android). System functions, shared calendars, or pre-boot accessibility services legitimately use lower protection classes. Misassigning protection classes downward for performance reasons without documented rationale can constitute a HIPAA or PCI DSS gap.

3. Key management scope — Both platforms expose key management APIs to enterprise MDM operators. However, neither platform exposes the root device key to the MDM layer — wipe operations destroy key material rather than exfiltrate it. Organizations requiring escrow of device key material cannot achieve this through native OS mechanisms on either platform.

4. FIPS 140 validation status — Federal agencies subject to FIPS 140-3 requirements must verify the validation status of the cryptographic modules in use. Apple's Secure Enclave and CoreCrypto modules have held FIPS 140-2 validations (certificates verified on the NIST Cryptographic Module Validation Program database). Android's validation status varies by device and OS version; the CMVP database is the authoritative verification source.

Professionals assessing mobile encryption deployments will find further classification context in the how-to-use-this-encryption-resource reference, which describes how service categories and standards are organized across this platform.