I have searched and viewed most of the other questions and answers about implementing forgot password functionality on a website.

However, we have a unique situation. When a user registers an account and uses their company-based email as the main email account, how can we implement a forgot password scheme if they no longer work for that company and can't access that email account?

We currently use the standard process of sending an email with a reset link to their primary email account. Most do not have a secondary email address and we do not want them to be able to enter just any email address to send the link to.

Is there a design pattern or process whereby we can have the user enter some information and be taken to a page where they can be allowed to change the email address to send the reset link? BTW, we do not want to use/store security questions. We can find the person by the information provided using a query about their account record via our web service.

How has this kind of thing been done before? I don't know of any sites that do this because most of them require to send an email to the user's account.

I was thinking something more along the lines of how Experian, TransUnion and Equifax do it when you check your annual credit report. They ask you questions about accounts that are on your report and if you answer them correctly, you are authenticated.

  • 4
    There's something that sounds quite illogical to me with this design. If people sign up using their company e-mail, doesn't that mean that whatever they're doing on your system is related to that company? Therefore, if they leave the said company, shouldn't they no longer have access to their account or at least no longer need it? If what they're doing on your system is not related to the company, then they should sign up with their personal email account.
    – Simon
    Commented Jun 19, 2015 at 17:32
  • We sell professional education, why wouldn't they be able to use the same account when they switch companies. Have you thought of that? AFA their personal email, yes, they can use it and a lot of them do, but most of them use their business email due to this being a somewhat business related account.
    – MB34
    Commented Jun 19, 2015 at 17:37
  • 2
    I would not expect someone to sign up with their business email if they want to use their account for another purpose than their current business they are working for.
    – Simon
    Commented Jun 19, 2015 at 17:45
  • You may be one in a minority as the majority of our users use their business email. They want to get email correspondence about their education AT WORK instead of at home.
    – MB34
    Commented Jun 19, 2015 at 17:48

8 Answers 8


Ultimately, you need to establish some kind of secret with the client that is:

  1. easily remembered
  2. unrelated to their email/password combination
  3. non-trivial to guess

Since you've ruled out security questions (which are iffy at best due to reason #3), you're left with a few options.

As mentioned before, a phone number is a good choice. Phone numbers don't change frequently. It's highly unlikely that somebody will change jobs and phone numbers simultaneously.

A secondary email address is about as good as the phone number, since people tend to keep their personal accounts for a long time. Consider bothering your current users to set one up.

You could give the user a password reset token - a very long string that is saved offline and only retrieved if a reset is needed. This won't work if the users don't bother to save them, though, which is likely to happen. It's also awkward to use, and doesn't do squat for existing users.

Addressing the other half of your question is going to be trickier. You only have the following information:

  • Email (defunct)
  • Password (forgotten)

One solution that springs to mind is to have companies verify that their old employees owned the defunct email addresses. This would be a time sink, however, and it relies on cooperation (and record-keeping), both of which are not guarantees.

As you suggested, you could see if the users recall any important private details from the account. This would be a glorified security question, though, and I seriously doubt that people who have forgotten their passwords will remember that much information.

Finally, do you store any payment details (e.g. monthly billing)? If so, you might be able to verify identities that way.

  • 1. We have definitely decided against using "security" questions. 2. Many of our 280K users have secondary email addresses but that wouldn't help the ones that don't. 3. The password token idea is kind of like MS Window's Workgroup password. In order to let others connect to your workgroup, you have to keep that info handy.
    – MB34
    Commented Jul 10, 2015 at 18:53
  • 4. AFA as the employers helping out. I don' tknow of any that would and most delete old addresses shortly after the employee leaves. 5. As I have pointed out to @user2320464, we have 85K users that don't have a stored cell phone number and I would not believe that every one of the 195K that do would have SMS enabled phones. 6. Now I did think that we could offer an option to have it sent to their secondary email, and for those that don't have one, they'd have to call in.
    – MB34
    Commented Jul 10, 2015 at 18:54
  • You'd need cooperation from the employers to verify that the person trying to reset their password is actually the person who owns the email. Larger ones would probably get annoyed after receiving dozens of requests, given the size of your userbase! Commented Jul 10, 2015 at 20:25

