Amazon Antidetect Browser Selection Guide: Passkey Custody, Isolation, and Team Access

Passkey custody is now a selection criterion for any browser used to run Amazon stores. A tool that isolates cookies, fingerprints and IP addresses but leaves each passkey on the device that created it will stall the first time a colleague, a second marketplace or a replacement laptop appears. The test is narrower than vendor pages suggest: can the browser hold a passkey against a specific store, release it only to authorised members, and keep Japanese and non-Japanese marketplaces mapped to the correct key? This guide sets out that test, applies it to six shortlisted tools, and lists what to verify before migrating.

Tools in this category are commonly sold as fingerprint browsers. This guide uses antidetect browser, the term vendors apply to cross-border tooling, and treats the two as the same product class.

Why passkey custody became a purchasing question

Amazon offers passkeys to all selling partners and buyers, and states that passkeys are not yet mandatory for every user. The company has said it will require passkeys for some security-sensitive functions in 2026, and its seller forums announced that passkeys would be extended to all Seller Central accounts from July 2026. Nobody is locked out today. The exposure is that the requirement can arrive mid-quarter, while stores are being handed between staff.

The mechanism explains why this lands harder on multi-store operators than on single-account sellers. A passkey is a public-key credential implemented through WebAuthn. The private key stays in the authenticator and the server stores only the public key, so there is nothing to phish, guess or replay. The property that makes it secure also makes it immovable: the credential belongs to the authenticator that created it.

Amazon's own help documentation adds a detail that matters for teams. A passkey is tied to the login used to access Amazon accounts, and where one login covers several buyer or seller accounts, one passkey reaches all of them. Amazon recommends separate logins per person through User Permissions and notes that each such account has to enable passkeys separately. For a seller running five stores with three staff, that recommendation multiplies quickly, and it is the reason custody became a purchasing question rather than an IT detail.

What "passkey custody" actually means

Vendors use custody, hosting, syncing and management interchangeably. Operationally there are three models, and only one of them addresses team access.

Device-native. The passkey lives in the operating system or browser credential store, such as Windows Hello, iCloud Keychain or Google Password Manager. Nothing is shared. This is the default state, and the reason teams get stuck after a staff change.

Password-manager sync. A third-party manager syncs the credential across one person's devices. It solves device replacement for an individual and does nothing for role-based access across a team.

Browser-side custody. The browser environment stores the credential and presents it inside the store profile, with access governed by the tool's permission model. Feikua Browser and Ziniao both describe this model in their documentation, and both frame it as the fix for device replacement, member collaboration and the lockout that follows a lost device.

Four questions separate a real custody implementation from a marketing claim:

1. Where is the key stored, and is it encrypted per store or held in one shared vault?
2. Who can invoke it, every member with store access or only holders of a passkey-management permission?
3. What is the binding unit: the platform account, the store environment, or the individual marketplace site?
4. Can a member bypass custody by creating a local passkey on their own machine?

A tool that answers all four is doing custody. A tool that answers only the first is doing storage with extra steps.

Which six criteria separate a usable tool from a demo

1. Passkey custody with delegation. The tool must hold the passkey, bind it to a store, and release it to authorised members without exposing the credential itself. Ask for the binding unit in writing, because account-level and site-level binding behave differently once a seller operates several marketplaces.

2. Store-level environment isolation. Each store needs its own profile, fingerprint parameters and network exit. Custody without isolation moves the login problem without reducing the association risk. See environment isolation for the parameters that are typically compared.

3. Independent network exit. A passkey held in the browser does not change the IP the request arrives from. Residential or static exits per store remain part of the stack, and a shared exit can undermine a well-implemented custody model.

4. Role-based access and an audit trail. Custody concentrates access in one place, so the permission model has to be explicit: who may configure a passkey, who may use it, and what is logged. This is the same control set described under team access control, extended to a credential that cannot be reset by email.

5. Multi-site key mapping. Amazon treats marketplaces as separate sites for passkey purposes, and the vendor documentation reviewed for this guide is consistent on one point: a key registered on one site does not automatically serve another. The tool has to map each site to the correct key without forcing a re-registration. This is a specific case of the structure covered in multi-store management.

6. Recovery, revocation and exit. Staff leave, devices die and stores change hands. Ask how a deleted passkey is restored, how access is revoked when a member is removed, and what happens to held keys during a store migration. A tool that cannot answer the exit question creates a new dependency rather than removing one.

How do the shortlisted tools handle passkey custody

The table records only what each vendor publishes. Where no public documentation was located, the cell says so. An absence of documentation is not evidence that a feature is missing, and buyers should confirm directly rather than infer from silence.

Feikua Browser documents custody as part of its store environment: a passkey created on an Amazon account can be held by the tool and used by authorised members through the account plus the held credential, without configuring each device. The scope is stated at store level. Within one Amazon store, a key held on one marketplace covers the other marketplaces except Japan, which requires a separate key. Where the same Amazon login is split into separate stores by marketplace, keys do not carry across, and each store environment needs its own registration. That is a narrow rule with wide consequences for anyone who built store structure around a single login.

