White Papers Password Management Best Practices Password Management Project Roadmap
Hitachi ID Facebook Page Hitachi ID Twitter Page Find us on Google+ Hitachi ID YouTube Page

Password Management Project Roadmap

This document will guide you through the entire life of a successful password management project, including:

  • A needs analysis.
  • Who to involve in the project.
  • How to select the best product.
  • Technical design decisions.
  • How to effectively roll out the system.
  • How to monitor and assure sound ROI.


As today's organizations deploy an ever-growing number of complex systems, password management problems choke help desk systems, cause expensive delays and lost productivity, and threaten to compromise security.

Identifying the cause of these problems, and resolving them, requires the involvement of many interested parties and much strategic planning. Organizations can use a number of software products to address these issues. Selecting the right one also involves taking a number of important factors into consideration.

This document will guide you through the entire life of a successful password management project, including:

Needs analysis


The first step when selecting and deploying a password management product is to conduct a needs analysis. The needs analysis should identify the problems that a password management system must solve. These should be translated into requirements which the successful vendor must meet.

Following are the most common password management problems, and a brief description of password management functionalities that are required to solve them.


Users frequently have too many passwords on too many different systems. As a result, they either forget their passwords or violate security policy in an effort to remember them.

A password management system should allow users to manage every password from a single screen, and allow users to synchronize their passwords to a single, hard-to-guess password.

User productivity

Users who forget their passwords waste time on:

Each problem incident may consume 20-30 minutes of user time. In many organizations, users experience this problem 2-4 times annually. In a large user population, this generates a huge volume of user problems and help desk calls.

A password management system should incorporate password synchronization, which helps users to remember their passwords and thus eliminate the majority of password-related problems. It should also include a password self-reset and help desk password reset facility, to speed up the resolution of remaining password problems at the help desk.

Support cost

Users who forget their passwords call the help desk, and get service. These calls normally represent 20% to 30% of total help desk call volume.

Security violations

In an effort to remember a large number of passwords, users may violate security policies by:

Password synchronization simplifies and automates the password change process while enforcing security procedures. A password policy engine should ensure that synchronized passwords are strong and changed regularly.

OS migration

When new network systems are installed, users must be assigned new passwords. When many users are involved, creating new login IDs, assigning each of them an initial password, and securely communicating that password value to the user is a large undertaking.

This process is required in projects such as new OS deployments (for example, migrating to Windows 2000 Active Directory), new authentication services (for example, RADIUS servers supporting many firewalls), and new application deployments (for example, SAP or PeopleSoft deployments).

Password synchronization should allow administrators to assign existing users of new systems a random initial password. Users can then reset some or all of their passwords to a new, known value to gain access to new systems.



To be successful, a password management project must have a mandate, a schedule and a budget. Persons in an organization with a vested interest in password management must be involved early in the project. This ensures that their requirements are met at the design stage, and that they will not object to any part of the project during deployment.


A password management project must start with a clear mandate to solve specific business problems. (2) outlines the most likely issues that must be resolved.

Projects that start without this mandate may fail when the time comes to request resources and the support of groups within the organization.


It is often helpful to verify, at the onset of a password management project, whether or when sufficient funds will be available. The following items require funding:


Early involvement by all interested parties in an organization ensures that the final design reflects all needs, and that no objections will be raised late in the project.

The following groups are typically involved in a password management project:


It is crucial for a password management project to include the system's long-term owner, as early as possible.

Ideally, the long-term system owner and the system's technical administrator(s) will have a strong influence over product selection. These people will have to work with the system and its vendor, so they are more likely to take the time to make a critical analysis of product documentation, and undertake a technical laboratory evaluation of candidate products.

It is risky, on the other hand, to have one team select a product, and a separate team install and manage it.

Selecting a product


The ideal password management product should meet all of the project's technical requirements, and be supported by a stable, mature and helpful vendor.

The following sections describe the technical and business requirements that a password management system vendor should meet.

Technical requirements


A password management system should include functionality for:

Target systems

A successful password management system should be able to manage passwords on most or all of the systems to which users login with an ID and password.

If this is not possible, then a threshold for systems that must be supported should be defined. A reasonable approach is to require the solution to manage passwords for systems that generate 95% of password-related calls to the help desk.

Target systems should work "out of the box" in as many cases as possible.

Where this is infeasible (e.g., home-grown applications, vertical market applications, legacy applications), the product should be open enough to make it possible to easily integrate with applications:


A password management system should integrate seamlessly with existing I.T. infrastructure, including:


Deployment should be as simple as possible. Features supporting this objective include:


The system should cope with both current and possible future requirements for:


A password management system literally owns the "keys to the kingdom" and consequently must meet the most stringent security requirements:

Vendor profile

As with any vendor, the company supporting a password management system should offer sound support, effective professional services, good relationships with other relevant vendors, and long term stability.

Financial stability

The five vendors with the largest market share in password management products are all small, and with one exception privately held corporations.

In the interests of long term support for the technology, it is important to verify that prospective vendors are financially sound: growing rather than shrinking, and profitable rather than burning cash reserves.

