When Apple launched iMessage PQ3 in February 2024, coverage declared that iPhones were now quantum-safe. When Google deployed hybrid post-quantum TLS through Chrome, similar statements followed. Both claims require qualification. "Post-quantum on mobile" is not a single thing. It describes at least four distinct cryptographic layers on a device, each with a different migration status. No mobile platform has completed migration across all of them, and a security assessment cannot be done by looking at one layer in isolation.

This article maps what Apple and Google have actually deployed, what remains on classical cryptography, and what enterprise mobility managers need to ask about their fleet.

The Four Layers That Matter

A meaningful PQC assessment of a mobile device must address each of these separately:

  • Layer 1: Messaging applications. Signal PQXDH, iMessage PQ3, WhatsApp. Application-layer changes that do not depend on the OS providing PQC.
  • Layer 2: Platform TLS. HTTPS connections from apps and the browser, using the platform TLS stack. iOS Network.framework and Android Conscrypt are the relevant components.
  • Layer 3: Hardware security primitives. The Secure Enclave on Apple devices, Android Keystore backed by TEE or StrongBox. Device attestation certificates for MDM and zero-trust access. These are the components that have moved least.
  • Layer 4: Developer-facing APIs. CryptoKit on iOS, the Android Keystore API and Conscrypt provider API on Android. Whether app developers can build PQC-using apps without bundling their own crypto library.

News coverage has focused on Layer 1. Layer 2 has moved significantly. Layers 3 and 4 are the gaps that matter most for enterprise deployments.

iOS: Layer-by-Layer Status

Apple's PQC deployment began with iOS 17.4 in March 2024 and expanded materially with iOS 18 in September 2024.

iMessage (Layer 1): PQ3, using ML-KEM-768 (FIPS 203, formerly Kyber) for initial key establishment and periodic ML-KEM re-keying throughout the conversation. Deployed on all devices running iOS 17.4 and later, with no user action required. This is the most widely covered element. For a detailed breakdown of what PQ3 does and does not protect against the HNDL threat, see the companion article on quantum-secure messaging and the Signal Protocol.

TLS (Layer 2): iOS 17.4 and later negotiate X25519MLKEM768 hybrid key exchange (per RFC 9496) for HTTPS connections through Network.framework and URLSession. This means HTTPS connections from iOS 17.4+ apps automatically use the hybrid construction when the server supports it, without developer intervention. The benefit covers all platform-TLS traffic, not just iMessage. This layer-2 deployment is underreported relative to PQ3.

Developer ML-KEM API (Layer 4): iOS 18 added public ML-KEM support to the Apple CryptoKit framework, exposing ML-KEM-512, ML-KEM-768, and ML-KEM-1024. Third-party app developers can build ML-KEM key establishment into their applications without implementing the algorithm themselves or bundling a separate crypto library. [ASSUMED: CryptoKit ML-KEM parameter set availability confirmed for iOS 18; verify whether ML-DSA has been added in iOS 18 or 18.x point releases before publication.]

Secure Enclave (Layer 3): Classical. As of iOS 17.4, ML-KEM operations for iMessage PQ3 run on the application processor, not inside the Secure Enclave. The Secure Enclave handles ECDH identity keys; the PQ3 ML-KEM prekeys are not hardware-resident in the same way. Apple has not published a roadmap for Secure Enclave ML-KEM support. For enterprise security assessments, this means ML-KEM private keys in PQ3 do not have the same hardware-backed protection as the device's classical identity keys.

MDM and code signing (Layer 3): Classical. MDM profile signing uses PKCS#7 with classical signature algorithms. App Store code signing uses classical ECDSA. Neither has been migrated to ML-DSA. For enterprise deployments where zero-trust network access relies on hardware-backed device attestation, the attestation certificate chain remains classically vulnerable.

Android: Layer-by-Layer Status

Android's delivery mechanism differs fundamentally from iOS. Android Mainline (Project Mainline) allows Google to push updates to core platform modules, including Conscrypt, through Google Play System Updates without requiring OEM involvement or a full OS update. This gives Android's Layer 2 significantly more update agility than is often assumed.

TLS via Conscrypt/BoringSSL (Layer 2): Google integrated ML-KEM-768 into BoringSSL (its OpenSSL fork underlying Conscrypt) and deployed hybrid X25519MLKEM768 TLS. Chrome shipped the finalised X25519MLKEM768 construction (per RFC 9496) in Chrome 131, released November 2024. [INFERRED: Chrome 131 as the X25519MLKEM768 finalisation version; verify the specific version before publication.] Applications using the Android platform TLS stack receive this protection via Mainline module updates. Android's Mainline delivery model means the TLS layer can be updated across billions of devices without requiring OEM cooperation or a full Android version bump. For the TLS layer, this is a genuine architectural advantage over iOS, which requires a full OS update for equivalent changes.

Signal on Android (Layer 1): Signal has run PQXDH since September 2023. Signal uses its own cryptographic library, libsignal, for all Signal Protocol operations and does not rely on the Android OS to provide ML-KEM. Even on Android versions without platform ML-KEM support, Signal provides post-quantum session key establishment through its bundled library. For post-quantum VPN implementations and other application-layer PQC, the same pattern applies: the application bundles its own library rather than depending on platform support.

Android Keystore (Layer 3): Classical. Android 14's Keystore API does not include ML-KEM or ML-DSA as hardware-backed key types. Adding PQC to hardware-backed Keystore operations requires OEM and chipset vendor cooperation for the TEE and StrongBox layers; Google alone cannot deliver this via a Mainline update. [ASSUMED: Android 15 Keystore PQC status; verify whether Android 15 or any Android Mainline update has added ML-KEM or ML-DSA to the Keystore API before publication.]

Key attestation (Layer 3): Classical. Android hardware-backed key attestation uses ECDSA or RSA attestation certificates. Neither Android 14 nor 15 includes ML-DSA attestation support. For enterprise ZTNA deployments that validate device identity through hardware-backed attestation, the attestation chain remains a classical vulnerability point.

Apps with bundled crypto libraries (Layer 2, partial): Apps that bundle their own TLS or networking libraries, common in enterprise applications, banking apps, and apps with custom Rust network layers, bypass Conscrypt entirely. Platform-level PQC TLS updates do not protect traffic from those apps until the bundled library is updated. This is an Android-specific gap that requires application-level inventory to assess properly.

Head-to-Head: What Is and Is Not Deployed

Feature iOS 17.4 / 18 Android (Mainline, 2024+)
Messaging PQC (iMessage / Signal) ML-KEM-768 PQ3 (iOS 17.4+) Signal PQXDH (app layer, libsignal)
Platform TLS hybrid PQC X25519MLKEM768 (iOS 17.4+) X25519MLKEM768 via Conscrypt / Chrome
Developer ML-KEM API CryptoKit ML-KEM-512/768/1024 (iOS 18+) Conscrypt provider access (limited public API) [ASSUMED]
Hardware-backed PQC keys Not yet (Secure Enclave: classical) Not yet (Keystore: classical)
Key attestation PQC Not yet (PKCS#7 / ECDSA) Not yet (ECDSA / RSA attestation)
Native VPN client PQC Not in native iOS VPN client Not in native Android VPN client
App Store / Play Store code signing Classical ECDSA (not migrated) Classical (not migrated)

PQC status as at July 2026. Verify before security decisions. Sources: Apple Platform Security Guide, Android security documentation, NIST FIPS 203/204.

Neither platform supports post-quantum digital signatures in a way that matters for enterprise code signing and device attestation. For how ML-DSA differs from ECDSA and why the signature size increase affects attestation workflows, that article explains the mechanics without assuming a cryptography background.

The CNSA 2.0 Gap

Commercial iOS and Android both deploy ML-KEM-768 for TLS hybrid key exchange (Layer 2). NSA CNSA 2.0 specifies ML-KEM-1024 as the minimum for National Security Systems (NSS). Commercial mobile deployments with ML-KEM-768 do not meet CNSA 2.0 requirements for NSS-classified applications. This does not mean commercial mobile platforms are inadequate for their intended use; it means that classified-grade mobile endpoints must be evaluated against CNSA 2.0 parameter requirements independently of the general consumer/enterprise platform status.

Under NIST IR 8547 (November 2024, initial public draft), ECDSA is on a deprecation schedule with planned disallowed status by 2030 for new deployments in security categories 2 and above. Mobile device attestation, MDM profile signing, and App Store code signing all use ECDSA. Enterprise fleet planning through 2028 to 2031 should include PQC migration status across these components as a hardware and OS refresh criterion, not just a messaging application consideration.

Three Questions for Enterprise Mobility Managers

Assessing a mobile fleet for post-quantum readiness reduces to three questions.

What is the minimum OS version in your MDM fleet? iOS 17.4 and later, and Android devices with current Mainline modules, have TLS PQC through the platform stack. Devices below iOS 17.4 or with stale Mainline modules use classical TLS only. The floor matters: a fleet with 15% of devices on iOS 16 has 15% of its platform TLS coverage on a classical-only stack.

Which apps handling sensitive data bundle their own crypto libraries? Bundled network and crypto libraries bypass platform PQC updates on Android. This requires an application inventory, not just a fleet OS version check. Enterprise apps and banking applications are the common cases. Your MDM's app catalogue should identify which applications use platform Conscrypt versus bundled alternatives.

What is your MDM vendor's PQC roadmap for profile signing and attestation? MDM profile delivery and device attestation for zero-trust access remain on classical ECDSA across all major platforms. If hardware-backed attestation is part of your ZTNA policy enforcement, those attestation chains are not post-quantum. Ask your MDM vendor specifically about ML-DSA support for profile signing and whether their device attestation chain has a published PQC migration timeline.