Passkeys are a major win for security, but they are not the same thing as anonymity. The FIDO Alliance and W3C both describe a passwordless model built on public-key credentials rather than shared secrets. That helps against phishing, credential stuffing, and password reuse. On a shopping site, that can be a meaningful upgrade because the login no longer depends on a password that could be stolen from another breach. But a safer login is still a login, and a login still binds actions to an account.

That binding matters in commerce because the account can accumulate order history, saved addresses, device history, returns, support records, and behavior across visits. Passkeys may reduce the chance that a merchant ever sees your password, but they do not stop the merchant from knowing that the same authenticated account came back again. In fact, because passkeys are frictionless, a site may be more willing to nudge people into signing in on every visit, which makes the profile more durable rather than less.

NIST's digital identity guidance is the useful lens here. Authentication strength is only one part of the story. A system can be strong against impersonation while still collecting too much, retaining too long, or linking too broadly. That is why the privacy question is separate from the security question. A passkey can prevent account takeover and still leave you fully trackable inside the merchant's own ecosystem if the merchant uses the account as a durable key.

The WebAuthn model is per relying party, which is better than one password reused everywhere. But the ecosystem around the credential still matters. Device synchronization, account recovery, support flows, and cross-device sign-in can all create additional trust relationships. If a shopper uses the same platform account to sync passkeys across devices, the login becomes easier without necessarily becoming less identifiable. The danger is not the passkey itself. It is the way services build more permanence around it than the user realizes.

The FTC's guidance on protecting personal information still applies because the merchant should only keep what it needs. If the site already has your address, payment method, and order history, it should not use the new login method as an excuse to collect extra profile fields or to retain support data forever. A passkey should be a way to make login safer, not a reason to build a deeper behavioral archive around the same customer account.

For shoppers, the right interpretation is: use passkeys whenever available, but do not confuse 'passwordless' with 'privacyless.' If you want lower exposure, combine passkeys with account minimization. Use guest checkout when possible, avoid saving unnecessary profile fields, and review recovery settings in the ecosystem account that stores the credential. A passkey may keep your login safer, but it does not guarantee that the store will know less about you once you are signed in.

cloak should surface passkeys as a security improvement with a privacy footnote. The product value is real: fewer stolen credentials, fewer phishing losses, and less password reuse. The privacy risk is subtler: the easier a login becomes, the more often the merchant can anchor a full shopping history to one persistent identity. Anti-exploitation defense should celebrate the security win while still warning that a smooth login can make profiling easier, not harder.

The best privacy practice is to pair passkeys with account restraint. If you do not need an account, do not make one. If you do need one, do not let the merchant collect extra fields just because the login is modern. A passkey should lower the cost of secure sign-in, not become a reason to widen the profile or keep more history than the user expects.

If a site pushes passkeys plus mandatory account creation plus marketing consent, the bundle is the signal. The user is being asked to accept a better lock in exchange for a thicker profile. That may be fine for a bank or a warranty portal. It is much less reasonable for a casual shopping site that only needs a receipt and a shipment address.