Docs

Quantum-Safe Credentials on Android 17: What to Track

Android 17's ML-DSA quantum-resistant key support changes credential generation cost — track it before it shows up as a performance regression.

Performance

Android 17 adds native support for quantum-resistant cryptography, including ML-DSA key generation, so apps handling sensitive authentication or signing can start migrating away from classical algorithms before quantum computing makes them a real threat. For most product teams this sits several layers below anything user-facing — it’s a keystore and crypto-provider change, not a UI change — which is exactly why it’s easy to roll out without instrumenting it at all. That’s a mistake, because post-quantum algorithms are computationally heavier than the classical ones they replace, and a credential-generation step that used to be invisible can become a measurable delay once it’s doing lattice-based math instead of elliptic-curve math.

The organisations most likely to adopt ML-DSA early are exactly the ones this site is built for — teams handling sensitive organisational data who can’t wait for a forced migration deadline. But “more secure” and “no regression” aren’t the same claim, and nobody wants to discover that a quantum-safe key rotation is adding half a second to login on mid-tier Android hardware three weeks after it shipped. Treat the migration like any other crypto or auth change: instrument it before rollout, not after a support ticket forces you to.

Data Points to Track

  • Key generation duration, split by algorithm (classical vs. ML-DSA), so any performance delta is visible immediately rather than inferred from aggregate login-time metrics
  • Device tier and chipset, since post-quantum key generation cost varies more by hardware than classical algorithms did, and low-end devices are where regressions surface first
  • Keystore provider fallback events, for any device or OS build that can’t satisfy a quantum-safe request and drops back to a classical algorithm
  • Signing and verification latency for the ongoing operations that use the generated key, not just the one-time generation cost
  • Rollout cohort, tagging users on the new credential path versus the legacy path during a staged migration, so you can compare like-for-like rather than pre/post across an unrelated app update

Setup Steps

  1. Wrap key-generation calls with start/stop timing on both the classical and ML-DSA code paths, tagged with the algorithm used.
  2. Capture device model and chipset alongside every generation event, since this is where the performance story will actually differ.
  3. Log explicit fallback events whenever a quantum-safe request degrades to a classical algorithm, rather than letting it pass silently as a successful key generation.
  4. Add cohort tagging to your staged rollout so quantum-safe and classical users can be compared in the same reporting window.
  5. Extend timing instrumentation to signing and verification, not just generation, since those operations run far more frequently and any per-call overhead compounds.

Actionable Insights

If ML-DSA key generation is meaningfully slower than your classical baseline on the bottom third of your device distribution, that’s a rollout-pacing decision, not just a footnote — you may want to gate the migration behind a device-tier check rather than shipping it universally. Fallback events clustering on specific OS builds or OEM skins tell you where your quantum-safe coverage actually has gaps, which matters if compliance or contractual requirements assume full coverage. And if signing/verification latency creeps up on the new path, that’s the number to watch longer-term, since it’s the cost you pay on every authenticated action, not just once at key creation.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert