What iPhone encryption means for enterprise mobile security

Message encryption

Apple's native messaging system for iOS and macOS, iMessage, has supported end-to-end encryption since 2011. That means that messages sent between Apple devices using iMessage are encrypted both in transit and at rest. As such, neither Apple nor any third party can read iMessage content.

When it comes to cross-platform messages between iPhone and Android devices, users historically were stuck falling back to regular SMS, without encryption. That changed with the release of iOS 18, which added support for Rich Communication Services (RCS). This shift introduced read receipts, higher resolution media sharing and better group messaging.

As of iOS 26.5, the RCS implementation supports end-to-end encryption as a beta feature. The effort to bring end-to-end encryption to RCS was a multi-stage process and is enabled through the RCS Universal Profile 3.0, which implements encryption based on the Messaging Layer Security protocol.

With encrypted RCS messages, IT teams cannot access content. Organizations with compliance or e-discovery requirements should address this in their respective mobile governance policies. It's important to note, however, that RCS encryption depends on carrier support and is not universally adopted. Where carrier support exists, encryption is on by default.

Hardware-level encryption

Each iOS device includes a dedicated Advanced Encryption Standard (AES) cryptography engine to support hardware-level iPhone encryption, and it sits between the system memory and flash storage. This engine works in conjunction with the device's unique identifier (UID) to segregate system operations and cryptographically tie data to the device. The UID is an AES 256-bit encryption key fused into the application processor and Secure Enclave during manufacturing.

Software that runs on the Secure Enclave -- a coprocessor security chip -- uses the UID to protect sensitive device information. The Secure Enclave also processes fingerprint and facial feature data associated with Touch ID and Face ID. In addition, the Secure Enclave carries out all cryptographic operations related to file-level encryption. Communication between the Secure Enclave and the application processor is isolated and highly controlled.

There's much more to hardware-level encryption, but the important point for IT teams to understand is that an iOS device automatically uses advanced cryptographic techniques to protect core system functions. These hardware-level security capabilities also provide a foundation for file-level data security, a feature known as Data Protection.

File-level encryption

The Data Protection feature on iOS devices encrypts data on the device's flash drive by assigning a new 256-bit key to each file when a user or administrator creates it. On iOS devices that support the Apple File System, IT can assign keys on a per-extent basis. This means different parts of a single file receive different keys.

Each file key is wrapped in one of several key classes that determine when and how the file can be accessed. The app that creates the file assigns a class to it, and the Secure Enclave manages all wrapped file keys so they're never directly exposed to the app.

File-level encryption covers on-device storage, but when users back up to Apple's iCloud, the situation changes. Apple retains the encryption keys on its own servers and can decrypt data in the event of a valid legal request. Advanced Data Protection, enabled through a user's Apple ID, extends end-to-end encryption to iCloud backup and removes Apple's ability to decrypt. In BYOD environments, IT can't force this setting as it's tied to the user's personal Apple ID rather than a managed account.

Data Protection ensures that each file on the device's flash drive is encrypted. Unlike hardware-level iPhone encryption, however, the feature is not enabled out of the box. To deploy these file-level encryption policies, IT must enable the passcode feature on the desired iOS devices.

Encryption relies on passcodes

The Data Protection feature is inextricably tied to passcodes in iOS. This is because a user's passcode is linked with their device's UID. An attacker can't access data in the protected classes without the passcode, which is why organizations should always require passcodes on their managed iOS devices.

Passcodes ensure that file data is encrypted. They also protect against brute-force attacks by escalating the time delays after each consecutive failed passcode attempt. For example, in iOS, the time delay is five minutes after five failed attempts, but after seven failed attempts, the delay is one hour. In addition, IT can configure its devices to automatically wipe the data after 10 failed attempts.

Passcodes ensure that file data is encrypted.

Organizations can manage a device's passcode settings and requirements through an MDM or UEM tool such as Omnissa Workspace One UEM or Ivanti Neurons for MDM. With these tools, IT can specify whether a passcode is required, the complexity of that passcode and several other settings. The more complex a user's passcode is, the stronger the file-level encryption, though longer passcodes create more friction for users. If the managed devices support Touch ID or Face ID, it's suitable for admins to require a much more complex passcode, as users don't have to supply it as frequently.

Best practices for iPhone encryption

IT teams managing iOS devices should apply the following practices to maintain a strong mobile security posture:

• Require passcodes on all managed devices. Passcodes activate file-level data protection. Without a passcode, that encryption is not enabled.
• Enforce passcode complexity and automatic wipe through a UEM platform. UEM platforms enable IT to set complexity requirements and configure automatic data wipe after repeated failed attempts.
• Restrict or manage iCloud backup access through MDM. By default, iCloud backups can be decrypted by Apple servers under legal process. IT should either restrict backup entirely or communicate to users the value of enabling Advanced Data Protection through their Apple ID.
• Account for message encryption limits in compliance policies. Neither iMessage nor RCS message content is accessible to admins. Organizations with e-discovery or legal hold requirements should address this gap in their mobile governance policies.
• Evaluate device ownership for regulated roles. In BYOD environments, IT visibility is significantly reduced. Employees in roles subject to data retention or regulatory requirements might need corporate-owned devices instead.

Editor's note: This article was originally written by Robert Sheldon in July 2019. Sean Michael Kerner updated and expanded this article in July 2026 to reflect current Apple features and include information on message encryption.

Sean Michael Kerner is an IT consultant, technology enthusiast and tinkerer. He has pulled Token Ring, configured NetWare and been known to compile his own Linux kernel. He consults with industry and media organizations on technology issues.

Robert Sheldon is a freelance technology writer. He has written numerous books, articles and training materials on a wide range of topics, including big data, generative AI, 5D memory crystals, the dark web and the 11th dimension.