"Please change my login email" is the riskiest support ticket you'll get. Don't do it from the reply.
A plain process for a tiny SaaS when someone writes from a new address and asks you to move their account. Why the last 4 digits of a card prove nothing, and what to ask instead.
Most support email on a small product is boring in a good way. "Where's my invoice?" "Can I switch to annual?" "The export button does nothing on Safari."
Then one day you get this:
Hi, I lost access to my old work email (I left the company). Can you change the login on my account to this new address? My account is under jane@oldcompany.com. Thanks!
It's polite. It sounds completely normal. People really do leave jobs and lose their work inboxes. And if you answer it the way most solo founders answer support, fast and helpful, you've just handed an account to whoever was able to type someone else's old email address.
This post is the process I'd put in place before that email shows up. It takes about ten minutes to write down, and it's the support ticket where being slow is the right answer.
Why this one ticket is different
Almost every other support request is reversible. A wrong refund can be fixed. A plan you switched by mistake can be switched back.
Changing the login email is different, because the login email is usually the password reset address. The moment you change it, the person who wrote to you can hit "Forgot password," get the link in their inbox, and they're in. The real owner gets nothing, because their address isn't on the account anymore. If your product only sends the "your email was changed" notice to the new address, they won't even know it happened.
So "change my email" really means "give account recovery to this new person." Read it that way and the rest of the process follows.
The last 4 digits of a card are not a password
The obvious move is to ask a verification question. And the obvious question for a SaaS founder is billing: "What are the last 4 digits of the card on the account?"
This has failed in public before. In 2012 Wired's Mat Honan wrote up exactly how his accounts were taken over. The attackers got Amazon support to add an email to his account by phone, used it to see the last four digits of his card on Amazon's site, and then gave those four digits plus his billing address to Apple support, which issued a temporary Apple ID password. His line from that piece stuck with me: the four digits one company was happy to show in the clear were the same four digits another company used to prove who he was.
Last 4 is a bad check for a small SaaS too:
- It's printed in lots of places. Receipts, invoice PDFs and "your card is expiring" emails often show the brand and the last 4. Anyone who has seen one forwarded receipt has it.
- It's guessable in context. If someone already has access to a person's old inbox, or a PDF invoice from their accounting tool, the digits come for free.
- It checks the wrong thing. It proves someone has seen the card. It doesn't prove they control the account.
Billing details are still useful as a supporting signal, and I like having them on the user record so I'm not opening Stripe for every email (I wrote about keeping three billing columns on the user for that reason). They just can't be the whole check.
What I'd actually do, in order
1. Try the old address first, every time
Reply to the request, but also send a separate email to the address that's currently on the account:
Someone asked us to change the login email on your account to j***@gmail.com. If that was you, reply to this email to confirm. If it wasn't, ignore this and nothing will change.
If the old inbox still works, this settles it in one round trip. The real owner confirms, or the real owner sees an attempt they didn't make and you've learned something useful.
Better still, don't make it a support task at all. Put "change email" in account settings, require the current password (or a fresh login), send a confirmation link to the new address, and send a notice to the old one. Then the support answer to "change my email" becomes "you can do it under Settings, here's where," and you're out of the risky part entirely.
2. If the old address is truly gone, ask for things only the account owner would know
This is the "I left the company" case, and it's real. Here the bar is: what could the account owner answer that someone with a forwarded receipt couldn't?
Good questions come from inside the product, not from billing:
- The name of a project, workspace or file they created.
- Roughly when they signed up, and what they last did in the product.
- For a team account, which other teammates are on it.
Ask for two or three, compare against what's in the database, and don't hint at the answers. "It starts with M" turns a check into a guessing game.
For a paid business account, there's often a cleaner route: ask someone else at the company. Another admin on the account, or the company's billing contact, can confirm the change. A person who left the company often shouldn't get the account anyway. It belongs to the company.
3. Don't let urgency skip a step
The requests to be most careful with are the ones with pressure in them: "I have a client demo in an hour," "I'm locked out and losing money." Sometimes that's true. It's also the oldest trick there is, because it works on helpful people.
A fixed rule helps here more than judgment does. Something like: email changes requested through support take effect 24 hours after approval, and the old address gets a notice the moment you approve. A real customer with a real deadline will grumble and survive. An attacker loses the one thing they were counting on, which is the owner not noticing in time.
4. Log it
Write down who asked, from which address, what you checked, and what you changed. One line in whatever you use for support is enough. If an owner shows up three weeks later saying "I never asked for this," you'll want to know exactly what happened without relying on memory.
The template I'd keep ready
For the "old email is gone" case:
Thanks for writing in. Since this would change who can sign in and reset the password, I need to confirm it's your account first. Could you tell me (1) the name of a project in your account and (2) roughly when you signed up? Once I've matched those, I'll make the change. It takes effect 24 hours later, and the old address gets a notice too, just in case.
It's friendly, it says why, and it doesn't leak any answers. A real customer reads it as "this company takes my account seriously," which is a good thing for them to think.
The part that's about you, not your customers
The same thing can happen to you on the other side: a stranger convincing your registrar, email host or payment provider that they're you. I put together a longer guide on protecting your own founder accounts from lockouts, covering recovery codes, 2FA and registrar lock, if you want to check your own setup after fixing your support process.
On the customer side, the short version is: confirm from the old address, treat card digits as a hint and not proof, add a delay, and tell the old inbox.
One thing I go back and forth on: if a customer has truly lost their old inbox and can't answer any account questions, do you tell them to sign up again and lose their data, or is there a check you'd accept that I haven't listed here?
Comments
Join the discussionTo your closing question: I'd avoid "sign up again" as the default and offer a slower verified route instead. A few checks I'd accept when the old inbox is gone: (1) confirmation from another admin or the billing contact on a team account, (2) details only the owner would know, like the name of a recent project and roughly the last thing they exported, and (3) a short video call where they log in from their usual device. Give those the same 24-hour delay you suggest. One pitfall: don't let support decide case by case. Write a one-page checklist that needs at least two matching signals, and log which ones were met, so the answer is the same whoever picks up the ticket.
The two matching signals plus a log is the part I was missing. Case by case is exactly where this goes wrong, because whoever is on support that day ends up being the policy. The other-admin check for team accounts is a good one too, cheap and hard to fake. I'm going to write the checklist down before the next one of these lands.