KoltrixVerifying identity before account-access requests by email
A support runbook for email requests to change an owner address, disable 2FA or transfer an account: why email alone is weak proof and how to verify safely.
On this page(7 sections)
- Why email alone is weak proof
- Classify the request first
- The verification runbook for high and critical requests
- Step 1: Don't act on the first email
- Step 2: Prefer in-product confirmation
- Step 3: When the registered channel is lost
- Step 4: Second-person review
- Step 5: Make the change, then notify
- Step 6: Record what happened
- Red flags that call for extra caution
- What to say when you say no
- Keep 2FA from becoming a support bottleneck
- Key takeaways
"I lost my phone and can't log in. Can you turn off two-factor authentication on my account? I'm traveling and need access urgently." It's a sympathetic email, and sometimes it's real. Sometimes it's the last step of an account takeover, and your support team is the only thing standing in the way.
Account-access requests deserve a written runbook, because the right answer depends on verification, not on how convincing the email sounds. This post gives you one to adapt.
Why email alone is weak proof
An email arriving from a customer's address feels like proof of identity. It isn't, for several reasons:
- The sender's mailbox may be compromised. If an attacker controls the customer's email, they can write from it convincingly.
- Addresses can be spoofed or imitated. Lookalike domains and display-name tricks fool busy readers. Email authentication helps, but support should never rely on a sender address alone for high-risk changes.
- Urgency is a tactic. "I'm about to board a flight" or "our CEO needs this now" exists to make you skip steps.
- Public information is easy to find. Names, job titles and even which tools a company uses are often discoverable, so "knowing details" proves little.
The principle: the riskier the change, the stronger the verification, and verification should happen through a channel the requester can't easily fake.
Classify the request first
Not every account email needs the same scrutiny. Sort requests into risk tiers:
| Tier | Examples | Verification needed |
|---|---|---|
| Low | How-to questions, general account questions with no data disclosed | None beyond normal support |
| Medium | Resending an invoice to the account's billing address, confirming a plan name | Request from the registered address; send only to registered contacts |
| High | Changing the owner email, disabling 2FA, adding an admin, exporting data | Strong verification (below), second-person review |
| Critical | Transferring account ownership, deleting an account, disputes between people claiming to own an account | Strong verification, lead or founder approval, written record |
The verification runbook for high and critical requests
Step 1: Don't act on the first email
Acknowledge receipt, explain that you need to verify the request for the account's protection, and set expectations about timing. Never disclose account details in that first reply, not even which email address is on file.
Thanks for getting in touch. For changes like this, we verify ownership first to protect your account. I'll send the next steps from our side shortly.
Step 2: Prefer in-product confirmation
The strongest verification uses a channel the attacker probably doesn't control:
- Ask the user to make the change themselves if there's any way to do it in-product, such as using 2FA recovery codes.
- Send a confirmation to the registered address (not by replying to the requester's email, but as a fresh message to the address on file) and ask them to confirm.
- Ask another admin on the account to confirm the request, for business accounts with multiple admins.
Step 3: When the registered channel is lost
The hard cases are when the customer has genuinely lost access to the registered email or their second factor. Options, depending on your product:
- Confirmation from another verified admin in the same organization.
- Verification through your billing system, such as details only the paying customer would have, handled carefully and never by asking for full card numbers.
- A waiting period with notification to the registered address, so a real owner has time to object.
Document which methods your team accepts. Improvising under pressure is how mistakes happen.
Step 4: Second-person review
For high and critical changes, a second team member reviews the verification before the change is made. It takes a few minutes and is the single best defense against a convincing social engineer working on one person.
Step 5: Make the change, then notify
After making a verified change, notify the registered address (and the new one, if it changed) with what changed and when, plus how to reach you if they didn't request it. If the request was fraudulent and slipped through, this notice is how the real owner finds out quickly.
Step 6: Record what happened
Note in the thread or your support records: what was requested, how identity was verified, who reviewed it, and when the change was made. If anything goes wrong later, this record matters.
Red flags that call for extra caution
- Pressure to skip steps, or anger when you mention verification
- Requests to send information to a different address than the one on file
- A recent change of email or phone, followed quickly by a request to disable 2FA
- Multiple people claiming to own the same account
- Inconsistent details across messages
- Requests arriving at odd hours with unusual urgency
None of these prove fraud. Each is a reason to slow down and follow the runbook strictly.
What to say when you say no
If verification fails, decline politely and without accusation:
We weren't able to verify ownership through the methods available, so we can't make this change. If you can confirm from the registered email address, or have another admin on the account contact us, we'll pick this up right away.
Never explain exactly which check failed. That information helps an attacker try again.
Keep 2FA from becoming a support bottleneck
A common source of 2FA reset requests is a customer who lost their device and never saved recovery codes. Encouraging customers to store recovery codes when they enable two-factor authentication, and to add a second admin on business accounts, cuts down on these requests over time. Koltrix supports 2FA for account sign-in, and the same advice applies to any product your team supports: make recovery self-serve wherever it can be done safely.
Key takeaways
- An email from a customer's address is not proof of identity for high-risk changes.
- Classify requests by risk, and match verification to the tier.
- Prefer confirmation through channels the requester can't easily fake, and use second-person review for high-risk changes.
- Notify the registered address after any change, and record how you verified.
- Decline politely without revealing which check failed.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
