| TL;DR Phishing is the number one threat to seller accounts, ahead of anything technical.Generate a 20-character random password. The current federal minimum for single-factor use is 15.Once a month, spend five minutes reviewing login alerts from the last 30 days.Every three months, revoke third-party app access you have not used in 90 days. Short version: account security here is not a project, it is a five-minute monthly habit and a quarterly purge, and the thing most likely to get you is an email rather than an exploit. |
Four vectors account for essentially all seller account intrusions: phishing, weak or reused passwords, shared logins, and third-party applications with access nobody has reviewed since they granted it. The item-by-item version, with the audit routine attached to each, is set out in this Amazon Seller Central security checklist.
Note what is missing from that list. There is no sophisticated attack on it. Every one is a process failure, which is good news, because process failures are fixable on a calendar.
Four ways in, and two recurring tasks that close all of them.
Phishing Sits at Number One
It is the leading threat, and the reason is that it targets the one component with no patch cycle.
CISA’s current guidance on recognizing and reporting phishing makes an uncomfortable point about how the detection advice has aged. Poor grammar and misspelling used to be a reliable tell. In the era of AI-assisted writing, plenty of phishing emails now arrive with perfect spelling and natural phrasing, so the heuristic most people were taught no longer discriminates.
What still works is structural rather than stylistic. Never act on a link in an email that asks you to log in or upload a document. Open Seller Central directly and look for the request inside the account. A legitimate case will be there. This costs ten seconds and defeats the entire category.
The seller-specific version of the risk is worth naming: the highest-value moment to phish a seller is during verification or a policy dispute, when they are already expecting Amazon to ask for documents.
Length Beats Cleverness
Generate a 20-character random string of letters, numbers and symbols. Not a memorable phrase with substitutions, not last year’s password with a digit appended.
For context on why the number is that high, NIST’s Digital Identity Guidelines, SP 800-63B Revision 4 require a minimum of 15 characters for passwords used as a single-factor authentication mechanism, dropping to eight where multi-factor authentication is in place. Twenty with a second factor is comfortably beyond the standard, which is the right side to be on for an account holding a payout destination.
The revision matters because of what it attaches the 8-character figure to. Eight is the floor only where a second factor is already in place. Quoted on its own, as a general minimum, it describes a standard that no longer exists.
Two consequences follow. A 20-character random string is not memorable, which means a password manager is not optional. And complexity rules matter less than length, so a long random string beats a short cryptic one, which is the opposite of what most corporate password policies taught a generation of users.
Stop Sharing the Login
If more than one person touches the account, each of them needs their own user permission.
This is the item most often skipped in small teams, on the reasonable-sounding basis that everyone is trusted. Trust is not the issue. Attribution is.
The Federal Trade Commission’s Start with Security guide, assembled from more than eighty enforcement actions, advises restricting access based on need and using separate user accounts to limit who can reach sensitive data. On a seller account the practical benefits are immediate: you can see who changed a price, you can revoke one person’s access when they leave without resetting everyone, and one compromised laptop does not become a full account compromise.
A shared login also breaks the lockout math. A colleague mistyping their way past five consecutive attempts can trigger a lock that shuts out everyone, and nobody can tell you who did it.
The Third-Party App Problem
Every tool you have connected holds access it was granted at some point in the past, on terms you agreed to once and have not revisited.
The risk is not that these tools are malicious. It is drift. An application that was well-run two years ago might have been sold since, and the access it holds transferred with it. Nobody sends you a notification when that happens.
The FTC guide is direct on this too: put security expectations for service providers in writing, specify reasonable precautions such as encryption, and then verify rather than assume. For a small seller the realistic version is not a contract negotiation. It is a quarterly review of who has access and why.
The Two Rhythms
Everything above collapses into two recurring tasks, and the value is entirely in their being recurring.
Monthly, five minutes. Log into Seller Central and review the login alerts from the last 30 days. You are looking for a location or a device you do not recognize. Five minutes is genuinely enough, and doing it monthly means an anomaly surfaces within weeks rather than at the next crisis.
Quarterly, deeper. Every three months, revoke access for any third-party tool you have not used in the last 90 days. Review user permissions and remove anyone who has left. Confirm your two-factor backup method still points at a device you own.
The 90-day rule on unused apps is the highest-value item in the quarterly pass, because unused access is pure downside. It carries all the risk of an active integration and none of the benefit.
Put It on the Calendar
The only implementation advice that matters: create the monthly and quarterly reminders now, while reading this, rather than resolving to remember. Every seller who has lost an account to one of these four vectors knew about all four beforehand.