You can offer entering a phone number and send password recovery message there (like Microsoft does) or using some things that only the user knows (e.g. ID of last ivoice)

  • 2
    We also create a User ID AND a User Number and it is communicated to them in almost every communication we send them, including paper. But the majority of them couldn't tell us what either of them are.
    – MB34
    Commented Jun 19, 2015 at 17:40
  • 2
    We formerly used Last 4 of their SSN and Date of birth as well as their email and matched on a combination of the three. But we have since quit recording their Last4SSN so that is no longer an option. Hey, maybe we could still offer to let them change their email if they enter the last email they used and their DOB??? But... both those are easily accessible by others.
    – MB34
    Commented Jun 19, 2015 at 17:50
  • 2
    One thing we've looked into is allowing them to send the reset email to their secondary email address if they have one. This only supports 40K of our 284K users that have secondary email addresses. I intend to let marketing know they need to send out a communication to all users notifying them that access to their account will be made easier if they supply a alternate email. I will also be adding a secondary email to the registration page.
    – MB34
    Commented Jul 14, 2015 at 18:40
  • 2
    "You can use this (entering last email), together with date of birth" Now how would this let them receive the reset email?
    – MB34
    Commented Jul 14, 2015 at 18:57
  • 3
    The majority of our users are in their 30's and up. They are not as computer literate as we'd like and even have difficulty logging in. Many of them won't even register for our courses online, they place a phone call because that is just the way they've always done it. We already send them an identification card with their ID on it but the majority of them don't even know what their ID is even though we include it on ALL correspondence. Getting them to do these types of things is why we want to help make things easier for them.
    – MB34
    Commented Jul 15, 2015 at 15:30

As part of your online registration process, ask for their preferred email address AND their personal address (or backup address). When resetting the password check for both accounts and send to whichever. Add in some marketing-like text to the effect of:

If you're using your work email address and leave the company we want to make sure you can take your training with you wherever you go. Add your personal email address to make sure you can always access your training.

This doesn't quite work for existing users, but I think its a better long-term approach than having them try and find a bunch of random numbers that were communicated to them months ago.

  • We already offer them to enter a secondary email address after they create their account. Most don't and we can't force them to and current users that don't have one could not use a feature that relied on it.
    – MB34
    Commented Jun 19, 2015 at 18:01
  • Seems we may go this route as customer service says they can send out notices to all 245K users that don't have secondary email to let them know this.
    – MB34
    Commented Jul 16, 2015 at 13:44
  • This relies on the assumption all users have a secondary email or want to provide one. It may increase your bounce rate to complicate your sign up process. Are you going to verify both emails as well? Do both need to validated in order to gain access. Converting existing users will be difficult and it does not seem feasible to make this compulsory. Management would likely rather have disgruntled customers who paid and lost access rather than have customer who don't sign up in the first place.
    – Eric G
    Commented Jul 17, 2015 at 15:02

Some theoretical ideas which may work based on what information is available to you

Offline to their known billing address

It sounds like this is a commercial service. For some users, if they are using a personal credit card, etc. you may be recording their person billing information - you could send an offline reset code via postal mail to those users (like when a bank sends you an ATM pin). That would be slow, but hopefully there isn't someone someone snooping in the user's postal mail.

Re-verify the Credit Card on file with Card Security Code

If the use is using a personal CC, I have a theoretical scheme I will share below. I was thinking about Address Verification System, but I do not believe that requires the card security code (e.g., CVV) in general. Consider this process:

Request the user to make a small purchase on your site with the same credit card they had on file - maybe something like $.50 (you can offer to reverse this charge immediately after the verification or call it a special reset fee)

Then make the payment using the same billing information, credit card number that is on file. While the billing information may be easily research for a given individual, the credit card number should be hard to pull out of no where, and the card security code even harder.

This could be fairly automatic and validates against information you have on file.

Links to other identities

Let's say that your service allows users to enter in a social network profile into their account. Since this is a business tool, maybe you ask them for their LinkedIn profile for no reason at all, or maybe for an actual purpose to post their achievements on their timeline. Maybe you have a setup where you automatically tweet the courses a user completes, etc. Since the user entered her social media information into her profiles, you can ask her to validate through the social media service.

