The Top Criteria for Self Service Password Reset (SSPR) Solutions: What should you be looking for?
When considering what criteria to use for your SSPR solution start with the business case – decide why you are looking for a self-service password reset tool.
There are 3 over-arching objectives for the majority of SSPR projects:
User productivity and convenience
Productivity for the IT Service desk
IT security
What are the 10 best SSPR solutions for you to consider for your SSPR project?
In this section, discover how your business goals affect your SSPR requirements.
The criteria falls into 3 categories (find a detailed explanation below):
The most important
The important
Good to have
The cost for the SSPR solution, and for the implementation and operation, is a key factor too.
The positive impact of the business case can be seen as the most important benefit to an effective SSPR solution. When deciding on what SSPR to use, think carefully to include the positive changes that will be incurred. It is also key to remember that different solutions produce different benefits! For more information on cost of SSPR solutions, contact the producers of the software solution or their implementation partners directly to get an exact and up to date cost for your situation.
If you provide IT services for other organizations, or you are a managed service provider (MSP), then you will have unique requirements in addition to those of a typical organization. Read on in the section below to find out more.
The most important criteria for SSPR solutions
Flexibility and 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 prior to purchasing 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. Do not expect that one set of rules and processes will satisfy your situation.
If this flexibility is not present, you will not be able to get user acceptance, or you might not even be able to offer the solution to a substantial number of users. Be aware that this might 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 is far more time consuming than for Windows passwords. So, if the SSPR solution does not support your SAP passwords, you will continue to waste time resetting SAP passwords and you will not meet your productivity business case. If you have an SSO solution you only have one password for the user. If you do not have SSO you help users with password synchronization which is a much simpler and cheaper solution to implement and run than SSO. Regarding the synchronization aspect within an SSO means however, that if a criminal gets the user’s password all systems are exposed! For this reason, some companies maintain that different passwords are needed. Then you incur the need for a portal where the user can select which password to reset.
You do not need to have self-service for all passwords. If you have 10 users with passwords to your bank, then do not try to implement your self-service solution here!
If you however have end-point encryption such 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 help the user in this situation!
Authentication / verification methods
When a user can manage their passwords via a self-service process we must have a verification process which guarantees that criminals cannot 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 broken? 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 a smart phone is not available cannot then alternatives must be in place. 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 okay for SSPR too.
Some organizations have employees of such high security sensitivity that password self-service is not accepted. Even for manual password resets, extremely strict procedures have been set up. 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 not suitable if it does not 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.
Multi-tenancy
If you need to run multiple individual accounts, you need a multi-tenant solution. A good 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 must ask the vendors to confirm the support of your infrastructure, and perhaps request a POC in your environment. This criterion is not represented in our charts.
Important Criteria for many businesses
The criteria in this section might have an important impact on your implementation, but you might live without them if justified by other criteria!
Work-From-Home
An issue for many users now, is that their service desk cannot 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 cannot remember what to do, and she/he will call the service desk! Unless of course the help is just in front of them. 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.
Languages
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 does not 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 is not possible
If enrolment has not been successful, it will directly affect the business case negatively!
Service desk process
With an SSPR solution you do not expect to have password calls to the service desk. Our experience is, however, that even the best implementations still have users who can't do the verification or for other reasons cannot self-serve. 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 the process and benefits? 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, impersonate the user, and convince the supporter to help. Social engineers can be very persuasive!!
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, 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.
Good-to-have features
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 make a simple password change (CTRL-Alt-Del / Password change in Windows). We call this Password Filter.
User Interface
To what degree can you change 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 change text, logos and design can be important in user adoption.
Reporting
We meet different customer strategies for reporting on Key Performance Indicators such as 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.
Notifications
It is important to get notifications when significant system 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.
Protect your Passwords today with FastPass
Get in touch with us today by filling up the form and our team will get back to you as soon as possible.