Amazon Account Hacked? Key 2026 Security Steps for Sellers
If your Amazon seller account may be hacked, sign in only through a trusted Seller Central address, secure the associated email account and credentials, check users and disbursement details, capture evidence of unauthorized changes, and open a case through official Seller Central Help. Then audit catalog, promotions, orders, connected apps, Brand Registry, and business information before declaring the incident closed.
A Seller Central account compromise is an incident, not a password issue. An unauthorized user can change account access, payout information, listings, promotions, orders, and even brand roles, all while you are still able to log in. So the correct response is staged: contain access, protect commercial goods, document what changed, contact Amazon via a verified channel, and verify every affected surface is clean. This guide is aimed at US sellers on Amazon.com; some labels in the interface and identity verification methods may vary by marketplace and over time.
In this guide
- Are you dealing with a compromise, lockout, suspension, consumer-account problem, or normal listing error
- Go the first 15 minutes path for still-signed-in, locked-out, or put phishing to the-only-situation
- Develop an incident evidence log and audit every Seller Central compromise surface.
- Reach Amazon safely and stabilize earnings, catalog, and customer services
- Confirm recovery, harden the account, and determine when professional assistance is warranted
- Use the FAQ to answer common questions about recovery and to avoid doubling up on topics
First, confirm what kind of Amazon problem you have
Begin by specifying the event compromised seller account: suspected or confirmed unauthorized access or modifications to your account. A lockout could result from changed credentials or a two-step verification issue but is not, in itself, evidence of a takeover. A suspension is a measure taken by Amazon enforcement. A standard listing error is a catalog or feed issue with no indication of compromise.
| Your situation | First action | Next checks |
|---|---|---|
| Still signed in; unfamiliar activity is visible | Use a known Seller Central address, record the time, capture the minimum evidence needed, and contain access. | Users, account information, disbursement details, listings, promotions, orders, apps, Brand Registry. |
| Locked out or email/phone details changed | Use a known Amazon domain and official recovery/help route. Secure the associated email account and preserve proof of ownership. | Recovery messages, affected marketplaces, device/mailbox security, support case ID. |
| Amazon says the account is suspended or deactivated | Read the Performance Notification, preserve incident evidence, and use the suspension workflow. | Determine whether the security incident and enforcement action are separate problems. |
| Unauthorized consumer order; Seller Central unaffected | Use official Amazon customer account help. | Consumer login, payment method, and order history; do not use this seller workflow. |
| Only a normal listing or feed error is visible. | Confirm that there are no unauthorized users or changes, then fix ordinary Amazon listing errors. | Error code, attribute/feed history, and affected ASINs. |
Safety warning:
Do not call a phone number or open a link from an unsolicited message. Navigate from a saved Seller Central bookmark or type a known Amazon domain. Amazon also advises customers to verify suspicious messages through official channels; review Amazon scam-avoidance guidance when a message or caller claims to be Amazon.
The first 15 minutes
The immediate objective is to prevent further access or financial harm without destroying the baseline trail that would be needed to lay out what happened. Do not let containment be delayed in the name of getting a perfect record. If an unauthorized payout, user, or catalog change is currently taking place, please contain it first and then document it right after.
- Work only from a trusted device and a familiar Seller Central URL. Do not click on any links in emails, text messages, or chat messages.
2. Note the time and time zone. Take the minimal necessary screenshot showing unfamiliar users changing contact or payout information, security alerts, or other suspicious activity, page by page.
3. Protect the email account associated with Amazon and the Amazon password. Check the same incident for recovery email addresses, forwarding rules, active sessions, and devices that have access to the mailbox.
4. Confirm your two-step verification methods and backups. Amazon states that Two-Step Verification is required to access Seller Central; a credential reset is only one containment step, not proof that every access path is closed.
5. Review Seller Central user permissions and remove unfamiliar users. Reduce excessive permissions for legitimate users where doing so will not interrupt critical recovery work.
6. Create an account-related case via the official Seller Central Help channel. Keep the case ID and use a single summary of facts from incident to incident.
If you are locked out
1. Go directly to Seller Central or Amazon Help through a known domain. Do not use a number or link supplied in a suspicious message.
2. Use the available account-recovery and support options. If the problem is limited to a missing two-step verification code, Amazon’s current FAQ directs sellers to use the “Didn’t receive the code?” option and an available backup method.
3. Secure the related email account, phone number, devices, browser extensions, and password manager. Consider any mailbox breach as part of the Seller Central incident.
4. Save the proof of ownership and recent Amazon communications such as registration information, company documents, bank validation documents, and previous case IDs. Share only through a recognized Amazon channel.
5. Log every attempt to contact, response, requested document, and next checkpoint. Do not make a substitute seller account to get around the system.
If you only received a suspicious message
- Do not respond to the message, do not click on any links, download anything, or call the number.
- Log in to Seller Central from a trusted path and verify whether there is a real notification, user change, payment change, or other account-related event.
- If you entered credentials or approved a login prompt, consider it a compromise and proceed to the appropriate signed-in or locked-out branch.
- Keep the message headers or take a screenshot for your own records without sending active malicious links to colleagues.
Build an incident evidence log before the trail disappears.
A good evidence log distinguishes facts observed from assumptions. It lets Amazon, your internal security and finance teams, an insurer, or qualified counsel know what happened without having to rely on memory. Collect only the information you are entitled to access, and redact customer, bank, tax, authentication, and personal data before sharing it outside of your organization.
| Timestamp | Observed fact | Evidence file | Action/owner | Amazon case ID | Next checkpoint |
|---|---|---|---|---|---|
| 24 Jul 2026, 09:12 ET | Unfamiliar secondary user visible | user-permissions-0912.png | Removed user; owner: account admin | Case 123456789 | Recheck permissions after 30 minutes |
| 24 Jul 2026, 09:18 ET | Deposit method shows an unrecognized ending | deposit-method-masked.png | Contacted finance owner and bank | Case 123456789 | Confirm verified bank details and disbursement status |
| 24 Jul 2026, 09:27 ET | Three ASIN titles changed without approval | catalog-change-log.csv | Paused internal catalog edits; preserved file history | Case 123456789 | Compare affected ASINs with approved source data |
Maintain a single master timeline. The notification times, login and contact information changes, users and permissions, payout information, business information, listing and promotion modifications, order/refund transactions, connected apps, Brand Registry roles, Amazon case communications, and internal decisions. Never accuse an employee, seller, or Amazon of wrongdoing without proof; stick to neutral language like “unknown actor,” “unauthorized modification,” or “potential compromise.”
If the incident also requires a broader document package, use a consistent structure to organize Amazon compliance documents without mixing routine compliance evidence with the incident chronology.
Audit the Seller Central compromise surface
Inspect high-risk surfaces first: access persistence, disbursements, and business identity. Then check catalog, customer operations, brand controls, and linked systems. Amazon’s current account settings show that Seller Account Information includes information about payment, business, contact, shipping/returns, and tax, which is also a critical review point after a compromise.
Use Seller Account Information and the current interface to verify each field rather than relying on memory or an old screenshot.
| Surface | Suspicious signals | Evidence to capture | Contain / review | Recovery proof |
|---|---|---|---|---|
| Users and permissions | Unfamiliar user, changed role, excessive access, new invitation | User list, role/permission view, invitation email | Remove unauthorized users; reduce access cautiously | Only approved users remain; permissions match job need |
| Disbursement and payment | Changed deposit method, unfamiliar bank ending, failed verification, unusual disbursement status | Masked bank details, change notices, disbursement records | Notify finance/bank; restore verified details through official controls | Approved deposit method and disbursement status confirmed |
| Business, tax, and contact data | Changed email, phone, legal entity, address, tax data, merchant details | Before/after records and Amazon notices | Restore verified data; complete requested identity checks | All identity and contact fields match authorized records |
| Catalog and listings | Unexpected title, image, attribute, price, offer, or variation changes | Affected ASIN list, contribution history, source files | Stop conflicting internal edits; revert only verified unauthorized changes | Catalog matches approved source data, and no new changes appear |
| Promotions, coupons, and ads | Unexpected budget, coupon, deal, campaign, or promotion | Campaign and promotion history, spend screenshots | Pause or adjust only confirmed unauthorized activity | Approved campaigns and budgets remain; spend reconciled |
| Orders, refunds, and messages | Unusual refunds, cancellations, concessions, buyer messages, or order settings | Order IDs, message records, refund/concession reports | Protect customer operations; involve finance and support, owners | Transactions reconciled and customer-impact actions documented |
| Inventory and fulfillment | Unexpected removals, shipments, stranded inventory actions, or fulfillment-setting changes | Inventory events, shipment IDs, removal orders | Preserve supply continuity while stopping harmful actions | Inventory state and fulfillment settings verified |
| Brand Registry roles | Unfamiliar administrator, rights owner, or affiliated account | Role list, affiliation notices, brand case IDs | Remove or correct unauthorized roles through verified Brand Registry controls | Approved roles and affiliated accounts only |
| Connected apps and API access | Unknown app, token, integration, or service-provider access | Authorized-app list, integration owner, access date | Revoke unrecognized access; rotate affected credentials with the system owner | Every connection has a current owner, purpose, and approved scope |
| Account Health and notifications | New warning, deactivation, policy notice, or missing notification | Performance Notifications, Account Health view, email copy | Treat enforcement separately while preserving security evidence | No unexplained notice remains; required response owner assigned |
Review Account Health for enforcement or policy issues that may have appeared during the incident. For Brand Registry, confirm the current brand roles and affiliated accounts. If a catalog problem is not tied to unauthorized activity, move it to the dedicated listing-error process instead of expanding this incident.
Contact Amazon through a verified route and manage the case
Access Seller Central Help from a recognized domain and within your logged-in account. Never post or trust a phone number that has been copied from search results, social posts, or a message received out of the blue. The precise authenticated menu labels may vary, so publish using resilient language and double-check the current path on the day of release.
Use a concise incident summary.
- Account details: store name, affected marketplace, and masked merchant identifier when applicable.
- Access status: locked out, still signed in, or access has been restored, but suspicious changes remain.
- Date and time: date, time, time zone, and the first reliable signal.
- Changes detected: users, contact information, disbursements, listings, promotions, orders, apps, brand roles, and notifications.
- Containment is over: credentials are safe, users have been removed, the bank has been notified, unauthorized activity has halted, or devices have quit.
- Available Evidence: Screenshots, Reports, Notification Emails, Case IDs, and Incident Timeline.
- Desired results: Day 1: access Account standards, confirm information as authorized on the Account, investigate any Detected Changes, and tell them what’s next.
Use consistent and factual narratives. Refer to prior case IDs rather than opening multiple contradictory cases when a single active case can be updated. Log every response, request for documents, and next checkpoint. If Amazon issues a policy action separately, carry on with the security chronology and the Amazon appeal process tailored to the enforcement issue only.
If a policy action follows the incident, use the Amazon appeal process after a policy action rather than turning the security case into an appeal template.
Stabilize revenue, catalog, and customer operations.
Do not apply a blanket “pause everything” rule. The correct decision depends on whether unauthorized activity is continuing, whether the action is reversible, and whether stopping a process would create more customer or inventory damage. Assign one incident lead and named owners for access, finance, catalog, advertising, fulfillment, customer operations, and communications.
| Severity | Example trigger | Immediate operating decision |
|---|---|---|
| Critical | Disbursement/bank change, primary-admin lockout, business identity change, active unauthorized user | Contain immediately; involve account admin, finance/bank, IT/security, and Amazon case owner. |
| High | Widespread listing or Brand Registry changes, unusual refunds/orders, connected-app abuse | Preserve evidence, stop confirmed harmful activity, protect customer and inventory workflows, escalate to relevant owners. |
| Medium | Unauthorized promotion/ad spend, isolated ASIN edits, suspicious message with no confirmed access | Verify scope, pause only confirmed unauthorized activity, reconcile spend and source files. |
| Monitor | Access restored and no new changes, but root cause or completeness is not confirmed. | Run a recovery checklist, increase review frequency, and keep the case open until all controls pass. |
Reach your bank or payment provider if your bank details have been changed or if there is suspicious financial activity. In the event the mailbox, device, browser, or shared credential is believed to be compromised, involve your internal IT/security team. Escalate to an insurer or a qualified lawyer where significant loss, regulated-data exposure, contractual obligations, law-enforcement inquiries, or a dispute that cannot be resolved without specialist advice arises. This is operational guidance, not legal advice.
Verify recovery - do not stop at a password reset
Recovery is complete when Access, Financial Settings, Catalog, Connected Systems, and Notifications have been reviewed, and there are no outstanding issues, and those that exist have an owner. A password reset could deprovision one access route but still leave an unauthorized user, modified bank account, linked application, or brand role.
| Control | Pass condition | Owner | Status |
|---|---|---|---|
| Credentials and mailbox | Password changed; mailbox recovery data, forwarding rules, sessions, and devices verified | Account admin / IT | ☐ |
| Two-step verification | Approved methods and backup method confirmed; no unfamiliar device or number remains | Account admin | ☐ |
| Users and permissions | Only approved users remain; least-privilege access documented | Primary administrator | ☐ |
| Contact, business, and tax data | All fields match authorized company records, and required verification is complete. | Operations/finance | ☐ |
| Disbursement and payment | Approved deposit and charge methods confirmed; suspicious activity reconciled. | Finance | ☐ |
| Catalog and pricing | Affected ASINs match approved source data; no new unexplained changes | Catalog owner | ☐ |
| Promotions and advertising | Approved budgets, campaigns, coupons, and deals only | Advertising owner | ☐ |
| Orders, refunds, messages, and inventory | Transactions reconciled; customer and fulfillment actions documented | Operations | ☐ |
| Apps, APIs, and Brand Registry | Every connection and role has a current owner, purpose, and approved scope | Systems/brandd owner | ☐ |
| Notifications and Amazon case | Case status, Performance Notifications, Account Health, and next monitoring date documented | Incident lead | ☐ |
Recovery rule:
Do not close the incident while an unexplained account change, financial discrepancy, unauthorized role, connected application, policy notice, or support request remains unresolved. Record what is confirmed, what is estimated, and what is still unknown.
What to change after the incident
Post-incident hardening should address the observed failure mode rather than repeat a generic security list. Keep this stage separate from emergency response so the team does not redesign access while the account is still unstable.
| Timing | Action |
|---|---|
| First 24 hours after stabilization | Retain the evidence log; confirm unique credentials and two-step verification backups; remove unneeded users and apps; reconcile bank and catalog changes. |
| Days 2-7 | Complete a root-cause review; document onboarding/offboarding; assign owners for alerts, users, apps, finance settings, and Brand Registry; restore only verified business changes. |
| Days 8-30 | Set a recurring access-review cadence; update the incident runbook; train staff on verified navigation and escalation; test who owns after-hours alerts and account recovery records. |
Avoiding these risks is an important step in Amazon fraud prevention and brand reputation protection. Another often-overlooked risk is personal information exposed on data broker websites. Hackers can use this data to create convincing phishing emails. Services like Incogni can request the removal of your information from hundreds of data brokers, reducing the personal data attackers may find and use.
Use the broader Amazon seller account protection checklist for ongoing prevention, policy monitoring, permission hygiene, and recurring audits. Agencies and portfolio operators should also review how they manage access across multiple Amazon accounts so one incident does not create unnecessary cross-account exposure.
When the problem is actually a suspension, appeal, or listing error
Use the incident workflow only when unauthorized access or changes are suspected. Move to the correct owner page once the evidence points to a different problem.
| ProblemCorrect handoff | |
|---|---|
| Amazon suspension or deactivation | Amazon issued a Performance Notification or disabled selling privileges. Use what to do if Amazon suspends the seller account. |
| Appeal after policy action | Amazon requires a response, corrective action, or Plan of Action after enforcement. Follow the Amazon appeal process after a policy action. |
| Ordinary listing error | A feed, attribute, variation, suppression, or catalog error exists without evidence of unauthorized access. Use the guide to fix ordinary Amazon listing errors. |
When expert help is justified
The most effective professional assistance is after the immediate containment of an incident when the incident covers multiple operating surfaces or the team is too overwhelmed to orchestrate recovery effectively. Objective triggers are losing access as the primary administrator (owner) of the account, change of disbursement or business information, extensive catalog damage, impact on Brand Registry, involvement of multiple users or tools connected to your account, pending or unanswered Amazon cases, or if you're unsure if your account is completely clean.
SalesDuo’s Amazon account management support is the approved commercial handoff for operational account, catalog, and ongoing management needs. The support scope should be matched to the specific incident; no agency can guarantee Amazon access restoration, fund recovery, response time, or policy outcome.
Move from containment to confirmed recovery.
A hacked Amazon seller account demands more than a password reset. Contain access, protect disbursements and operating assets, preserve a factual record, use official Amazon channels, and verify every account surface before closing the incident. Once the immediate risk is stable, fix the root cause and assign durable ownership for permissions, alerts, connected tools, finance settings, and catalog controls.
For coordinated operational support after stabilization, book a 1:1 growth call with SalesDuo.
FAQs About Amazon Seller Account Hacked
1. What should I do first if my Amazon seller account was hacked?
Take a trusted Seller Central route, make sure your email account and credentials are secure, review users and disbursements, sequester minimal evidence, and file an official case with Amazon. Follow the logged-in or locked-out branch instead of having one generic procedure.
2. How do I know whether Seller Central was compromised?
Watch for a mix of credible signals, e.g., altered contact or payout information, new users, unauthorized changes to listings or promotions, unexplained orders or refunds, new app access, changing roles in Brand Registry, security alerts. Another anomaly may have another explanation, so verify it elsewhere.
3. What if the unauthorized user changed my email address or phone number?
Use a known Amazon domain, and go through the official account-recovery or Seller Central Help channel. Secure the original mailbox and phone account, keep proof of ownership and Amazon notifications, and log every case ID. Never use a telephone number contained in a suspicious message, ever.
4. Which Seller Central settings should I check after unauthorized access?
Users and Permissions, Seller Account Information, Banking and Charge Methods, Business and Tax Information, Listings and Prices, Promotions and Advertising, Orders and Refunds, Inventory Actions, Applications Connected with Your Seller Account, Brand Registry Roles, Performance Notifications, Account Health.
5. Should I create a new Amazon seller account if I cannot get in?
No, you are not allowed to have an additional account. Don’t open another seller account to bypass the access. Another account may lead to further compliance and linked-account complications, not to mention that it does nothing to resolve the original breach.
6. Is a hacked seller account the same as an Amazon suspension?
No. There’s unauthorized access or changes; that’s a compromise. “Suspension” and “deactivation” are Amazon enforcement actions. The two can, but don’t have to be. Preserve the incident chronology, then address enforcement through the suspension and appeal process.
7. What evidence should I send to Amazon?
Include a brief timeline, impacted surfaces, screenshots or reports, what you have done, previous case IDs, and what specific resolution you need. Redact Sensitive Information And Send Only Via A Verified Amazon Channel. Exact identity or document requirements can vary depending on the case and marketplace.
8. How long does Amazon seller account recovery take?
There is no responsible universal timeline. Recovery depends on whether you still have access, the scope of unauthorized changes, identity verification, the affected marketplace, financial or catalog impact, and Amazon’s review. Track checkpoints and unresolved items instead of relying on a promised duration.
9. What should I do after I regain access?
Run the complete recovery checklist. Verify users, two-step verification, contact and business data, disbursements, catalog, promotions, orders, apps, Brand Registry, notifications, devices, and the Amazon case. Then conduct a root-cause review and move ongoing prevention to the account-protection process.
10. When should I get professional help?
Consider specialist help when access is lost, payout or business data changed, catalog damage is widespread, multiple users or apps are involved, Brand Registry is affected, the Amazon case remains unresolved, or the business lacks internal account, catalog, finance, and security owners.
About the Author
Meet Nandita Nair, an Associate Content Writer at SalesDuo, passionate about creating impactful content that helps Amazon businesses grow and thrive. When she’s not writing, she finds joy in listening to music, exploring art, and getting lost in the world of novels.