I recall Stack Exchange doing this at some point to merge two of my profiles, you put some type of message in profile of both accounts and then contacted an admin to do the merge. In your case, you can just private message the account the user had listed in her profile since its unlikely she would have added some random person's account on her profile on your site.

If you wanted to take on more risk, you could ask a user who never entered a social media profile before losing his old email to provide you with a few social media profiles and do some due diligence to see if those profiles seem legitimate (has real friends/followers from the same company the person used to work for). You can then requires at least two good profiles, ask them to put some update on the site or in their profiles to prove they own the sites or direct/private message them on both platforms to make sure they own them.


In the end, I assume the reason they would not just make a new profile is because they are paying for the service and they want that for which they have already paid. As they say, follow the money... However, this will not work if they used a corporate card they no longer have access to. Maybe they have an old copy of an invoice or credit card statement they can send to you in that case, is not very likely someone else outside of payroll/reimbursements has these types of documents. I would say if you can't do something with billing information, then maybe try the route of social media I described above.

I do not think you will easily be able to create a secure and robust platform to do this automatically, but I would also imagine you will not have hundreds of these cases a day. I would try to start with the most reliable and then work down on an individual basis to what is less reliable or more time consuming.

Thoughts on other strategies

It looks like the path you are going with right now and suggested in many of the other answers rely on taking in additional identification information at sign-up (ideally) and then using that information to later validate user when she no longer has her email account. The problem is that any of the information you are likely going to collect can be researched or found. You may run into a UX problem (why so many fields, why are you invading my privacy, etc.) if you start asking for a lot of information which is not relevant to your service. If you ask them to validate a lot of information it increases difficulty, but it doesn't sound like this will meet you requirements for reasonable assurance. The same issues apply with security questions.

Some of the other answers rely upon the user validating their identity by previous actions taken on the site. Depending upon your services this may be possible, but in many cases the actions could be difficult to remember, too much activity may be publicly known, or may be generic enough that any other user could impersonate the user. There is some potential with this path depending on your specific circumstances.

