I'm working on a financially leaning site and was curious — is there a standard amount of time to wait before expiring a reset password link once a user has forgotten his/hers and requested to reset it?

On the other hand, if there is no "standard" as such, how might a UX practitioner go about figuring out what would be a sensible and acceptable period for their use case?

  • 1
    This may be a duplicate post I think. Does this post answer any of your queries? ux.stackexchange.com/questions/42007/… – JonW Nov 6 '13 at 15:24
  • That Q has 4 answers addressing the 'why', none addressing the 'how much' of this question. – Erics Nov 6 '13 at 16:33

There doesn't appear to be a standard.

https://postmarkapp.com/guides/password-reset-email-best-practices has a password email reset guide that includes this information:

Expiration information

If the link expires—and it should—include a sentence to let the recipient know that it expires and how long until the link expires. And, for convenience, include a direct link to where they can initiate another password reset request if the link has expired.

Well-engineered password reset processes will automatically expire or invalidate the password reset URL after a period of time. In some cases, the expiration window may be aggressive, and it’s possible the link will expire before the recipient has an opportunity to check their email and reset their password. So it’s important to clearly communicate both the fact that the link expires as well as when the link will expire.

I think it depends on the use case. If someone is reseting their password and wants access right then, a shorter expiration time would make sense.

If someone is sending password reset emails that may or may not be used immediately, a longer reset time would be useful to the user.

  • 1
    If you give the expiration information as the "time to expiry", make sure you mention when that time starts from, as emails may not always be received immediately. E.g. "This reset link was created at 09:34 on and will expire in 60 minutes". Alternatively, specify the time at which it will expire ("This reset link will expire at 10:34"). For short durations (< 24 hours) it's probably sufficient to mention the date somewhere in the email; for longer durations, you might include the date/day of expiry more explicitly). – TripeHound Aug 23 '17 at 9:57
  • Great link, thanks. The advice on avoiding the appearance of phishing was very useful, even though unrelated to the OP. – Savage Feb 5 at 8:18

Generally when users initiate a password reset, they're actively in the process of trying to get into their account. I would set the link expiration between 30-60 minutes, and insert a message letting the user know when the link will expire and have instructions on how they can re-engage the process again if they need a new link.

However there is an approach where you could use a generic forgot password link for all users and wouldn't need to worry about link expiration at all. Since there are some security issues that arise when you provide a user specific link, you could have all users visit a forgot password page where they have to answer specific challenge and security questions before proceeding to the password reset screen. With this method you reduce the risk of a user's account being compromised if that same user's email account has also been compromised. This approach is outlined in this PDF file.


I think 24 hours is a user-friendly (ie, convenient) time limit. It's easy to remember if you're the requesting party and it gives you plenty of time.

  • 2
    This answer expresses an opinion when the question asks for a standard. – James Jenkins Nov 6 '13 at 19:10
  • The OP requested an opinion if there is no standard. Personally I'd like a bit more explanation of the rationale behind a 24-hour window... – Savage Feb 5 at 8:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.