swipe to navigate


Password synchronization

A password management system, such as Password Manager, requires a profile of login IDs for every user, on every system. This must be constructed at the outset of the deployment project, and maintained over the life of the system.

Where login IDs are consistent across systems, constructing and maintaining these profiles is easy. If login IDs belonging to the same user are different on some systems, some work is required, either centrally or by each user, to connect different IDs back to their individual owners.

In general, no client software deployment is required.

In general, little or no target-system software deployment is required.

In general, little or no ongoing system maintenance is required.

Password synchronization systems can be quite fast to deploy. For example, Password Manager has been deployed in organizations with as many as 90,000 users, to synchronize passwords over a dozen systems, in just 5 days. Password Manager has been deployed to organizations with as many as 300,000 internal users and as many as 5,000,000 consumer-users.

Self-service password reset

In addition to the login ID profiles described above, a self-service password reset system, such as Password Manager, also requires secondary credentials for each user. The most common credentials to use when users forgot or locked out their passwords are mobile phone numbers and security questions. The self-service system sends a random PIN to the user's phone, which the user must type, after which the user is asked to answer a series of security questions.

In a typical deployment, this method means that enrollment of mobile phone numbers (or personal e-mail addresses) and security questions is required, as this data is rarely available prior to deployment.

Additionally, most password reset systems include the installation of client software on each PC, to enable users to reset or unlock their primary OS login password, from the PC login screen. For example, on Windows Vista and later, this is an extension to the Credential Provider OS subsystem. Such client software is relatively simple to deploy.

Other popular options with password reset systems are to:

  1. Integrate the client software with the corporate VPN, so that off-site users who forgot their primary password can resolve their login problem;
  2. Integrate with full disk encryption software, so that users can unlock their filesystem in the event that they forgot their pre-boot password;
  3. Offer access to self-service using a mobile phone; which requires installing an app on each phone and setting up a proxy server in the cloud or DMZ;
  4. Integration with a ticketing system, to track SSPR activity;
  5. Integration with e-mail, to invite and remind users to enroll.

In general, little or no target-system software deployment is required.

In general, little or no ongoing system maintenance is required.

Simple password reset systems can be rolled out in 1--2 weeks. More complex ones, with many and varied integrations, can take 2--3 months to roll-out.

Enterprise single sign-on

An enterprise single sign-on (E-SSO) system requires not only login ID profiles for each user, but also current passwords for each user, on each application. The enrollment process is consequently more invasive, as users are prompted by the E-SSO software asking whether each password they type should be remembered.

E-SSO systems require client software, by definition. This client software can be quite invasive so careful compatibility testing is required with each application and whenever client operating system configuration changes or patches are pushed out.

E-SSO systems require a wallet of credentials for each user. This is often done using a directory schema extension, which typically requires extensive change management.

As mentioned earlier, if a user forgets their primary password, all their application passwords will be lost. To avoid this, a password recovery system is needed, which adds complexity and security risk to the system.

Since E-SSO systems are generally Windows-specific, non-Windows users need some way to sign into their applications. E-SSO systems therefore necessitate a way for non-Windows users to remote into a Windows desktop, typically on a farm of Citrix or Windows Remote Desktop Services servers. A sufficiently large farm of such servers can be very expensive, both in terms of hardware and software licenses.

The consequence of all of the above is that E-SSO systems are often as much as 10x more costly than credential management systems.


Comment via LinkedIn