Quality of support

Quality technical support is crucial to project success. This is best measured by implementing the password management system in a test environment, and evaluating the ability of the vendor to assist in the installation process.

Deployment time

Vendors should be able to offer turn-key or assisted deployments. A good vendor will be able to successfully deploy the system in a minimum amount of time. A good product can be deployed without intrusion -- without installing desktop software, and with limited use of server agents.

The deployment effort in a large organization should not take more than 10-20 supplier person/days.

Single source

It is easier and safer to work with a vendor that can provide all the required technology directly. This eliminates the risks of using third party technology, such as:

Future direction

The successful vendor should have a clear direction for future growth and technology advancement. This helps to ensure vendor stability, and a sound future for the product.


Password management products must inter-operate with other I.T. infrastructure supported by current suppliers. Relationships between a password management vendor and the vendors of other infrastructure or services can streamline interoperability and ongoing support.

In particular, it is helpful if the password management vendor has a working relationship with providers of:

Project management


The following sections outline the objectives of each phase in a password management deployment project.

Project startup

To begin the project:

  1. Perform a needs analysis, as described in (2).
  2. Document technical and business requirements, as described in (4).
  3. Establish a project whose mandate is to resolve the problems identified in the needs analysis.
  4. Identify prospective vendors and products.
  5. Allocate and approve people, systems and a budget.

Product selection

To make an effective product selection:

  1. Perform some research to find out what products are currently available. Analyst firms generally know which vendors have significant market share, and can identify prospects.

    Another excellent source of information is the Internet: use a search engine to find sites that mention:

    • "password synchronization,"
    • "self-service password reset,"
    • "help desk password reset", and
    • "password management."

  2. Once you have identified prospective vendors, forward your technical and business requirements document to them, and request a proposal.

  3. Provide the prospective vendors a list of key decision-makers in your organization and their selection criteria. This will help vendors to focus their efforts on what matters most to you.

  4. Evaluate the product in either a laboratory environment or with a pilot group of users and systems. Evaluating products based on paper only is very risky. You may reach final conclusions based on unfounded or inaccurate information.

    Vendor RFP responses are no substitute for lab testing: some vendors will respond to RFPs based on what they believe the customer wants to hear, with no bearing on what their product can actually do, on the theory that "we can either build it later, or convince the customer that they don't need it."

    Analyst reports are also no substitute for lab testing: the analysts do not install products in their own labs, and instead rely on every vendor for an assessment of their own capabilities. Specific vendor claims are not verified.

    Ensure all features defined in the requirements document are tested and compared. This exercise will highlight differences between products and vendors in a way that a paper process cannot.

  5. Compare vendor proposals, technical evaluation results and prices.


Once a product has been selected, negotiate on a price and project deliverables and sign a contract. Fixing the price and deliverables (professional services, milestones, level of support) mitigates project risk.

Include a detailed list of deliverables and a statement of work attached to the contract.

Product deployment

Prepare a detailed deployment plan including: system design, schedule and resource allocation. These should cover the following aspects:

  1. Design:


    • Which features will be activated.

    • How users will access the system.

    • Which security policies (such as authentication process, password policy) will be enforced.

    • Whether the system will integrate with the help desk issue tracking system, and if so how/when it will create open/closed tickets.

    • Whether the system will integrate with e-mail, the events that will trigger e-mail, and the messages to be delivered.

    • Whether the system will integrate with an authentication database, and the database and schema to be used.

    • Whether the system will include meta directory integration, and the direction, directory, and attributes to be used.

    • The number of servers needed.

  2. Installation:

    Determine how you will carry out:

    • Operating system and web server installation.
    • Application software installation.
    • Integration with the help desk system, meta directory, H.R. database, e-mail, authentication systems, etc.
    • Multi-server replication.

  3. Pilot test:

    Determine how you will carry out the pilot test by:

    • Deploying the system to a limited number of users.
    • Verifying the functionality of the system.
    • Ensuring that the (possibly customized, possibly multi-lingual) user interface is easy to understand.
    • Verifying that all interfaces work as expected.

  4. Training:

    Determine how you will:

    • Train help desk analysts to use the tool, and to assist users with using it.

    • Compose training materials for the user population, to be posted on the Intranet and e-mailed directly to users.

  5. User roll-out:

    Determine how you will notify users about the tool, and (if required) activate them.

    Be sure to get supporting documentation and best practices from the vendor.

Post deployment


While the bulk of the work in a password management deployment process ends with user roll-out, more work is required on an on-going basis. This includes:

User adoption

Ongoing support and upgrades

A technical resource must be assigned to ongoing system support. In particular, this person must:

A mature product should allow to minimize the amount of effort required to perform these duties.

Measuring ROI



Password management systems offer a simple way to improve user service, reduce network security vulnerabilities, and lower I.T. support costs.

A typical project can go through concept, needs analysis, technical requirements, product selection, installation, pilot testing and roll-out in six months or less. Positive return on investment is typically achieved within 6 months of general roll-out.