Ecommerce Seller Accounts Are an Access Management Problem, Not a Password Problem

Security teams classify customer databases, payment systems and source code. Marketplace seller accounts rarely make the list, which is strange, because a single seller account typically controls where money is paid out, who can change that destination, a live advertising budget, and a catalogue that represents most of the revenue of the business operating it.

When these accounts are compromised, the post-incident analysis almost never finds a weak password as the root cause. It finds too many people and too many systems holding valid credentials, with no record of who granted them or when they should have been removed.

A Documented Example

The clearest public case remains the 2018 compromise of Amazon seller accounts, disclosed through a filing Amazon made in a UK court. Attackers gained access to roughly 100 seller accounts over a six month period and changed the bank details attached to them, diverting sales proceeds and loan funds to accounts under their control. The reported access method was spear phishing, which is to say that the attackers did not break the platform. They used working credentials.

What makes that case instructive is the second step rather than the first. Credential theft is common. The damage came from the fact that a single compromised identity could alter the payment destination without any secondary approval, and that the change did not surface to anyone who would have questioned it.

Four Access Paths That Accumulate

An ecommerce operation of any size ends up with four distinct categories of access to the same account, usually added in this order and almost never reviewed afterwards.

The founder credential. Created at registration, often tied to a personal email address, and frequently still the only route to recovery two years later. It outranks every control added afterwards.

Operational staff and contractors. Virtual assistants, freelance designers, customer service staff. In small operations these are routinely given the founder credential rather than their own user, which means the access cannot be revoked individually and activity cannot be attributed.

Service providers. Agencies, prep centres and consultants, each needing a different subset of functions, each typically onboarded in a hurry at the start of an engagement.

Application tokens. Repricers, analytics dashboards, review tools, inventory systems and shipping integrations, authorised through the platform’s API and holding standing access that persists whether or not anyone is still using the tool.

The first three are human identities and get some attention during offboarding. The fourth rarely does.

The Tokens Nobody Revokes

Third-party application access is the clearest example of non-human identity sprawl in a commercial context that security teams seldom examine. A merchant evaluating four repricing tools authorises all four. Three are abandoned within a month. The authorisations usually remain.

Each of those tokens represents a standing grant to read order data, which often includes customer names and delivery addresses, and in many cases to modify listings or pricing. The scope is set at install time, reviewed by nobody, and inherited by whoever acquires that vendor later. A merchant whose own account hygiene is excellent can still be exposed through a defunct tool they forgot they installed in 2023.

The control is unglamorous and effective: maintain an inventory of authorised applications, record who approved each one and why, and revoke anything without a current owner. Quarterly is sufficient for most operations.

Key takeaway: Treat marketplace API authorisations as service accounts. They need an owner, a justification and an expiry review, exactly like any other machine identity.

Why Multi-Factor Authentication Does Not Close This

Marketplace platforms generally mandate two-step verification, which is necessary and insufficient. Three failure modes recur.

Codes delivered by SMS are vulnerable to SIM swapping, where the attacker persuades a mobile carrier to port the number. This is well documented and remains effective, particularly against individuals whose business details are publicly listed, which describes most registered sellers.

Shared authenticator seeds are a quieter problem. When a team shares one login, they often share the TOTP seed as well, usually by passing the QR code around during setup. Every holder of that seed can generate valid codes indefinitely, including after they leave.

Session theft bypasses the mechanism entirely. An attacker with a stolen session token does not need to authenticate, which is why infostealer malware on an operations machine is more dangerous than a leaked password.

Monitor the Settings That Move Money

Detection in this context does not require a SIEM deployment. It requires knowing which fields matter and checking them on a schedule.

Disbursement and bank details are the primary target, as the 2018 case demonstrated. The contact email on the account is the secondary target, because changing it redirects the notifications that would otherwise alert the owner. Together they constitute the entire attack path from access to payout.

Any notification about a change to either should be treated as an incident until proven otherwise, not as administrative noise. The window between a payment detail change and the next disbursement is the period in which the loss is still preventable.

A Practical Access Review

Third Parties Should Not Need Your Credential

Most major marketplaces support granular user permissions, allowing an external party to be given a named account limited to the functions they actually perform. The capability exists. It is simply bypassed under time pressure, because sharing a password takes thirty seconds and configuring permissions takes twenty minutes.

This is worth making a procurement requirement rather than a preference. A provider that asks for the account owner’s credential is describing how it will handle every other client’s access as well. Established operators, including a marketplace operations agency handling accounts for multiple brands, work through permissioned user accounts that the client grants and can revoke independently. Ask prospective providers how they authenticate, how client access is separated internally, and what their own offboarding process looks like when a staff member leaves.

The Underlying Point

Nothing here is novel as security practice. Least privilege, identity lifecycle management and machine identity governance are established disciplines. What is unusual is how rarely they are applied to accounts that often represent the majority of a company’s revenue and hold direct control over its banking destination.

The reason is largely organisational. Marketplace accounts are owned by commercial teams, provisioned without IT involvement, and never appear in an asset inventory. They are, in effect, shadow IT with a payout function attached. Bringing them into a normal access review process is among the cheapest risk reductions available to any business that sells online.