Password Reset: Getting it Right

It didn’t quite come to blows but it was a heated discussion to say the least. I was talking to the incident manager about password resets and if they were incidents or not. In the years since this conversation, I have had this conversation many times with many different people. I haven’t been keeping a record but I think it’s been a pretty even split of opinion.

Passwords are still a large part of life; we are still waiting for a better solution. In most cases passwords need to be changed on a regular basis for security reasons, so I’m going to focus on supporting passwords.

I will start with a bit of a cop-out and say that all interactions with the service desk are “requests”. E.g. When you contact the service desk you are either:

  • Requesting a change (Change Management)
  • Requesting an item from the service catalog (Request fulfillment)
  • Requesting a resolution (Incident Management)
  • Requesting information (Knowledge Management)

The answer to the question is clear right? Request.

Not so fast, the request fulfillment process has monopolized the word “Request” so it doesn’t refer to incidents, or the other processes mentioned above.

Image Credit: Rui Soares

In the end, the question is; “should a password reset be handled by the incident management process or the request fulfillment process?” The answer to this may be different for different organizations. I am going to try and help you decide.

Incidents should be logged when something has gone wrong (or is about to). Incidents are a measurement of how stable your environment is. They can be used to measure availability and how much you are spending to fix failures. If you have 100 incidents one week and 90 incidents the next, then you are most likely making progress (if the incident management process is being followed).

Requests on the other hand are a measure of the growth of an organization or possibly the rate of change. If you have 100 requests one week and 90 the next it means an entirely different thing.

If your organization considers password resets something to be minimized, then it would fit into the incident category.

If you have an automated self service password reset service for your end users and it doesn’t matter how much it is used it would fit into the request category.

If a user needs to have their password reset before they can continue working then there is interruption to service, this would put it into the incident category. Nothing technical has failed, you just have a forgetful user, but some sort of action needs to take place to restore service for that one user.

When it comes to reporting on both processes, it is valuable to measure how many password resets have been actioned because steps can be taken to reduce effort and therefore cost. If you are using the request fulfillment process, you should highlight which of the requests are for password resets. If you are using the incident management process they can be included in the overall numbers. It is tempting to move password resets to request fulfillment to bring the number of incidents down because password resets are often a large percentage of the total.

If you “expect” users to forget their passwords from time to time and consider it normal to have them contact the service desk, you are missing out. Don’t settle for this, a better standard can be achieved.

Either process would be able to successfully handle password resets, in my experience the incident management process is the better fit for most organizations. However, it may be more appropriate to use the request fulfilment process particularly if you have a self service password reset tool. Users will continue to forget their passwords, using the service desk to reset them gets expensive, it’s worth investing in a better way.


  1. It is important to have separate processes for Incidents and Requests
  2. Decide where “Password resets” fits for your organization, and stick to it.
  3. Invest in a self-service password reset tool.