Other suggestions include asking for something that the user will carry with them such as a secondary email or a mobile phone (assuming they don't also give you the corporate mobile phone number). Any other type of token, hash, file, etc is probably a moot point if they are using their corporate email they are probably using their corporate computer and won't have access to this if they no longer have access to their corp email.


I see some of your questions related to SMS and availability on all user phones. Going on the assumption you have their personal phone and not their work phone, there are non-SMS based solution that use a VRU/IVR etc to give a code via voice. If you have a valid, accessible phone number then you should be able to contact that number via SMS or a voice prompt system. At the very least, at low volume, you could have a human call the number on file when a request is made. Hopefully there is not a high volume of users who moved on and forgot their password on a daily basis.


It really depends on the information provided by the customer when registering for your service. If payment is required, ask for some identifying information regarding that transaction. If the customer provides their phone number, send an SMS token. So on and so forth. If none of this applies then communicate the importance of registering a second email address.

Whatever solution is used, I would also advise that you communicate the process to your customer. Google does a great job of this with GMail and enabling two-factor authentication. An alert appears requesting to register a phone number to enable this functionality and make your account more secure. Take the same approach with your own service by letting the customer know (for example) a password reset token will be delivered to their registered phone number via SMS.

  • Not all users have SMS enabled phones and this wouldn't help the over 85K users we currently have that don't have one stored at all.
    – MB34
    Commented Jul 10, 2015 at 18:43
  • I understand, SMS was just an example. My suggestion is to leverage any information you already have as part of the registration process. Then let your customer know what pieces may or may not be used during the password reset process. For example, if they don't have an SMS enabled device suggest they register a second email account. Commented Jul 10, 2015 at 20:14
  • I'm curious about the non SMS enabled phone use-case. Do such phones even exist? I thought SMS had become a default by now? What fraction of your users have non-SMS enabled phones? Commented Jul 17, 2015 at 2:54

Since you've ruled out:

  • Security questions
  • Phone Number
  • Secondary email

You're left with a no many options, may something physical and storable by user as a file:

1st Option:

You can create a secure file, with some hash information, and you can match the filename with file content.

eg. bff295a929d9872817f3fd282459bd4f9ff7a71b7917778e6eb36c09f21a789c.txt with content


Using this security file (Of course, may you can use a stronger encryption method) people can recover their account.

2nd Option:

You can provide a file with backup codes like google to 2-step logins

" The codes come in sets of 10, and you can generate a new set at any point, automatically making the old set inactive. In addition, after you’ve used a backup code to sign in, it will become inactive."

Based on this unique codes you can restore the client account.

The client must keep this file in a secret for future recoveries, may stored in a Drive, Cloud Driver, Printed Paper or something else.

You can provide a message like:

"We recommend you store your codes wherever you keep your other valuable items. Like the codes on your phone, backup codes are only valuable to someone if they manage to also steal your password."

Together with file you must request some unchangeable information like Birthday.

I know it sounds a little fool but in actual scenario, there a limited solutions.

  • I think asking regular users to store and manage a file is problematic because its something they will likely have on their corporate computer in this case (with corp email) and will not have access to this after they leave. Also, I do not think average users would get hashing. The codes are another item they need to store and manage, but who is going to plan ahead to put this on their personal system; its also something they have little incentive to manage on a regular basis and likely to get lost.
    – Eric G
    Commented Jul 17, 2015 at 13:14
  • You're right, but with the alternatives were eliminated lack of user information to have a consistent validation. I'm taking into account the ease of having a cloud drive today, he can attach the file through a corporate e-mail and send it to your personal e-mail is also very easy. The advantage of this model is that you delegate security responsibility to the user himself(must be explicit on use term), for this reason that the messages that I mentioned above are important. I see this means of password recovery and email as a last resort. A call center-like business model can also be useful. Commented Jul 17, 2015 at 16:06
  • 1
    I would imagine many orgs block cloud sites and prevent sending out attachments in some cases. I don't think its an advantage to the company to empower the user, you want it to be frictionless. It seems the main goal here is to keep a paying customer happy and coming back, managing a file like this is a big ask for the user.
    – Eric G
    Commented Jul 17, 2015 at 22:23

What exactly you require is intermediary secure connection from a password reset perspective for your customers to be able to reset their passwords. You opted out of phone numbers, secondary email as it conflicts with large corporate accounts using the service, and you have had also ruled out using file backups to store hash (+plus this out rules simplicity and introduces more complexity and all in one - security via obscurity).

Security via obscurity is often discouraged in security industry and could led to unknown circumstances of information breach and hence could be worth an immediate response plan. Keeping all of this into consideration and taking simplicity by design to concept.

High Level Details of Implementation: Here’s what to do to fix the security issue designing: gather copies of all of the credit related statements received each month. This should include any loan or credit obligation that likely is being reported to the credit reporting agencies, such as credit cards, mortgages, auto loans, and student loans. Look at how the name and address is displayed on the statement. This is very likely going to be how customers name is showing up in the credit bureau’s systems and it should hint at how to request a copy of your credit report. If a part of the displayed results could be utilized and is confidential to only the customers, the system could use it.

If that doesn’t work then this quest is about to become even more difficult. But to keep it simple again, you could instead of a TXT SMS, alternatively set-up a VoIP server and implement voice messaging system to auto retrive a single sign on token (not the hash, but the reset token number {this is one time generated}) and set a rate limiting expiration time to that token or the random number. This will again depend on random questionaries asked by the automated voice tunnel which requires either of these information in 3 step process:

  1. SSN
  2. Mix of SSN + Last Name
  3. Mix of SSN + Last Name + Last Tried Login Date (DD/MM/YYYY)

The mix of all these three components should then get you a single sign on reset number and when you input this reset number within the timeframe, you get the reset link. Using the reset link, the user could be able to reset their passwords without having to completely rely on a TXT based OTP service. The Last Tried Login Date could seem complex but you can actually ask your customers to precisely state 'last login date which were successful/unsuccessful', and the system can match it up against the session tokens set up for a particular username (application API should had stored the timestamps).


IMO there are some other ways to solve this but it will depend on your current system and needs. For example, you could provide a client certificate that they can install in their browser and that way they can be easily identified.

Now, if they can no longer access from that browser (eg. company pc), other way could be to generate a file that could be stored somewhere in case they lost their password and that could be used to access to their account (like instead of password). However if that file is compromised their account is compromised as well.

I think the best way is to offer SSO (OAuth/OpenID/SAML/etc) login options so they can use 3rd party personal accounts as authentication. That way they no longer depend on their company email to get access.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .