Skip to content

The best SSPR criteria - what you should be looking for

When deciding what criteria to use for your SSPR solution start with the business case – why are you looking for a self-service password reset tool?

We see 3 different objectives for most SSPR projects:

productivity for end-users icon

Productivity for end-users

productivity for service desk icon

Productivity for the service desk



best password self-service resetWhat are the 10 best SSPR solutions for you to consider for your SSPR project?

In this section of our guide to the 10 best SSPR solutions we will review what the objectives means for your requirements.

We have sorted the criteria in 3 groups (with detailed explanation below):

The most important

  • What passwords do users forget? They must be included
  • What MFA devices do we use today?
  • Do you have many different processes for different user-groups?
  • Your technical infrastructure
  • Cloud / On-premise
  • IT-security

The important

  • Work-from-home
  • Enrolment process
  • Credential Provider
  • Languages
  • Service desk integration

Good to have

  • Password Policy
  • User interface
  • Reporting
  • Notifications

Cost for the SSPR solution and for implementation/operation are very important too.

Our experience is however that the positive impact of the business case is more important, so remember to include the benefit side of the equitation, as different solutions probably produce different benefits! We have however not covered the cost of the solution in this guide. Contact the producers or their implementation partners to get the correct cost for your situation.

If you provide IT service for other organizations we name it Managed Service Provider (MSP), then you have special requirements in addition to what a normal company will have. We have a section below to represent this.

The most important criteria

Flexibility/configurability for individual groups

If you have implemented or worked with Identity Management solutions you have learned how complicated your own organization is, and how difficult it is to match reality to the simplicity of the solution. What looked so simple in the demonstrations before buying has now become complex, because you have an unlimited number of different scenarios.

It is the same situation for SSPR solutions. Different countries, different divisions, different security sensitivity, different devices, different languages and more. Don’t expect that one set of rules and processes will satisfy your situation.

If this flexibility is not present, you’ll not be able to get the user acceptance, or you might not even be able to offer the solution to significant number of users. It will degrade your productivity case.

Cover the corporate passwords you have

All SSPR solutions cover Active Directory. But do you have other passwords? We know from many customers that due to the importance of data in their SAP systems the user verification process for new SAP passwords takes longer time than for the Windows passwords. So, if the SSPR solution doesn’t support your SAP passwords you will continue to waste time resetting SAP passwords and your productivity business case will lose!

If you have SSO solution you only have one password for the user. If you don’t have SSO you help users with password synchronization which is a much simpler and cheaper solution to implement and operate than SSO. As well SSO as Synch means however, that if a criminal gets the user’s password all systems open up! For this reason, some companies maintain that different passwords are required. Then you need a portal where the user can select what password to reset.

You don’t need to have self-service for all passwords. If you have 10 users with passwords to your bank, then don’t try to implement your self-service solution here!

If you however have end-point encryption for many PCs as MS Bitlocker, then look at the lost time related to forgotten passwords here. It might very well take more than half an hour for a supporter to assist the user in this situation!

Authentication / verification methods

When a user can do self-service of passwords, we must have a verification process which guarantees that criminals can’t steal a real user’s identity.

If you have implemented tokens for your log-in process this is where you should start: Can the SSPR solution support my present MFA method?

Most MFA methods today are based on smartphones. What happens then if the user has forgotten his smartphone, or it is broke? Will we deny him self-service? And if he then calls the service desk how can he then convince them, that he is legitimate?

For these reasons and to cater for situations where you can’t have a smartphone or you can’t expect your user to have one, then alternatives must be available. Make sure that your future SSPR solution can help users, when the obvious method is not available!

Your verification logic must follow your authentication logic! If you in the user’s situation will require 2-factor authentication for a log-in you must also require a 2-factor verification in SSPR! If single factor is OK for login authentication, then single factor should be OK for SSPR too.

Some organizations have employees of such high security sensitivity that password self-service is not accepted. Even for manual password resets very strict procedures have been established. For these situations you can demand that special authentication by manager or trusted colleagues is available.

On-premise or Cloud

Your MSP solution must match your IT-strategy. This can mean that an SSPR solution with good functional score is out, if it doesn’t match your operational strategy.

IT Security

Can’t we expect that all solutions are secure against attacks from hackers? Perhaps, but a strong recommendation is still for you to make your own penetration test when you have installed the SSPR solution. What about man-in-the-middle attack, code-injection, zero-days vulnerability and many more risks.

As a prelude to your internal penetration test ask the SSPR provider to document, that the solution has been penetration tested by an external security company. Then you reduce the risk that you waste your time later.


