---
url: 'https://www.corbado.com/blog/android-17-passkeys'
title: 'Android 17 Passkeys: What''s New for Credentials?'
description: 'Explore the key passkey updates in Android 17: secure import and export via Credential Exchange, hardened theft protection and Advanced Protection mode.'
lang: 'en'
author: 'Vincent Delitz'
date: '2026-06-23T09:14:04.090Z'
lastModified: '2026-06-23T15:31:07.662Z'
keywords: 'Android 17, Android 17 passkeys, android passkey import export, Android 17 theft protection'
category: 'WebAuthn Know-How'
---

# Android 17 Passkeys: What's New for Credentials?

## Key Facts

- Android 17 continues the quiet maturation of passkeys with three pillars: **secure
  import and export** via the FIDO Alliance Credential Exchange standard, **hardened theft
  protection** for the credential store and an enhanced **Advanced Protection mode**.
- **Credential Exchange** lets users move passwords and passkeys directly between Google
  Password Manager and third-party managers end-to-end encrypted, retiring insecure CSV
  and JSON exports.
- Developers integrate the transfer through the new **`ProviderEventsManager`** APIs
  (`importCredentials` and `registerExport`) in the `androidx.credentials` library.
- An enhanced **Mark as lost** feature in Find Hub locks a missing phone with biometrics,
  so a thief who knows the passcode cannot reach saved passkeys.
- Android 17 **reduces PIN guess attempts** and adds longer lockout delays, while
  **Advanced Protection mode** keeps passkeys and security keys as the enrollment baseline.

## 1. Introduction: Passkeys in Android 17