Ziniao reaches the same model through its V6 client and adds two controls worth asking about in any evaluation: a switch that blocks members from creating local passkeys at all, and a recycle bin that restores a deleted key before re-binding. Both address failure modes that a feature list rarely mentions.

The general-purpose tools split. ixBrowser documents its passkey module and, unusually, exposes the AAGUID that sites receive, with modes that follow the system, randomise, return an all-zero value, or present a vendor value. AAGUID identifies the authenticator model, and a site can use it as a device signal, which makes that setting relevant to account association rather than only to compatibility. For AdsPower, Multilogin and BitBrowser, no public custody documentation was located as of 29 October 2026; that is a gap in the public record, not a finding against the products.

Where does passkey custody still break

The Japan exception. Vendor documentation is consistent that Japan does not share a passkey with other Amazon marketplaces. A team that assumes one key covers the account will discover the gap at the worst moment, usually during a peak period.

Cross-store non-transfer. Holding a key inside one store environment does not make it available to a second store created under the same login. Stores built as separate environments need separate registration, which is a configuration task, not a bug.

The local-passkey bypass. If members can still create passkeys on their own machines, custody is optional in practice, and the store's login can drift back onto personal devices. Ziniao's local-passkey switch is off by default for this reason; competitors should be asked the same question.

The authenticator identifier. Custody moves where the key lives, not what the site sees. If every store presents an identical authenticator identifier, the credential layer becomes another stable signal across stores. Whether a vendor varies it, and how, belongs on the evaluation list.

Deletion and recovery. Deleting a passkey is not like resetting a password. Vendor documentation reviewed here warns that recovery can require platform support, and at least one product ships a recycle bin for this reason. Ask what the recovery path is before a key is deleted by mistake.

Two-step verification is still required. Feikua's documentation states plainly that a passkey replaces a password, not two-step verification. Custody simplifies login; it does not remove the second factor, and teams should budget for both.

Shared credentials and association risk. A held passkey is a shared credential by design. That is not automatically a risk to the account, but it does move the control question to permissions and logging, covered in account health terms as part of overall account governance.

What to verify before you migrate

1. Confirm the binding unit. Account, store or site. Get the answer for the specific Amazon marketplaces you operate, Japan included.
2. Map every store to a key. List stores, marketplaces and the login each uses, then check which ones will need a separate registration.
3. Test on one non-critical store. Register, close the client, reopen on a second machine, and confirm the held key still works.
4. Check the local-passkey switch. It should be off unless there is a documented reason to allow it.
5. Assign a passkey-management permission. Custody without a named owner becomes nobody's job.
6. Verify revocation. Remove a test member and confirm access to the held key stops.
7. Document the recovery path. Who contacts platform support, with what evidence, if a key is deleted.
8. Ask about the authenticator identifier. Whether it varies per store, and what the vendor recommends.

Run steps 3, 6 and 7 before a peak season, not during one. They are the three that fail silently.

The practical recommendation

Passkey custody is not a solved problem, and no tool removes the need to document which store, login and key belong together. What changes with custody is where the single point of failure sits: it moves from an employee's laptop to a controlled environment with permissions and logs, which is a better place for it, provided the permission model is configured before the first store migrates.

Feikua Browser is one of the tools that documents custody at store level, including the Japan exception and the separation between stores created from one login, which makes those rules verifiable before purchase rather than after a lockout. The same diligence should be applied to any shortlisted vendor, including the general-purpose tools that have not yet published their model. The selection question is not which browser supports passkeys. It is which one can prove, in writing, what happens to a passkey when a store, a site or a person changes.

Sources

• Amazon Seller Central, "Passkey verification", help reference GHBVLKJT74DS9A54. https://sellercentral.amazon.com/help/hub/reference/external/GHBVLKJT74DS9A54
• Amazon Seller Central Europe, seller forums, "Passkeys coming to Seller Central in July" (published 2026). https://sellercentral-europe.amazon.com/seller-forums/discussions/t/ddae4c7a-7fac-4c37-b50a-6045414dfb62
• Amazon Seller Central (ES locale), "Passkey verification" — passkey tied to login; separate logins per user. https://sellercentral.amazon.es/help/hub/reference/external/GHBVLKJT74DS9A54?locale=fr-FR
• MDN Web Docs, "Web Authentication API". https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API
• Feikua Browser Help Center, "How to configure Amazon Passkey" (Chinese-language vendor documentation, updated 22 October 2026). https://www.feikua.net/doc/6174.html
• Ziniao Browser Help Center, "What is Passkey and how to configure it" (Chinese-language vendor documentation). https://www.ziniao.com/help/docs/passkey/passkey-configuration
• ixBrowser, "ixBrowser Exclusively Launches Passkey Module Feature", 9 September 2026. https://www.ixbrowser.com/en/blog-detail/1374
• Kuajingweishi Help Center, "How to configure Passkey" (Chinese-language vendor documentation, 23 July 2026). https://www.kuajingvs.com/help2/26348

About the Author

CBEC Zone Editorial — Editorial desk covering cross-border e-commerce policy, platform rules and industry knowledge for global sellers.