Account stolen or banned? Don't panic: account appeal and recovery for vibe projects

When an account goes wrong, most people's first reaction is the wrong one. Some hammer the "reset password" button until the account locks completely. Some run to social media to complain, publishing their personal details along with their appeal. Others, in desperation, pay a shady "unban service" and hand over whatever control they had left. In reality there are only three situations, and each needs a different response: the account was stolen, and someone else took your identity; the account was banned, and the platform restricted you; or the account locked itself, because you tripped a risk control or lost your verification method. Spend three minutes telling them apart before you act, and every later step gets easier. This guide covers recovery after something has gone wrong — not everyday prevention. Device and session management lives in the published login-devices guide, and two-factor setup lives in the published two-factor guide; those two are the "before", this one is the "after".

First, tell the three cases apart

Stolen accounts leave concrete traces: login alerts you did not trigger, a changed password, a replaced recovery email or phone number, content you never wrote, unfamiliar charges. If you can still log in, do not start by editing your profile — check the login history and session list first to see whether the intruder is still inside. Banned accounts announce themselves from the platform's side: a restriction notice at login, features switched off, content removed, usually with a stated reason such as a community-standards violation or suspicious behaviour. A ban is not a theft, and the path is different: theft means winning back control, a ban means proving your case or owning a mistake. Self-lockout is the most common and most misjudged case: a new phone without the authenticator app, a drifted authenticator clock, lost backup codes, a temporary lock after repeated wrong attempts. Nobody is targeting you; the verification chain simply broke, and recovery depends on the backup methods you set up in advance, not on how moving your appeal letter is. Acting before distinguishing the cases produces predictable damage: theft victims who keep receiving verification codes at a compromised email, banned users who file repeated appeals and trigger anti-abuse limits, locked-out users who turn a temporary lock into a long one by retrying.

The golden hour: eight moves after a theft

Once theft is confirmed, follow this order and do not skip steps. One: change the password immediately from a clean device — clean meaning not the computer that may carry malware, ideally a phone on mobile data. Two: change the password of your recovery email, because email is the root of every recovery flow; lose the email and the account is gone for good. Three: sign out every session and revoke all login states and API keys, so whatever the intruder holds stops working at the same moment. Four: check billing and subscriptions, freezing the payment method before disputing charges, since the reverse order can cost more. Five: review what was changed inside the account — signatures, forwarding rules, third-party authorisations, connected apps — and revoke them one by one. Six: take screenshots as evidence, with timestamps: abnormal login records, altered profile data, unfamiliar content. Memory alone will not do. Seven: notify your contacts and users briefly and plainly that messages sent in your name during this period should not be trusted — short, specific, without drama. Eight: only now file the platform's security report or appeal, attaching everything from the previous steps at once. The order has a logic: stop the bleeding, gather evidence, then negotiate. People who skip to the appeal usually end up writing "I was hacked, please help", and support teams process thousands of such letters a day; appeals without evidence go to the back of the queue.

The appeal evidence pack: graded proof, no essay

The most common flaw in appeal letters is too much emotion and too little evidence. Support does not judge how miserable your experience was; it judges whether you can prove "this account is mine" and "this is what happened". Prepare evidence in three grades. Strong evidence is what only the owner would have: receipts from the original registration email, the earliest bills and payment records, purchase history, and identity documents matching the account information — provided only through official channels and only when the platform asks. Medium evidence is behavioural trail: long-used devices and cities, frequently used features and content, corroboration from friends or collaborators, past support history. Weak evidence is subjective memory — "I think the password was something like…" or "I always used this avatar" — worth including, but never decisive. The letter itself should stay within three paragraphs: one sentence stating the request, a chronological list of facts with evidence, and a clear statement of what you want the platform to do. No long complaint, no irrelevant screenshots, no three contradictory appeals filed on the same day. One submission, complete evidence, and keep the ticket number. If the platform offers a dedicated appeal channel, use it instead of a general support mailbox; if it asks you to pick a reason category, pick the one closest to the facts, because the wrong category routes you into the wrong queue.

Appealing a ban: name the cause before you write

Ban appeals are a different genre from theft appeals. Theft appeals prove "I am the owner"; ban appeals explain "what this incident actually was". Before writing, copy the platform's stated reason verbatim, then compare it with your own activity log and decide which bucket you are in: a false positive, where the system mistook normal behaviour for a violation; a borderline case, where the behaviour did touch the line but lightly; or a genuine violation, where owning it and fixing it is the only credible move. False-positive appeals should be built on an evidence chain: timestamps, action records, context — for example, a shared exit IP that caused a misflag, an automation script that tripped a detector, or content quoted out of context. Borderline appeals should acknowledge the boundary, explain the intent, and offer concrete fixes; "everyone does it" is not a reason. Genuine violations should not be argued away; admitting the mistake, removing the offending content and stating how you will avoid it next time earns more leniency than any explanation. Three red lines apply to every category: never fabricate evidence — once discovered, fabrication ends any second chance; never threaten support staff or threaten to go public, since threats only get the ticket flagged; and never open several appeal channels with inconsistent stories, because inconsistent accounts are the easiest reason to reject outright. The following example is fictional and illustrates format only, matching no real platform: a user of a fictional notes app, called Xiao Lin here, was temporarily restricted after bulk-exporting data in a short window; his appeal stated the export time, that the notes were all his own, and that the reason was a backup before switching devices, with a billing screenshot attached, and the platform lifted the restriction after verification. The point is not Xiao Lin but the structure: facts, timeline, evidence, request — all four present.

