The four 2FA methods you'll encounter
- SMS codes. Convenient but the weakest form; vulnerable to SIM-swap and tied to a phone number that's usually the seller's personal number.
- Authenticator apps (Google Authenticator, Authy, 2FAS). A time-based code generated from a seed stored on the device.
- Hardware keys (YubiKey, Titan). Physical device that must be plugged in or tapped for login.
- Backup codes. One-time codes issued at 2FA setup, meant for recovery when the primary method is unavailable.
What must change during handover — always
- The email address on the account.
- The password.
- The 2FA method, seed, and any backup codes.
Anything less and either side retains a re-entry path into the account after the sale. That is the exact vulnerability that produces "buyer paid, account recovered a week later" disputes.
SMS 2FA: the tricky one
A phone number cannot be handed over the way an email address can. Two workable paths:
- Seller disables SMS 2FA during the handover session, and buyer immediately enables authenticator-app 2FA on their side before doing anything else.
- Both sides switch the account to a virtual number (Google Voice, TextNow, MySudo) that the buyer controls. Do this in-session, not before.
Authenticator apps: the cleanest handover
- Seller removes 2FA from the account entirely.
- Buyer signs in, immediately re-enables 2FA using their own authenticator app.
- Buyer generates and saves a fresh set of backup codes.
Never share the QR code or seed of your authenticator setup with the buyer. Sharing the seed means both parties can generate valid codes forever — which is exactly what you're trying to prevent.
Hardware keys
Hardware keys cannot be transferred meaningfully — the buyer needs their own physical key. The seller unregisters their key from the account, the buyer signs in with the temporary window (usually authenticator-app fallback) and registers their own key.
Backup codes are as sensitive as the password
Every backup code is a permanent, one-shot bypass of 2FA. If backup codes generated during the seller's ownership still exist anywhere, the account is not truly secure. Standard practice:
- Seller invalidates all existing backup codes at the end of handover (usually by regenerating them, then discarding the new set).
- Buyer generates a fresh set after re-enabling 2FA on their own device.
Recommended order of operations
- Escrow confirms funds are held.
- Seller: change account email to a fresh handover inbox.
- Seller: disable 2FA on the account.
- Seller: hand over inbox login (email + password + inbox 2FA) via the escrow chat.
- Buyer: sign in, change email to their own, change password.
- Buyer: re-enable 2FA using their own authenticator app or key. Save new backup codes.
- Buyer: confirm access. Escrow releases funds.
What good escrows do at this stage
Every step above happens with the escrow watching the chat log in real time. If one side pauses at the "seller shares credentials" step and the other side then vanishes, the escrow sees exactly when the deal broke and mediates from evidence, not from claims. That's why the process is worth doing inside an escrow chat rather than a private DM.