Why SSPR fails and what to do about it
Many self-service password reset solutions (SSPR) have very low user adoption rates, even close to 20 percent. Understanding why this is so is necessary to understand how to improve SSPR solutions and build a great business case for so doing. This blog will help you understand the issues regarding most SSPR implementations and where to look for improvements.
Employees forget passwords or get locked, and this means lost time and productivity for themselves and for the central IT-service desk. The answer is self-service password reset (SSPR) solutions. Many different vendors now offer such solutions, though in some cases these are simply bundled in as part of another solution. SSPR solutions are now available for Microsoft Azure, ServiceNow and other ITSM packages, and many identity management solutions have now integrated SSPR into such packages.
We have noted, however, that many IT managers are concerned that their SSPR solution is not being used as much as expected. One study, conducted by the Service Desk Institute amongst its members, demonstrated that less than 10 percent of organizations with SSPR solutions achieved more than 70 percent usage (measured as percentage of self-service). The large majority attained less than 40 percent success.
A simple decision tree can help us understand the issues facing users of SSPR:
Enrollment: Users must share individual and personal information to be verified by password reset best practices. Even 60 percent enrollment is high for most situations, indicating 40 percent won’t carry out self-service.
Practically speaking, all SSPR solutions cover only Windows passwords, but large organizations have application passwords from SAP, Oracle, IBM, LDAP and so on. In this case, 40 percent of password issues are caused by SAP passwords, and then users call the service desk.
Verification is easily achievable if the user has an accepted token. Often, this means a mobile phone receiving an SMS text. However, it can mean different apps on a smartphone too, or perhaps some sort of physical token. The user may, however, have lost or forgotten the token or may not have enrolled it in the first place.
The last resort comprises answers to private questions, such “What was your first car?” or “What is your favorite pizza topping?”. However, if users can’t remember their answers or spell these answers incorrectly, they then have to call the service desk.
In our scenario above, only 22.5 percent carry out self-service of passwords—the remaining 77.5 percent call the service desk. And this percentage is quite normal!
Additional issues are as follows:
Will the user know what to do? The password reset situation might happen less than once per year, so if the solution isn’t right in front of the user’s nose, then they will probably have forgotten what to do and will then call the service desk.
Many of us work from home. Can the solution reset the local password at our mobile PC? Most solutions can’t, in which case we need to get the PC back into our office domain and ask the IT team for assistance.
If only about 20 percent of all password calls are handled by self-service, then the question is this: Is it really is worthwhile to have and maintain a solution?
A better question, however, is this: Can we get user acceptance above 80 percent?—then it will make sense!
Making SSPR successful!
After working many years with SSPR projects, we know that user adoption can go even beyond 90 percent, but it takes a good internal process and the right functionality in relation to the SSPR product. As a case study, let’s look at the new FastPass V4 SSPR solution, which adds some new, exciting features.
Enrollment: Most users will be obliged to enroll when logging in to Windows—there’s simply no way to avoid it. Users who do not have a domain PC will be email invited. This process runs automatically until the user enrolls—close to 100 percent. But notice that if you haven’t enrolled, then you can’t call the service desk, at which point you end up asking your tour manager or a trusted colleague!
The FastPass V4 portal can reset passwords for any corporate application—the user simply chooses the type of password they wish to reset.
Enterprises may employ many different types of tokens: Smartcard, Microsoft Authenticator, Duo, mobile phones, RSA devices and so on. FastPass V4 supports all of these and many more, and the user can freely select the one they have in their pocket that day!
Based on years of experience, we have recommendations for customers to help improve users’ chance of answering the questions and still keeping them secure. One of the elements is users’ own questions, where they can generate one to two personal questions.
A new element in FastPass V4 is “Manager Approval” or approval by a trusted colleague. If any of these are available and can verify that the user really is asking for a new password, they can approve—even when everything else has failed, and even if the user has not been enrolled!
In the illustration above, only 7.1 percent of all calls turn to the service desk and 92.9 percent are calls regarding self-service. When the service desk has verified that it’s the true user, then that user user is asked to reset the password him/herself in FastPass, to make sure that they are enrolled correctly and can create a new password according to the company password policy.
Even users on remote PCs will get the local PC password reset automatically as part of the self-service process.
A key issue for corporate security is how to defend ourselves against social engineering against the service desk. Hackers might call the service desk and impersonate a real user to get the password. Good hackers are experienced in social engineering techniques and are often able to con the service desk into helping.