Roll out Seller Central passkeys without locking out the team

Amazon’s passkey rollout should be treated as an access migration, not a two-minute settings task.

Amazon says passkeys are available to all sellers starting in July 2026 and will become required for some accounts later in the year. The company describes a passwordless sign-in using a device fingerprint, face recognition, PIN, or QR-code flow, with the credential held in the device’s password manager.

That can remove a major phishing path. It can also expose weak ownership practices if the business still shares the primary login, depends on one employee’s phone, or has never rehearsed recovery.

Treat passkeys as an identity project

A passkey changes how a person proves access. It does not decide who should have access.

Before enrollment, identify the legal or business owner of the primary user, every secondary user, the email address behind each identity, and the permissions each person holds. Map the critical actions attached to those users: disbursements, tax settings, user administration, listings, inventory, advertising, cases, and reports.

Do not solve team access by creating one passkey around a shared credential. Shared identities blur attribution and make offboarding dangerous. Give each operator an individual Seller Central user, then grant only the permissions required for that role.

The deliverable is an access register that a leader can review without opening Seller Central.

Choose where each passkey lives

The sign-in experience may look like a face scan or device PIN, but the operating decision is where the credential is stored and who controls that environment.

For each user, record the approved device and password-manager account used during enrollment. Confirm that the device has screen lock, current software, remote-loss controls, and a business-approved recovery process. Separate personal convenience from business continuity: a passkey tied to an unmanaged personal ecosystem can become an access dispute when a contractor leaves.

Do not place a high-privilege passkey on a shared warehouse computer. Do not screenshot setup prompts, send credentials through chat, or ask several people to use one person’s device. The safer pattern is one accountable human, one Seller Central identity, and one approved authentication environment.

Stage enrollment before scaling it

Amazon directs sellers to Login & Settings, then Create Passkey. The button is simple; the release sequence should still be controlled.

Start with one secondary user who has limited permissions and no urgent operational deadline. Save the before state: user email, permission set, working sign-in methods, approved devices, and the administrator who can intervene. Create the passkey, sign out fully, and test a fresh sign-in rather than trusting the enrollment confirmation.

Repeat the test in the real working context, including the browser or mobile device the operator normally uses. Confirm that the person reaches the correct seller account and marketplace and can perform only the intended tasks. Log the result, then enroll the next user. Keep the primary user out of the first wave.

Prove continuity and recovery

Phishing resistance is not the same as business resilience.

NIST notes that phishing-resistant authenticators address credential theft and replay, not every phishing outcome. Device compromise, social engineering during recovery, excess permissions, and unsafe sessions still matter. A team also needs a path when a phone is lost, a password-manager account is unavailable, or the administrator leaves.

Document Amazon’s current recovery and login-help routes from the account itself; interfaces and available fallbacks can change. Confirm that an authorized administrator can review users and revoke departed staff without relying on the person being removed. Test access from a second approved context supported by the team’s chosen setup. Do not delete a working fallback merely because the first passkey login succeeded.

Run the exercise before travel, a product launch, or a promotion window—not during an account emergency.

Monitor the access layer after launch

For two weeks after each wave, treat authentication as an operating metric.

Track failed sign-ins, unexpected verification prompts, locked users, recovery attempts, new-user invitations, permission changes, and access from unmanaged devices. Separate an operator training problem from a platform or device problem. One failed login is evidence to inspect, not proof that passkeys are broken.

Add a quarterly access review and an immediate offboarding checklist. Remove users who no longer need access, narrow permissions that have expanded, and verify that primary-user ownership still matches the business. Any agency or tool vendor should have a named sponsor, defined scope, and removal date.

The control is complete only when access can be granted, used, reviewed, recovered, and revoked without shared secrets.

The Operator Read

Passkeys can make Seller Central authentication meaningfully harder to phish. They cannot repair a team access model built around one shared primary account and one irreplaceable device.

Map users first. Decide where credentials may live. Enroll a lower-risk secondary user, verify a fresh sign-in, then scale in controlled waves. Preserve a tested recovery path and monitor the access layer after launch.

The objective is not merely to turn on the new login method. It is to make Seller Central access both harder to steal and easier for the business to govern.