The 24 hours after recovery: do not celebrate yet

Getting the account back is only half the job. Run this list through the first day after recovery. Force every device to sign in again so no leftover session survives. Rotate every API key, third-party authorisation and in-app token, because the old ones may have been copied. Check billing and subscription settings for altered auto-renewals or added items. Check content and profile data for tampering, including signatures, avatars, public profiles and auto-forwarding rules. Re-enable two-factor authentication and print the recovery codes somewhere offline. Check the recovery email's own security settings, including forwarding rules and secondary addresses, because intruders often leave a back door in the mailbox. Then send your users a recovery notice: the problem is resolved, and messages from the affected window should not be trusted. That notice matters because much secondary damage happens not on the day of the theft but in the days after recovery, when the victim believes everything is already fine.

When the root email is gone, the phone changed, or the account is shared

Three hard cases deserve separate treatment. Losing the root email as well is the toughest combination, since nearly every recovery flow depends on it. Do not wrestle with the account appeal first; recover the mailbox first through the mail provider's own flow — secondary email, secondary phone, historical devices — because once the mailbox is back, the account recovery has a foundation. If the mailbox is unrecoverable, only the platform's manual identity verification remains; prepare material proving long-term use and accept a longer wait. A changed phone number is easier: as long as the email works and the password is remembered, most platforms let you swap the number after login; if login itself is impossible, it depends on whether the platform supports backup methods such as recovery codes, secondary email or manual verification — which is exactly why printing recovery codes offline matters. Shared team accounts produce the messiest disputes: departing staff walking away with the account, unclear handovers, several ex-colleagues filing conflicting appeals. Prevention belongs in everyday practice: write account ownership into the handover checklist, separate admin from ordinary permissions, and register critical accounts under organisational management rather than personal mailboxes. After an incident, the legally owning party should lead, with organisational proof attached, rather than letting several former staff appeal separately. All three cases share one rule: recovery difficulty is set by how many backup paths you left in advance.

A small team's appeal SOP: do not let support improvise

If you build a product, user appeals will arrive sooner or later, and how you handle them is part of the product. Set four rules. One: triage — obvious cases with complete evidence take a fast lane, doubtful cases get human review, and cases involving money, legal exposure or press attention escalate. Two: published response times for every tier, even if the first reply is only "received, under review" — a reply beats silence by an order of magnitude. Three: a phrase bank with five templates — requesting more evidence, under review, restored, decision upheld, escalated to a human — each stating the next step and the expected time, so agents never improvise. Four: a monthly review of appeal data, because the rule that generates the most false positives is the rule most in need of repair; appeals are not a cost centre but a product-quality sensor. And one hard floor: never ask users for passwords, verification codes or ID photos through unofficial channels, and tell your users that anyone doing so under a "support" name should be treated as suspect. That rule belongs in your support handbook and in your user-facing guidance alike.

Five anti-patterns: stop on sight

One: paying an "unban service" or a supposed insider contact — the money goes, the account details go with it, and paying for that is itself against platform rules. Two: posting ID documents, ticket screenshots and appeal details in public to create pressure — that hands identity-theft material out voluntarily. Three: registering a new account after a rejection and repeating the same behaviour — the new account gets linked and banned, and the appeal gets harder. Four: storing recovery codes, backup emails and passwords in the same cloud note, so one breach equals total breach. Five: changing nothing after recovery — same password, same sessions, same authorisations — and waiting for the same person to use the same method again. Recovery is not finished at "I can log in"; it is finished when the intrusion path is closed, the evidence chain is complete, users have been notified, and the process has been reviewed. And the best recovery preparation is always done while everything is normal: print the recovery codes, and leave backup paths in place.

A final word for product builders: the moment a user contacts you about a lost or banned account is the moment their trust is lowest and most in need of care. The deeper the appeal channel is buried, the slower the replies, the more perfunctory the wording, the more you lose than an account — you lose a group's basic trust in the platform. Conversely, a channel with a clear entry point, visible progress, explicit evidence requirements and reasoned outcomes earns acceptance even when the decision is upheld. The design standard is simple: make it easy for honest users to prove themselves, hard for abusive appeals to slip through, and turn every false positive into a chance to fix a rule. Meet those three, and your appeal channel stops being a cost centre and becomes the most convincing proof of your product's credibility. All specific people and dialogues in this guide are fictional examples used only to illustrate format and structure, matching no real platform or real user.