welcome to the password reset implementation insights today we're going to cover how do i get started with password reset so let's have a look at it so firstly how useful is password reset well password reset is a high volume request on many service desks today it's a source of frustration for end users and often absorbs a disproportionate amount of time for the service desk agents in these modern times it can also be a security gap invert is the user who's requesting a password reset the legitimate user service now provides a modern approach to password reset either through self-service or agent how do i get started with password reset and what are the key implementation considerations first you need to load the application into your instance there are integration hub spokes for ad azure google on octa from san diego the platform security team has introduced the key management framework that enhances the security of basic crypto operations on the platform as part of these changes password reset application needs to update the older glide encrypter functions to use these new encrypt decrypt methods for retrieval of sensitive data in addition from san diego there's an enhanced virtual agent change password support leveraging the va custom component to render change password inputs and integrate into third party systems next we need to determine how and who can raise a password reset is it all employees i.t staff only i.t staff with exception of sensitive groups like security or executives these decisions need to be made as part of the configuration and then the how is there are various methods self-service portal slack teams virtual agent windows login screen service now login screen and also mobile applications again these have to be decided on next is really down to how the enterprise is configured so where are the user accounts and where are those passwords stored are they locally on the servicenow instance of a part of ad or assure ad of a google directory octa or other areas this is really important to understand what the architecture of the enterprise is and how password reset will integrate into there how will users identity be verified and how many options should be available servicenow supports a configurable set of questions providing a bank of questions that the user can then fill in their preferred answers and at the time of password reset would be presented with a subset of those questions other technologies such as sms google authenticator and email can also be used it comes down to a choice of which ones and how many in addition should privileged groups such as xx or people working in sensitive areas have additional forms of verification applied as well password expiring notifications can be sent to users when the password is close to expiring the time period and frequency of these notifications can be configured as well as for contents within those notifications notifications should be sent on traditional channels like email as well as newer channels like the mobile app from san diego the password expiration data is consumed from a credential store windservice now the password complexity can be configured along with the use of things like google recapture to ensure that it's valid if you're using the out of box questions then this should be reviewed and amended as required by default the number of questions a user can answer during enrollment are five and the number of questions that a user will be challenged on a password reset is defaulted to three whereas a minimum length that is definable for each answer you can also define when users should be reminded to enroll such as through emails with weekly monthly and what date and time that should be sent will users access password reset by invoking the change password topic in birch agent any user trying to change their password from virtua agent by invoking change password topic will see a custom change password component that renders within purge agent this component will validate and make sure to collect older new passwords from the users at once by doing so ensures this is more secure as the passwords are not stored in securely even for runtime how many failed attempts are allowed before lockout the maximum number of attempts a user can attempt to password reset before they locked out is defaulted to three for this can be changed if they are unsuccessful they're locked out for a period of time the default being 1404 minutes and if they have been successful in resetting their password they can be blocked from resetting the password again for a period of time again in this case the default is 1440 minutes let's have a look at this from the user experience both self-service and agent assisted self-service it's pretty straightforward user is directed to enter information about themselves and then verify that information either by say the q a email or other options such as voice and facial are available if those services are something that the customer has subscribed to service desk again the service desk will expect the user to answer correctly the challenge questions and then the agent will be presented with a new password for the user requesting it and they've got a phonetic guide to support the agent to help them through change and password on behalf of the user so i hope this has given you some valuable insights into implementation considerations for servicenow password reset