Verifying identity when members contact support

“Hi, I have a new email address. Can you update my account so I can log in?” It sounds like one of the most ordinary support requests you will ever receive, and most of the time it is. It is also one of the most common ways accounts are taken over. If your support team changes the email address on request, whoever asked now controls the account: they can reset the password, see the member’s details and, depending on your site, change payment settings or read private messages.

Support teams are trained to be helpful, and attackers know it. Verifying identity is the step that lets you stay helpful to the real member without handing their account to someone else. It does not need to feel like an interrogation. It needs to be proportionate: the more harm a request could do if it came from the wrong person, the stronger the check.

Sort requests by risk

Group the requests your team handles into three tiers and agree a check for each:

• Low risk: no personal information involved. General questions about content, event times or how a feature works. No verification needed.
• Medium risk: account information, sent to the member. Resending a receipt, explaining a charge or confirming a renewal date. Reply only to the email address already on the account.
• High risk: changes that affect control of the account. Changing the email address, removing two-factor authentication, updating payment details, exporting data, transferring a membership or refunding to a different card. These need stronger verification.

If you are still setting up customer support for your membership site, build these tiers in from the start; it is much easier than retraining a team later.

Verification methods, strongest first

1. The member makes the change while logged in. The best answer to many requests is to guide the member to do it themselves on their account page, where they have already proved who they are.
2. A confirmation sent to the address on file. Send a code or confirmation link to the existing email address, and act only when it comes back. This works whenever the member still has that inbox.
3. A request from inside the account. If your support form is available in the member area, a request sent while logged in carries far more weight than one from an unknown address.
4. Account details only the member should know. For example, the date and amount of their most recent payment and the last four digits of the card used. This is weaker, because some details can be found or guessed, so use several together and never read the answers out for the person to confirm.

Avoid relying on information that is easy to find, such as a member’s name, town or join date, which may be visible on a profile. And never ask for a password. You should never need it.

When someone has lost access to their email

The hardest case is a genuine member who can no longer get into the email address on their account, perhaps after leaving a job. Refusing to help loses you a member; helping too easily loses someone else their account. A written fallback process helps:

1. Ask for several account details together, such as the recent payment date and amount, the card’s last four digits and the plan they are on.
2. Send a notice to the old email address saying a change has been requested, in case the real owner still reads it.
3. Wait a set period, perhaps a couple of days, before making the change, and explain that this is your policy.
4. After the change, sign out all sessions and ask the member to set a new password and review their account.
5. Record what was checked and who approved the change.

Never confirm who is a member

Membership itself can be sensitive. For a support group, a debt advice community or a professional body, confirming that someone belongs could reveal something personal. If a caller asks “Is my husband a member?” or an employer asks whether a named person has joined, the answer is the same: you can only discuss an account with the account holder. Where a third party legitimately manages an account, such as a company paying for team seats or a parent for a young member, record who is authorized on the account itself and verify them in the same way.

A worked example: scripts for a guitar lessons membership

A hypothetical guitar lessons membership gives its support team, led by Oluwaseun, these replies to adapt:

Email change requested from an unknown address: Thanks for getting in touch. To protect your account, we can only change the email address after confirming the request with the address currently on file. We have just sent a confirmation link there. Once you click it, you can enter your new address. If you no longer have access to that inbox, reply and we will walk you through our alternative check.

Refund to a different card: We can only refund to the card used for the original payment. If that card has been closed, your bank can usually still pass the refund on to you, and we are happy to send a receipt to help.

Third-party enquiry: For privacy reasons we can only discuss an account with the account holder. If they would like to contact us, we will be glad to help.

Scripts like these keep answers consistent across the team, and they fit naturally with the habits in writing support replies that solve problems the first time.

Your next steps

1. List your common support requests and sort them into low, medium and high risk.
2. Choose a verification method for each tier, favoring self-service and confirmation to the address on file.
3. Write a fallback process for members who have lost access to their email.
4. Adopt a rule of never confirming membership to third parties.
5. Add verification scripts to your support templates and train everyone who answers members.
6. Log every high-risk change and the checks you made.