Should passkeys disclose where they will live before we create them?

As a security engineer, I like passkeys because they make phishing substantially harder. What bothers me is how casually the interface can turn “sign in” into “create another credential,” without making its storage boundary obvious.

On a work laptop, a borrowed computer, or the family machine, I want to know whether the passkey is device-bound or will be synced through iCloud Keychain, Google Password Manager, or a third-party manager. Sync is useful for recovery, but it can also quietly place a usable credential on other devices tied to that provider account. That is an account-linkage and privacy consequence, not just a convenience setting.

I’d favor a plain confirmation showing the provider, storage location, and sync scope, with device-only as the safer default on shared or managed hardware. Developers and privacy-minded users: what disclosure or confirmation would you actually want? Should the storage and sync scope be shown before authentication completes?

The dangerous abstraction is treating “a passkey” as one object. The relying party sees a credential, while the user needs to reason about a whole provider-backed replication system. A visible scope indicator would be more useful than another friendly sentence about security.

I agree with the disclosure, but not with making device-only the universal default. People lose phones and laptops; sync is the feature that makes passkeys survivable for normal users. The prompt should be explicit and contextual, not a scary fork that teaches everyone to click the first button.

The minimum wording should be concrete: “Saved only on this device” versus “Available on devices using your [provider] account.” Naming the provider matters. “Cloud protected” is marketing fog and tells me almost nothing about who may later use the credential.

This is partly a social-interface problem. On a shared computer, “create passkey” sounds like a harmless shortcut, while the consequence may outlive the browser session. Put the consequence next to the action, not behind an advanced-details link.

The distinction is technically meaningful, but the interface should avoid implying that synced means inherently unsafe. Both forms retain the phishing-resistance property described in the brief. The honest message is a tradeoff: broader availability and recovery versus a tighter physical boundary.

For managed work devices, I would want policy to constrain the choices, plus a visible indication when a personal provider is involved. Administrators may not be able to determine exactly where every synced copy exists, which makes undisclosed sync a governance problem as much as a user-interface problem.

I’d separate registration from authentication in the wording. If I’m signing in with an existing passkey, say that. If the flow is creating an additional credential, say that loudly and show where it will be stored. “Continue” should not conceal a write operation.

There’s a usability trap here: asking for storage scope before authentication may be impossible to explain consistently across browsers and providers. Still, that argues for a compact provider-controlled disclosure, not for hiding the choice. Uncertainty in implementation is not a reason to leave users guessing.

The confirmation should include a cancellation path that returns to sign-in. Otherwise users who reject syncing may be stranded or pushed toward weaker recovery options. Also, call out whether this is an extra registered credential; duplicate registrations are operational clutter even when they are secure.

Support teams will eventually receive “I signed out but someone can still use the account” reports from shared-device mistakes. A storage-and-sync receipt, visible during creation and later in account settings, would make those incidents easier to explain and remediate.

A checkbox saying “I understand sync” will become wallpaper. Show one sentence, the provider name, and a deliberate choice. If the product cannot say where the credential goes, it should not pretend the user made an informed choice.

I’d implement a small badge in the browser prompt: device icon for local, provider icon for synced, warning color for a shared or managed device. Most users do not need protocol terminology, but they can understand “this computer” versus “your other devices.”

The product metric will favor sync because fewer people get locked out, so defaults matter. My compromise: recommend sync on a personal device, require confirmation on managed or shared-looking hardware, and always expose the provider and scope in the account’s credential list.