Why Privileged Identity Management Implementations Fail

Why Privileged Identity Management Implementations Fail

As veterans of the privileged identity management (PIM) field, my colleagues and I hear some unsettling stories from organizations whose privileged identity management deployments did not provide the expected business value. We’ve also heard from organizations whose purchases led to years of expensive service engagements. And that’s without every delivering the agreed scope of work.

At the heart of this problem is that many organizations seem to grasp too late that implementing a privileged identity management solution is too important a process to delegate to a rubber-stamp RFP or a battle of vendor check boxes.

If handled correctly your PIM implementation can enable you to close critical security loopholes; help make staff members accountable for actions that impact IT service and data security; and lower the cost of regulatory compliance.

Yet the wrong choices too often turn into expensive shelf-ware – or worse.

The Simple Truth About Privileged Identity Management

The truth is that privileged identity management (or privileged account management) software is not a commodity. Do not purchase it based on checkboxes and up-front fees alone. Vendor claims to the contrary, not all solutions perform equally well under vastly different deployment conditions that can include:

  • wide varieties of managed computers – Windows, Linux, UNIX, and mainframes. Also network appliances, backup infrastructure, and other hardware;
  • large numbers of frequently changing target systems separated by slow, unreliable, or expensive WAN links;
  • significant numbers of custom-designed and legacy applications. These might be poorly documented and their designs may pose significant vulnerabilities if not properly remediated;
  • complex organizational structures demanding solutions with the flexibility to handle overlapping and frequently-changing lines of delegation and control.

Where Your Focus Should Be

If any of these scenarios sound like your organization, you should disregard all vendors’ claims and instead focus on:

  • trial deployments that encompass, at the very least, a test environment with a realistic sampling of your target systems, applications, and user roles;
  • engaging in in-depth conversations with reference customers whose deployments realistically match the diversity and scale of your own organization;
  • getting the facts from those reference customers about true timeframes and back-end costs of vendor deployments so that you can budget your project accordingly.

As you proceed with your evaluation be aware that vendor checkboxes often lie. Craftily written marketing pieces can suggest that a product’s capabilities with respect to one target platform, application or deployment scenario extend to all areas where the vendor claims coverage. And salespeople often believe their organization’s own marketing hype.

Ask very explicit questions – both of vendor engineers and reference customers. Ask them how individual target platforms, managed applications and use case scenarios are configured and deployed. In each case was the vendor’s capability delivered out-of-the box, only through custom development, or never at all?

How the PIM Selection Process Should Work

Your choice of a PIM solution should start with an honest discussion among all process stakeholders. That includes the CSO, CIO, IT administrators, and anyone else involved in the management of sensitive accounts.  Your key stakeholders should be those that will suffer the most damage should the solution take too long to implement, unnecessarily add to IT staff workloads, or provide insufficient coverage. Define your project goals. Then decide who on the team is best suited to determine whether each proposed solution is really a fit.

Be aware that privileged identity management requires not only the introduction of technology. It also requires some fundamental changes in how sensitive credentials are disclosed, changed and attributed to those who use them.  Regardless of whether a solution can lower staff workloads, individuals who once enjoyed unlimited, anonymous access will probably resist being held accountable. For this reason the project is likely to succeed only with the active sponsorship of top management.

What A PIM Vendor Should Provide

You’d never choose a doctor based solely on cost. Nor would you trust a physician who writes a prescription before taking the time to diagnose your condition. Check your medical history, and perhaps run some tests. The same holds true for choosing a PIM vendor. Expect your vendor to provide:

  • a detailed, written analysis of your organization’s business goals;
  • explicit documentation of your needs with respect to systems, applications, and lines of control;
  • a trial evaluation of the proposed solution in a realistic test environment;
  • a clear statement of work that details the time and cost required to bring unsecured privileged accounts in your target systems and applications under control.

The investment to license virtually any of today’s privileged identity management software is small compared to the cost of failed audits and leaving the organization vulnerable to external and internal attacks. Above all, it’s the cost of a failed, protracted implementation that should be your motivation to perform every bit of due diligence you can. Before making your purchase decision.

If you like this topic, please follow us on Twitter and Facebook. You can also subscribe to our company newsletter for a monthly highlight of these posts.

1 Comment on "Why Privileged Identity Management Implementations Fail"

  1. Shirief Nosseir | July 27, 2010 at 5:48 pm | Reply

    Good piece. Few quick additions that come to mind:
    • Assuming that compliance is particularly high on your agenda, ensure that you clearly understand your compliance requirements in details before defining your solution requirements. As you know, compliance is a complex and shifting realm (and cannot be viewed as just one single “checkbox”). For example, identify the specific compliance controls that will need to be supported by the solution, and what type of support are you looking for (e.g., out-of-the-box reporting, enforcement of segregation of duties, password policies…etc). Also, is the solution flexible enough to extend and support additional compliance requirements as new ones get introduced?
    • Give more preference to solutions that capitalize on your existing investments and easily extend/integrate with your critical infrastructure (e.g., Active Directory, LDAP, you user provisioning tool…etc). This can be verified during the trial evaluation
    • Find out from the vendors what recommendations and best practice processes they offer on how to implement, maintain, and manage privileged identities

    Shirief Nosseir
    CA Technologies

Leave a comment

Your email address will not be published.


Time limit is exhausted. Please reload CAPTCHA.