Android 17 Passkeys: What's New for Credentials?

1. Introduction: Passkeys in Android 17#

Like its predecessor, 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: 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 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 Credential Exchange standard, mirroring the secure import and export capability Apple introduced in iOS 26. 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.

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 services 26.21 starting June 2026, Android now supports the 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 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 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: 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 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 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 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 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 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 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 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 credentials, a passkey or a hardware security key, 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 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, 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. None of these gains is automatic for a business. Credential Exchange, theft protection and Advanced Protection are platform features Google ships, and they say nothing about 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.

Corbado Observe is the authentication observability layer that closes this gap. Credential Exchange is the change it reads most directly: Authenticator Inventory names every credential your users hold from its AAGUID and counts synced and device-bound credentials apart, so a move off Google Password Manager onto another provider surfaces as a shift in the model mix over the following weeks. Google Password Manager and the third-party managers a Credential Exchange transfer would send credentials to come from a platform-authenticator catalog. The FIDO Metadata Service is a second catalog behind the same page and it covers hardware security keys, which on Android is the smaller half of the story. Passkey Insights covers the same fleet by authenticator, sync status and transport.

See Authenticator Inventory in Corbado Observe →

The readiness question is a second view. Technology splits every login and enrollment by OS, OS version and browser, so "Android 17 works" becomes a number per cohort, and Device Health goes a level deeper by classifying ceremony outcomes per device brand and model, which is where a single Samsung or Xiaomi model that fails the credential prompt separates itself from Android in general. Passkey Errors attributes the failures behind a weak cohort to a WebAuthn reason, carrying the raw error name, message and code the client returned.

Once you can see which cohorts are ready, Corbado Connect acts on them. Rollout Rules gate passkey creation and login per client, and every rule ends in allow, block or allow with sampling, so a build that only behaves from Android 15 upwards can take the passkey path at whatever share you are comfortable with while older builds keep the flow they have. A ruleset can be replayed against recorded traffic as a simulation before it takes effect, and each version is kept, which is what makes a staged rollout reversible on a fleet you do not control and keeps you clear of the failure patterns that derail many rollouts.

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.

About Corbado

Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (+80% passkey activation). Talk to a Passkey Expert →

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.