Like its predecessor, [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) 17 does not announce
its passkey story with a single headline feature. Rolling out first to Pixel devices in
June 2026 and to other eligible devices throughout the year, it instead continues the
pattern set by [Android 16](https://www.corbado.com/blog/android-16-passkeys): a set of foundational improvements
that collectively make passkeys more portable, more resilient against device theft and
more credible as the security baseline for an entire [digital
identity](https://www.corbado.com/blog/digital-identity-guide) ecosystem.

The defining theme of Android 17 is interoperability. For years a passkey saved in Google
Password Manager was practical to use but awkward to move, leaving users worried about
lock-in and pushing them back toward familiar but insecure habits. Android 17 addresses
this head-on by shipping the [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance) Credential Exchange
standard, mirroring the secure import and export capability Apple introduced in
[iOS 26](https://www.corbado.com/blog/ios-26-passkeys). Alongside this it hardens the device itself, the place
where every synced passkey ultimately lives.

This blog post provides a deep dive into the passkey-relevant pillars of Android 17. It
explores the secure credential portability enabled by **Credential Exchange**, the
**hardened theft protection** that shields the credential store from a thief who knows the
PIN and the continued endorsement of passkeys within an enhanced **Advanced Protection
mode**.

| Feature                       | Primary Benefit                                                 | Impact on Passkeys                                                                                         |
| ----------------------------- | --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| **Credential Exchange**       | Secure, user-controlled migration between credential managers.  | Removes vendor lock-in and retires insecure CSV exports for passkeys.                                      |
| **Enhanced Theft Protection** | Biometric lock and PIN brute-force throttling for lost devices. | Protects saved passkeys when a thief holds both the phone and its passcode.                                |
| **Advanced Protection Mode**  | Hardened profile for high-risk, targeted users.                 | Keeps passkeys and hardware security keys as the enrollment baseline, cementing them as the gold standard. |

## 2. Secure Passkey Import and Export with Credential Exchange

The most consequential passkey change in the Android 17 timeframe is secure credential
portability. Delivered through [Google Play](https://www.corbado.com/blog/google-play-services-passkey-error-codes)
services 26.21 starting June 2026, Android now supports the [FIDO
Alliance](https://www.corbado.com/glossary/fido-alliance) Credential Exchange Protocol (CXP) and its companion
data format, Credential Exchange Format (CXF). Users can move both passwords and passkeys
between [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) and
third-party managers such as 1Password, Bitwarden and Dashlane.

### 2.1 User Experience: Migration without Lock-in

From the user's perspective the flow is short and explicit. The transfer can start in two
places: by choosing "Import passwords & passkeys" inside the destination manager, or by
choosing "Export passwords & passkeys" inside Google Password Manager. The user picks the
source app, authenticates with a [biometric](https://www.corbado.com/blog/passkeys-biometric-authentication) and
the selected credentials move directly to the destination.

Crucially, this replaces the old reality where moving credentials meant exporting a plain
CSV or JSON file, an approach that scattered unencrypted secrets across the file system
and never worked for passkeys at all. The new flow is end-to-end encrypted and happens
app-to-app, so sensitive material is never written to an intermediate file. This directly
tackles the fear of lock-in that has slowed [passkey
adoption](https://www.corbado.com/blog/passkey-adoption-business-case): a passkey is no longer a credential
trapped inside one vendor's ecosystem but a portable identity the user genuinely controls.

### 2.2 Technical Analysis: CXP, CXF and the Provider Events APIs

Under the hood the transfer follows the [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance)
Credential Exchange specifications. The importing provider initiates the flow with an
export request containing a challenge and a public key, the two providers establish a
secure channel using Diffie-Hellman key exchange and the exporter returns the encrypted
credential payload formatted with CXF. The importer validates the signed challenge,
decrypts the data and stores it. Because the channel is negotiated per transfer, secrets
are protected with [end-to-end encryption](https://www.corbado.com/faq/end-to-end-encryption-passkey-sync) in
transit. The following diagram traces this exchange end-to-end.

For credential providers the integration point is the new `ProviderEventsManager` family
of APIs in the `androidx.credentials` library:

1. **Registering as a source:** A provider that wants to export credentials calls
   `registerExport`. Once registered it appears in the system selector whenever another
   provider starts an import. The provider must also declare an activity in its manifest
   with the appropriate intent filter so the framework can hand it the transfer request.
2. **Initiating an import:** A provider in the client role calls `importCredentials`, which
   launches a provider selector UI listing every app that registered an export capability.
   The request is then forwarded to the chosen source.
3. **Verifying both sides:** The framework moves data through a content URI and attaches
   security context to the request. The importer's `CallingAppInfo` is supplied so the
   exporter can verify who is asking, and a `credId` validates the selected export entry.
   Google additionally blocks transfers to unverified or untrusted apps.

This architecture matters beyond convenience. By building migration on an open
[FIDO2](https://www.corbado.com/glossary/fido2) standard rather than a proprietary token, Google ensures a passkey
created on Android can later live in any compliant manager, including Apple's, which also
implements CXP. Interoperability, not a single vendor's sync graph, becomes the foundation
for portable identity.

## 3. Hardened Theft Protection for the Credential Store

Passkeys resist remote [phishing](https://www.corbado.com/glossary/phishing) by design, but their security is
ultimately bound to the security of the device. The persistent real-world threat is
"shoulder surfing": an attacker observes a PIN or pattern, then steals the phone. With both
the device and a known passcode, that attacker could previously reach the credential store
and the passkeys inside it. Android 17 closes this gap from two directions.

### 3.1 Biometric Lock with the enhanced "Mark as lost"

[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) 17 upgrades the **Mark as lost** feature
in Find Hub. When a device is flagged as lost, the owner can lock it using their
biometrics, and the key consequence is explicit: even if a thief knows the passcode, they
cannot access information on the phone or turn off tracking. For the passkey ecosystem this
means the saved credentials in [Google Password
Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) stay out of reach precisely in the
scenario where a stolen phone and an observed PIN would otherwise hand an attacker
everything.

### 3.2 PIN Brute-Force Throttling

Android 17 also hardens the lock screen itself. Google reduced the number of times an
attacker can guess a PIN and added longer wait times between failed attempts. This blunts
the brute-force path to the credential store: an attacker who does not already know the
exact PIN can no longer rapidly cycle through guesses to reach saved passkeys and app
data. Combined with the biometric lock, these changes shift the weakest link, the
observable or guessable PIN, away from being a viable route to a user's passkeys.

Together these measures continue the work [Android 16's Identity
Check](https://www.corbado.com/blog/android-16-passkeys) began, treating access to stored passkeys as a
high-value action that deserves protection stronger than a memorised number. The contrast
below shows how these two layers break the stolen-PIN attack chain.

## 4. Advanced Protection Mode endorses Passkeys

For users at high risk of targeted attacks, Android 17 enhances **Advanced Protection
mode**, the device-level profile that locks down the attack surface with strict policies
and now adds stronger defences against sophisticated threats alongside improvements to Live
Threat Detection.

The relevant point for authentication is continuity of direction. Advanced Protection
continues to treat [FIDO2](https://www.corbado.com/glossary/fido2) credentials, a passkey or a [hardware security
key](https://www.corbado.com/blog/best-fido2-hardware-security-keys), as the enrollment baseline for the Google
account, with passwords considered insufficiently secure for this tier. By keeping passkeys
at the centre of its highest-security offering, Google reaffirms that they are the
designated gold standard for modern authentication, an endorsement that carries weight for
security-conscious users and large enterprises planning their rollout.

## 5. What it means for Developers and Enterprises

For developers, the headline is that credential portability is now a platform capability
rather than a per-app workaround. Teams that build credential providers can adopt the
`ProviderEventsManager` import and export flows, while application developers benefit
indirectly: users who can move their passkeys freely are more willing to create them in
the first place, lifting [passkey enrollment](https://www.corbado.com/blog/passkey-creation-best-practices) across
the board.

For enterprises, the theft-protection and Advanced Protection changes reinforce passkeys as
a security baseline rather than a convenience. Reduced PIN attempts, biometric device
locking and a hardened high-security profile all narrow the gap between a synced passkey's
theoretical strength and its real-world resilience on a lost or stolen device. As with
[Android 16](https://www.corbado.com/blog/android-16-passkeys), the practical takeaway is that the platform keeps
removing reasons to stay on passwords.

## 6. How Corbado can help

Android 17 removes real barriers to passkeys, but none of these gains are automatic for a
business. Credential Exchange, theft protection and Advanced Protection are platform
features Google ships - what they do not tell you is whether your own users actually create
passkeys, on which devices the prompts succeed and where people still fall back to
passwords. The Android fleet is heavily fragmented across versions, OEM skins and staggered
Play services rollouts, so passkey behaviour varies sharply from one device cohort to the
next.

This is the gap Corbado closes. Corbado's [passkey
analytics](https://www.corbado.com/blog/passkey-analytics) and
[authentication observability](https://www.corbado.com/blog/authentication-observability) continuously track
device-level passkey health across your entire user base, so you can see exactly which
Android versions, browsers and authenticators succeed or fail rather than guessing from
aggregate numbers. On top of that, gradual rollout and device-level suppression let you
withhold passkey prompts on environments that are not ready while nudging high-confidence
cohorts, which is how teams [lift passkey
adoption](https://www.corbado.com/blog/passkey-adoption-business-case) without raising support load or risking the
[failure patterns](https://www.corbado.com/blog/why-passkey-implementations-fail) that derail many rollouts. The
platform improvements make passkeys more portable and resilient - Corbado turns that
potential into measurable enrollment and login rates.

## 7. Conclusion: Android 17's continued March to passwordless

The passkey-relevant updates in Android 17 are not flashy, and that is the point. They
extend the deliberate maturation of the ecosystem that Android 15 and 16 began.

With **Credential Exchange**, Google has solved credential portability on an open standard,
removing the lock-in that made users hesitant to commit to passkeys. With **hardened theft
protection**, it has shielded the credential store from a thief who holds both the device
and its PIN. And by keeping passkeys central to **Advanced Protection mode**, it has once
again endorsed them as the gold standard for secure authentication.

Taken together, these updates make passkeys more portable, more resilient and more
trustworthy than before. For developers and enterprises alike, Android 17 is another clear
signal that the passwordless future is arriving one foundational improvement at a time.

## Frequently Asked Questions

### How do I move my passkeys from Google Password Manager to another app on Android 17?

Android 17, via Google Play services 26.21, supports the FIDO Alliance Credential Exchange standard.
You open the import flow in the destination password manager or the export flow in Google
Password Manager, authenticate, then the credentials transfer directly app-to-app
end-to-end encrypted. This replaces insecure CSV or JSON exports for both passwords and
passkeys.

### Which developer APIs power passkey import and export on Android 17?

Credential providers use the `ProviderEventsManager` APIs in the `androidx.credentials`
library. An importer calls `importCredentials` to launch a provider selector, while a
source provider calls `registerExport` and declares a transfer activity in its manifest.
The framework moves data through a content URI and supplies the importer's `CallingAppInfo`
so each side can verify the other.

### Does Android 17 theft protection stop a thief who already knows my PIN from using my passkeys?

Yes. The enhanced Mark as lost feature in Find Hub lets you lock a missing phone with your
biometrics, so a thief with your passcode cannot reach saved passkeys or disable tracking.
Android 17 also reduces how many PIN guesses are allowed and adds longer wait times between
failed attempts, hardening the credential store against brute force.

### Why does Advanced Protection mode in Android 17 matter for passkey adoption?

Advanced Protection mode is Google's highest-security profile and continues to treat
passkeys and hardware security keys as the enrollment baseline rather than passwords.
Android 17 strengthens this mode against sophisticated threats, reinforcing that passkeys
are the designated standard for high-risk users and making them a compliance consideration
for enterprises.