If you need to operate multiple individual accounts, you need a multi-tenant solution. A real multi-tenant solution will allow each individual tenant to configure the solution differently from the other tenants.

This is of the highest value for Managed Service Providers. Different configurations for all customers require a true multi-tenant solution

Technical requirements

A basic assumption is that the SSPR solution will work in your environment today and in the future.  For this criterion we have to ask the vendors to confirm the support of your infrastructure, and perhaps ask to do a POC in the your environment. This criterion is not represented in our charts.


Important Criteria for many


An issue for many users now, is that their service desk can’t reset the cached PC password, when the user is outside the domain. Some solutions offer reset of the cached password, which can have a significant impact on the business case. We warn against solutions where this functionality is achieved by local PC apps. The preferred solution is a VPN connection, which will let Windows synchronize the passwords.

Credential provider

When a Windows password is forgotten the user can’t remember what to do, and she will call the service desk! Unless of course the help is just in front of her. As most Windows problems start at a PC the user must be able to use the PC – even when the password is forgotten. SSPR products solve this with a Windows credential provider which allows the user to do the password reset from the PC BEFORE log-in with a visible icon. Without this most password calls will continue to be called to the service desk.


As SSPR solutions have a simple and intuitive user interface, do we need other languages than English? YES! If you want your users to trust a solution for passwords, we must be sure they fully understand what is communicated. The normal language for the IT applications must also be used in SSPR! And it is not only in the menu and dialog but also for the emails and notifications. Consider countries you have operations in and make sure you can have all the languages you need.

Enrolment Process

The SSPR solution needs information to verify users. For some simple SSPR solutions no Enrolment Process exists and then the IT-staff must manually send emails to motivate users to enroll. This doesn’t work!!

The efficient options are:

  • Avoid enrolment: Some information is available at AD which can be used: Mobile phone number, personal information, private email and other. In general, it is not recommended if the passwords protect sensitive systems
  • Forced enrollment: A credential provider forcing users to enroll SSPR when they log-in to Windows. Very efficient – but only if the user has a domain PC
  • Automatic email enrolment: An automatic process sending emails to users until they enroll. Necessary to enroll users where forced enrollment isn’t possible

If enrolment hasn’t been successful, it will directly impact the business case negatively!

Service desk process

With an SSPR solution you don’t expect to have password calls to the service desk. Our experience are however, that even the best implementations still have users, who cant do the verification or for other reasons can not do self-service. Then the service desk can do a password reset / unlock as they have always done.

A better solution is to bring the user back into SSPR. Helping the user enroll in SSPR and make sure they understand will increase the probability that the user does self-service next time. This can be combined with a limited use of the user’s Q/A to make a user verification. We call this light service desk support.

The best solution at the service desk is to make a strong and secure process for the verification of the user. For a social engineer who wants a specific user’s password the easiest way is to call the service desk and impersonate the user and convince the supporter to help. Social engineers can be very persuasive!!

But if the supporter is forced to follow a workflow specific for the user’s profile and this is the only way to get a password reset the social engineers will give up. In this way the combination of SSPR and a forced verification workflow in the service desk prevents identity theft by social engineers. We call this Secure Service Desk Identity Verification. To work efficiently it must be integrated with your ITSM solution.

This might be important

Some criteria are important for some companies and unimportant for others. Some SSPR functionality can be solved outside the SSPR solution with only a smaller loss of functionality and value for the business case.

Password Policy

Users reset the password in SSPR. It works best if the user can get direct feedback on the compliance to the password policy. We call this a Password-Meter!!

Many companies want however to have a password policy which extends the AD strong password policy with better solutions. We call this Extended Password Policy. For the Extended Password Policy to work in real life it must also be active outside the SSPR situation, as when users do a simple password change (CTRL-Alt-Del / Password change in Windows). We call this Password Filter.

User Interface

To what degree can you modify the user-interface to match your own company’s design line? This is important, as users might deny using a password service, as they might be concerned, that it is a fake site, which they have learned not to trust!!

The possibility to modify text, logos and design can be important in user adoption.


We meet different customer strategies for reporting on Key Performance Indicators like Enrollment, Success rate for verifications, Value of password resets and unlocks, and all split on different user groups and much more.

The main strategies can be split into:

  • All reporting available from the SSPR tool
  • Reporting to be represented and integrated in the ITSM tool
  • Reporting available from the internal Data Warehouse reporting tool

Consider what will work best in your environment.


It is important to get notifications when important actions happen. It might be notifications to end-users when their password is reset (“If not you – contact the service desk immediately!!”). It might however also be notifications for central staff in case of unusual actions, like a user’s SSPR account has failed X times the same day or other security related alerts.

A popular feature is password expiration notification.