Passkey Rollout — which one?

Decide whether to trust device-bound attestation broadly, add fallback paths, or gate rollout by OEM and OS version as Android's attestation chain transition affects risk controls.

Require fallback when attestation is missing, legacy, or unverifiable, unless this rollout protects high-risk flows where only verified RKP devices should pass.

Blockers

Who this is for

Candidates

Broad trust with dual-root validation and revocation checks

As of 2026-04-08, Google says any app relying on Android Key Attestation should already trust both the existing root and the new ECDSA P-384 KeyMint root, with the migration deadline having passed on 2026-03-31. RKP-enabled devices started receiving chains rooted in the new certificate in February 2026 and are scheduled to use the new root exclusively by 2026-04-10. Google also states the attestation extension schema is unchanged, so the main breaking change is trust-anchor handling rather than payload parsing. Production verification still requires checking the certificate chain and Google's revocation status list.

When to choose

Use this when you want the widest Android coverage and can update server-side verifiers quickly. It is the least disruptive path if your current control already validates Google-rooted hardware attestation and can absorb the root rollover safely.

Tradeoffs

Maximizes coverage and preserves device-bound signals across the transition, but only if your verifier is correctly updated and does revocation checks. It also keeps accepting older factory-provisioned chains, which reduces rollout friction but preserves heterogeneity in assurance levels.

Cautions

As of 2026-04-08, the root-update deadline has already passed. Google explicitly says not to fetch trusted roots dynamically at runtime; handle root changes through a formal release process instead.

Sources

Require fallback when attestation is missing, legacy, or unverifiable

Google's attestation docs say devices launched before Android 7.0 can return software attestation signed by a key hardcoded in Android source, which does not prove secure hardware. The same docs say that if the chain roots in anything other than Google's attestation roots, Google makes no security claim about the hardware, including on non-Google Play devices. Separately, Google's Android FIDO2 API switched to hardware-backed key attestation by default in early April 2025, and SafetyNet certificates are no longer granted. As of 2026-04-08, a fallback path is the practical way to avoid hard failures when a device cannot present a verifier-accepted chain.

When to choose

Use this when passkey adoption matters more than enforcing hardware-backed attestation on every Android device. It fits mixed consumer fleets, BYOD environments, and any rollout where rejecting legacy or non-Google-Play devices would create too much user friction.

Tradeoffs

Improves registration and sign-in success rates, but weakens attestation as a universal fraud or device-binding control. You will need separate risk policies for accounts created without a trusted hardware attestation chain.

Cautions

Do not treat software attestation or unknown OEM roots as equivalent to Google-rooted hardware attestation. If you still depend on Android FIDO2 attestation parsing in-app, the default-format change already occurred in April 2025, so unsupported parsers are already a production risk.

Sources

Gate high-assurance rollout to verified RKP devices and newer launches

Google documents that Android 15 made RKP support optional, while devices that launch with Android 16 support only RKP. The same key attestation guidance says RKP-enabled devices are the population affected by the 2026 root transition, and it provides a test path that requires Android 15 or higher plus confirmed RKP support. As of 2026-04-08, this makes RKP status and launch-era OS a concrete gating signal for higher-assurance device-bound policies. This strategy is stricter than dual-root broad trust and narrower than a universal fallback model.

When to choose

Use this when device-bound attestation feeds sensitive controls such as strong anti-fraud, regulated workflows, or high-value account recovery. The decisive factor is whether you prefer a smaller trusted cohort with more uniform provisioning behavior over maximum passkey coverage.

Tradeoffs

Reduces ambiguity during the transition and lines up better with Android's future direction, but excludes a meaningful share of older or unverified Android devices. Operationally, it also requires device-segmentation logic and rollout analytics by OS and provisioning capability.

Cautions

Google's test instructions for the new root require Android 15 or higher and confirmed RKP support, so test coverage may not represent older fleets. Older factory-key devices continue using the old root and do not support key rotation, so a strict gate should be paired with a clear fallback or denial policy.

Sources

Facts updated: 2026-04-08
Published: 2026-04-08

Related questions

Try with your AI agent

$ npm install -g pocketlantern
$ pocketlantern init
# Restart Claude Code, Cursor, or your MCP client, then ask:
# "Passkey Rollout — which one?"
Missing something? Request coverage