Android Post-Quantum Support in 2026
Google announced in March 2026 that it is implementing post-quantum cryptography across the entire Android security stack, with the first production deployment arriving in Android 17. This is not a distant roadmap item. Android 17 beta already includes PQC enhancements, and the production release ships these capabilities to devices.
This article details exactly what is available, on which Android versions, through which APIs, and what remains unsupported. The distinction between what ships in the OS, what ships via Mainline module updates, and what requires app-level implementation matters significantly for developers planning their own PQC adoption.
The Android cryptography stack
Understanding PQC on Android requires understanding the layered architecture:
- BoringSSL - The C/C++ cryptographic library (Google’s OpenSSL fork)
- Conscrypt - Java Security Provider that wraps BoringSSL, providing TLS and JCE APIs
- Android Keystore - Hardware-backed key storage with system-level crypto operations
- Chrome/WebView - Browser TLS handled separately from app TLS
Each layer has its own PQC status, and they do not all move at the same pace.
BoringSSL: PQC foundation since August 2024
BoringSSL added support for X25519MLKEM768 (hybrid key agreement combining X25519 ECDH with ML-KEM-768) in August 2024. This is the foundational implementation that enables PQC across all Android components that use BoringSSL for TLS.
The implementation supports both the final NIST standard ML-KEM (codepoint 0x11EC for X25519MLKEM768) and the earlier draft Kyber form (codepoint 0x6399 for X25519Kyber768Draft00). The standard version is what matters for new deployments.
BoringSSL also includes ML-DSA implementations. Since BoringSSL ships as part of Android’s system libraries and the Conscrypt Mainline module, its capabilities propagate to devices through module updates without requiring full OS upgrades.
Conscrypt: The TLS gateway
Conscrypt is Android’s Java Security Provider. It uses BoringSSL as its native backend and provides the TLS implementation for nearly all Android apps that use HttpsURLConnection, SSLSocket, or OkHttp (which delegates to the platform SSL implementation by default).
Mainline module advantage
Conscrypt is a Project Mainline module, which means Google can update it independently of the device OEM’s firmware updates. This is critical for PQC adoption because it means:
- PQC TLS support can reach devices without waiting for Android version upgrades
- Google controls the update timeline, not device manufacturers
- Devices running Android 12 and later receive Mainline module updates via Google Play System Updates
Current PQC capabilities in Conscrypt
| Feature | Status | Delivery mechanism |
|---|---|---|
| X25519MLKEM768 hybrid key exchange (client) | Shipping | Mainline module update |
| TLS 1.3 with PQ key agreement | Shipping | Mainline module update |
| ML-DSA signature verification in TLS | Planned | Future Mainline update |
| ML-KEM standalone API (JCE) | Android 17 | OS release |
When your Android app makes an HTTPS connection to a server that supports X25519MLKEM768, the TLS handshake will negotiate post-quantum key exchange automatically if the device has a recent Conscrypt module. The app developer does not need to change any code for this to happen.
Which Android versions get PQ TLS?
Because Conscrypt is a Mainline module, PQ TLS support is not strictly tied to the Android version number. However, the Mainline module infrastructure requires:
- Android 12+: Full Mainline module update support via Google Play
- Android 10-11: Limited Mainline support (some modules updatable, but earlier versions of the framework)
- Android 9 and below: No Mainline updates; Conscrypt is frozen at the OS version
In practice, devices running Android 12 or later with current Google Play System Updates should support X25519MLKEM768 for outbound TLS connections. The exact rollout timing depends on Google’s staged deployment of the Conscrypt module update.
Chrome on Android: PQ since November 2024
Chrome on Android operates its own TLS stack (also BoringSSL-based, but compiled into Chrome rather than using the system Conscrypt). Chrome 131, released in November 2024, made X25519MLKEM768 the default key agreement for all TLS 1.3 connections.
This means:
- Web browsing through Chrome on Android has had post-quantum key exchange since late 2024
- This applies regardless of Android version (as long as Chrome can update via Play Store)
- Chrome on Android 8.0+ supports this, since Chrome manages its own TLS library
Chrome does not yet support post-quantum signatures in TLS certificates. Google is developing Merkle Tree Certificates as an alternative approach to traditional X.509 post-quantum certificates, but this is still in the feasibility study phase.
Android 17: Full PQC stack
Android 17 represents the first Android release with comprehensive PQC support built into the OS itself, rather than relying solely on Mainline module updates for the TLS layer.
Android Keystore PQC support
Android 17 adds native PQC algorithm support to the Android Keystore:
| Algorithm | Key type | API | Status |
|---|---|---|---|
| ML-DSA-65 | Signing | KeyPairGenerator | Production (Android 17) |
| ML-DSA-87 | Signing | KeyPairGenerator | Production (Android 17) |
| ML-KEM-768 | Key encapsulation | KeyPairGenerator | Production (Android 17) |
Developers can generate post-quantum key pairs using the standard KeyPairGenerator API:
KeyPairGenerator kpg = KeyPairGenerator.getInstance("ML-DSA-65", "AndroidKeyStore");
kpg.initialize(new KeyGenParameterSpec.Builder(
"my-pqc-key",
KeyProperties.PURPOSE_SIGN | KeyProperties.PURPOSE_VERIFY)
.build());
KeyPair keyPair = kpg.generateKeyPair();This means applications targeting Android 17 can generate, store, and use post-quantum keys with hardware backing on supported devices.
Verified Boot and firmware signing
Google’s March 2026 announcement described PQC as a “comprehensive architectural upgrade” being rolled out across the operating system. This includes protections at the firmware level, where PQC signatures protect the boot chain. Android’s Verified Boot ensures that the operating system has not been tampered with, and post-quantum signatures in this layer protect against an attacker who might use a quantum computer to forge firmware signatures in the future.
RKP (Remote Key Provisioning)
Android’s Remote Key Provisioning system, which provides attestation keys to devices, is being upgraded with PQC. This ensures that hardware attestation remains trustworthy even in a post-quantum world. The exact timeline for the RKP PQC rollout beyond Android 17 beta testing is not yet publicly documented.
What about older Android versions?
The PQC story differs significantly depending on the Android version:
Android 14-16 (current flagship devices)
- TLS key exchange: PQ-capable via Conscrypt Mainline updates (X25519MLKEM768)
- Keystore PQC algorithms: Not available (requires Android 17)
- Chrome PQ key exchange: Available via Chrome app updates
- App-level PQC crypto: Possible via bundled libraries (see below)
Android 12-13
- TLS key exchange: PQ-capable via Conscrypt Mainline updates
- Keystore PQC algorithms: Not available
- Chrome PQ key exchange: Available via Chrome app updates
- App-level PQC crypto: Possible via bundled libraries
Android 10-11
- TLS key exchange: Limited Mainline support; PQ may or may not be available
- Keystore PQC algorithms: Not available
- Chrome PQ key exchange: Available via Chrome app updates
- App-level PQC crypto: Possible via bundled libraries
Android 9 and below
- TLS key exchange: Not PQ-capable (frozen Conscrypt)
- Keystore PQC algorithms: Not available
- Chrome PQ key exchange: Chrome updates may still work if the device meets minimum Chrome requirements
- App-level PQC crypto: Possible via bundled libraries
App-level PQC without OS support
If you need PQC cryptography on older Android versions or need algorithms not yet available through Conscrypt, you have options:
Bundle Conscrypt in your app
You can include Conscrypt as a dependency in your Android app and register it as a security provider. This gives your app its own TLS implementation independent of the system version:
// In build.gradle
implementation("org.conscrypt:conscrypt-android:2.5.2")
// In your Application class
Security.insertProviderAt(Conscrypt.newProvider(), 1)This approach lets you ship PQ TLS support to devices running any Android version, at the cost of a larger APK (approximately 3-4 MB for the native libraries).
Use BoringSSL directly via JNI
For applications that need lower-level control, you can compile BoringSSL for Android and call it through JNI. This is more complex but gives you access to the full BoringSSL API including ML-KEM and ML-DSA primitives.
Third-party PQC libraries
Libraries such as MLKEMNativeAndroid (pure Kotlin ML-KEM-768 implementation) provide PQC primitives without native binaries. These are useful for key encapsulation at the application layer, independent of the TLS stack:
// Using a Kotlin ML-KEM library for app-level key encapsulation
val keyPair = MLKEM768.generateKeyPair()
val (ciphertext, sharedSecret) = MLKEM768.encapsulate(keyPair.publicKey)
val decryptedSecret = MLKEM768.decapsulate(keyPair.privateKey, ciphertext)What PQC protects on Android
Understanding what is protected helps prioritize migration:
Protected today (Chrome, Android 12+)
- Web browsing traffic: HTTPS connections via Chrome use X25519MLKEM768 by default
- App HTTPS traffic: Connections to servers that support PQ key exchange (via Conscrypt updates)
- Google services: Internal Google traffic uses ML-KEM for key exchange
Protected with Android 17
- App signing keys: ML-DSA key pairs in Keystore
- Boot integrity: Firmware verification with PQ signatures
- Key attestation: Hardware attestation with PQ protection
- App-to-app encryption: ML-KEM key encapsulation via Keystore
Not yet protected
- Existing stored data: Files encrypted with classical keys remain classical
- Third-party messaging (older protocols): Signal, WhatsApp, etc. manage their own crypto stacks independently
- Bluetooth/NFC: Short-range protocols have not adopted PQC
- Wi-Fi (WPA3): No PQC integration announced
Performance considerations
PQC algorithms have different performance characteristics than classical algorithms:
| Operation | ML-KEM-768 | ECDH (X25519) | Impact |
|---|---|---|---|
| Key generation | ~0.05 ms | ~0.04 ms | Negligible |
| Encapsulation | ~0.06 ms | N/A | Negligible |
| Decapsulation | ~0.06 ms | ~0.04 ms | Negligible |
| Public key size | 1,184 bytes | 32 bytes | Larger ClientHello |
| Ciphertext size | 1,088 bytes | 32 bytes | Larger ServerHello |
The hybrid X25519MLKEM768 TLS handshake adds approximately 1.1 KB to the ClientHello message. On modern mobile networks (4G/5G), this adds less than 1 ms of additional latency. On very slow connections, the impact may be noticeable for the initial handshake but is amortized across the session.
For signatures:
| Operation | ML-DSA-65 | ECDSA (P-256) | Impact |
|---|---|---|---|
| Sign | ~0.3 ms | ~0.1 ms | Moderate |
| Verify | ~0.1 ms | ~0.2 ms | Slightly faster |
| Signature size | 3,309 bytes | 64 bytes | Significantly larger |
| Public key size | 1,952 bytes | 64 bytes | Significantly larger |
The larger signature and key sizes are the main trade-off. For applications that transmit many signatures (such as certificate chains), the bandwidth increase is noticeable on mobile networks.
Timeline of Android PQC milestones
| Date | Milestone |
|---|---|
| August 2024 | BoringSSL adds X25519MLKEM768 support |
| April 2024 | Chrome 124 enables PQ key exchange by default (desktop) |
| November 2024 | Chrome 131 enables X25519MLKEM768 by default (all platforms including Android) |
| March 2026 | Google announces full PQC implementation in Android, 2029 migration target |
| Q2 2026 | Android 17 beta with PQC enhancements begins testing |
| H2 2026 | Android 17 production release expected |
| 2029 | Google’s target for complete PQC migration across Android |
Recommendations for Android developers
If you are building a new app
- Target Android 17 (API level TBD) to access native Keystore PQC support
- Use the standard
KeyPairGeneratorAPI for ML-DSA and ML-KEM - Your HTTPS connections will automatically use PQ key exchange on supported devices without code changes
If you maintain an existing app
- Do nothing for TLS: Conscrypt Mainline updates handle PQ key exchange automatically
- For app-level crypto: Evaluate whether you need PQC keys before Android 17 adoption reaches critical mass
- For sensitive data: Consider bundling Conscrypt or a PQC library for backward-compatible PQ protection
- Test ClientHello size: Some enterprise proxies and firewalls may reject the larger TLS ClientHello from PQ handshakes
If you target older Android versions
- Bundle Conscrypt as an app dependency for PQ TLS on older devices
- Use Kotlin/Java PQC libraries for application-layer key encapsulation
- Remember that Chrome on older devices already provides PQ web browsing
Frequently asked questions
Does my Android phone already use post-quantum encryption?
If you use Chrome for web browsing, yes, since November 2024. For app traffic, it depends on whether your device has received a Conscrypt Mainline update with PQ support and whether the server you connect to supports X25519MLKEM768.
Do I need Android 17 for PQC?
For TLS key exchange (protecting network traffic), no. Conscrypt Mainline updates can bring PQ TLS to Android 12 and later. For Keystore-level PQC (generating and storing ML-DSA or ML-KEM keys on the device), yes, you need Android 17.
Which servers support PQ TLS on the other end?
Major CDNs and services already support X25519MLKEM768: Cloudflare (default since 2024), Google services (default), AWS (opt-in), and many others. If the server does not support PQ, the handshake falls back to classical key exchange with no user-visible impact.
Will PQ TLS break anything?
The main compatibility issue is with legacy network middleboxes (firewalls, proxies, DLP solutions) that cannot handle the larger TLS ClientHello message. Chrome includes fallback logic to retry without PQ if the initial handshake fails, but enterprise environments with strict proxy configurations may need proxy updates.
Is Signal/WhatsApp post-quantum on Android?
Signal adopted post-quantum key exchange (using CRYSTALS-Kyber, the precursor to ML-KEM) in its PQXDH protocol in late 2023. WhatsApp followed for key exchange. These messaging apps manage their own cryptographic stacks independently of Android’s system TLS layer.
What about Samsung, Pixel, OnePlus, etc.?
The Conscrypt Mainline module update applies regardless of device manufacturer. Android 17 PQC features will be available on all devices that ship or update to Android 17. Hardware-backed Keystore support depends on the device’s secure element, but the software fallback is available on all Android 17 devices.
Can quantum computers break my existing encrypted data?
A future sufficiently powerful quantum computer could decrypt data that was encrypted using classical key exchange if an attacker recorded the encrypted traffic. This is the harvest-now-decrypt-later attack. PQ key exchange prevents this by ensuring that even a quantum computer cannot recover the session keys from a recorded handshake.
Sources
- Google Security Blog: Implementing Post-Quantum Cryptography in Android — Official Google announcement of PQC in Android 17 (March 2026)
- Google Blog: Digital security in the Quantum Era — Google’s 2029 PQC migration timeline commitment
- Google Security Blog: A new path for Kyber on the web — Chrome’s transition to X25519MLKEM768 (codepoint 0x11EC) in Chrome 131+
- NIST FIPS 203: ML-KEM Standard — ML-KEM specification used in Android’s Keystore and TLS stack
- NIST FIPS 204: ML-DSA Standard — ML-DSA specification used in Android 17 Keystore
- Conscrypt GitHub Repository — Android’s Java Security Provider that wraps BoringSSL for TLS