Why PAM Projects Fail: 10 Failure Modes and How to Avoid Them

The PAM Academy · Module 10

Who this module is for

The problems this module solves

What you will learn

1. Ten common failure modesUnderstand the biggest reasons PAM projects stall, fail or restart, described concretely enough to recognise in your own delivery.
2. The lesson behind each failureSee which discipline prevents each failure and the key takeaway that turns it into a rule you can apply.
3. Apply the lessons in reverseReframe what you already know as a risk radar, so you can spot a failure pattern forming and choose the safer path early.
4. Stronger decisions under pressureUse proven practices for scoping, selection, sequencing and go-live to avoid wasted time, wasted budget and lost trust.
5. Build for long-term successCreate a resilient, value-driven PAM programme that keeps improving instead of freezing at the moment the project closes.

Why do PAM projects fail so often?

PAM failure is rarely a single dramatic event. It is usually a slow divergence between what an organisation bought and what it actually operates. The investment case is signed on real numbers, an average credential breach cost of 4.88 million dollars and 292 days to detect one, and then the programme is run as a procurement exercise rather than a change to how access works.

Three patterns account for most of the wreckage:

• Partial coverage that never closes. The platform is live, but the percentage of privileged accounts genuinely under management stops climbing. Years after purchase the estate is protected in patches.
• Shelfware. Licences are bought, the deployment stalls, and the renewal is approved each year because cancelling would require admitting the failure. The control exists on paper and in the budget, not in the path of privileged work.
• Restarts. The project is stopped and relaunched with new consultants, a new platform or a new sponsor. Project two carries project one’s scars, and the people it needs most have already decided how this ends.

The underlying cause is almost always the same: the organisation treated PAM as a purchase rather than a discipline. A tool dropped into an environment with no strategy, no operating model and no process does not fix chaos, it automates it. If access was granted by favour before the vault, it is granted by favour after the vault, through a nicer interface.

So the useful question is not whether your platform is good. It is whether you can name the owner of access decisions, the discovery you have done, the risk ranking you are working through, the measures you report and the people who are watching. If several answers are missing, the failure has already started.

The 10 reasons PAM projects fail, and the lesson that prevents each

Each failure below is the mirror image of a discipline taught elsewhere in this course. Read them as a diagnostic list.

1. Blame the person, keep the system

An incident is treated as an individual’s mistake. Someone is disciplined, a memo about personal accountability circulates, and the system that created the forgotten account, no ownership, no reviews, no lifecycle, keeps running untouched. Eighteen months later a different person’s account does the same thing. Module 1’s lesson prevents this: until you treat the breach as a process problem, you repeat it with better documented scapegoats.

2. A tool without a programme

The board demands action, so IT buys a vault. No strategy, no operating model, no named owner for access decisions, no success measure beyond deploying the tool and no executive sponsor. Module 2’s sequence is the fix: strategy, then operating model, then processes, then controls, and the tool fifth.

3. Securing only the accounts you already know about

Scope comes from a list somebody kept rather than from discovery across directories, IAM, logs, access control lists and interviews. One manufacturer scoped ninety privileged accounts; a comparable estate that ran full discovery found 312 accounts nobody had on any list, plus 47 orphaned and 89 over-privileged. Module 3’s rule: you cannot protect what you cannot see, so collect once and audit forever.

4. Boiling the ocean

Everything, everywhere, at once. No risk ranking and no sequence, so test lab servers are argued over with the same energy as payment systems. Twelve months in, everything is fifteen per cent protected, nothing is finished, and the board sees burn rate without wins and stops the money. Module 4’s rule is that protection follows risk, and visible quarterly wins are how a programme keeps earning its budget.

5. Buying the demo, not the fit

A strong demonstration, a discount expiring at quarter end, and a signature in the same month. No requirements written first, no proof of concept on your own systems, and no integration costing, which is where the largest hidden cost arrives. Every connector becomes a custom project and every upgrade breaks two of them. Module 5’s rule: requirements first, vendors second, and price every integration.

6. Deployment as an event, not a methodology

Big bang go-live across every site and user, announced by email days before. Supervisors locked out of production systems, a four hour help desk queue by nine in the morning, and by midweek blanket exemptions for whole departments. The tool stays installed and nobody privileged uses it. Module 6 prevents it: pilot, phase, communicate ahead of the change and rehearse the rollback.

7. Deploy and walk away

Sessions recorded to storage nobody opens, alerts firing into an unstaffed mailbox until a rule archives them, and an operational handover line that was never resourced. One organisation had an attacker inside for seven months with the evidence sitting in its own recordings. Module 7’s rule: collected is not monitored and monitored is not understood, so fund the watch.

8. A programme frozen in time

The design assumes the estate of five years ago while the business moves to multiple clouds, container pipelines, machine identities and AI agents with delegated access that nobody security reviewed. The fastest growing part of the identity estate becomes the least protected. Module 8’s habit is horizon scanning: principles hold, tempo changes.

9. Never measured, never mirrored

No maturity model, no independent review, no honest mirror. Status stays green until the day it is red, because nobody was ever asked a hard question with evidence required. Module 9 supplies the structured assessment that lets a programme catch itself before an attacker does.

10. The forgotten doors

Humans get vaulted while machines, outsiders and emergencies stay in shadow: a machine identity with a five year old password set by a developer who has left, a vendor login from a project that ended years ago, and self made break-glass credentials in a desk drawer. This failure draws on the whole series and is the theme of Module 10. A PAM programme covers humans, machines, outsiders and emergencies, or it is a partial map with an attacker standing in the blank space.

What is PAM shelfware, and how do you spot it early?

Shelfware is a licence that is paid for and renewed while the control it represents is not in the path of real privileged work. A slow deployment is still moving. Shelfware has stopped, and the organisation has stopped noticing.

The early signals are operational rather than financial:

• Coverage has flatlined. The percentage of discovered privileged accounts under management has not moved in two or three reporting cycles, and nobody is asking why.
• Exemptions outnumber onboardings. Departments hold blanket exclusions granted during a difficult go-live, and no one owns the plan to bring them back in.
• Alerts go to an unstaffed destination. Thousands of notifications a week, untuned, with a mailbox rule quietly filing them away. Session recordings accumulate and are never opened.
• Discovery has never been repeated. The account inventory is a point in time list, so new services, new clouds and new vendors never enter scope.
• Reporting describes activity, not outcomes. Slides count workshops held and accounts touched rather than risk reduced or standing privilege removed.
• Renewal is decided by finance, not by security. If the annual conversation is about cost rather than value delivered, nobody is defending the outcome.

The test that cuts through all of it is simple. Pick your three most critical systems and ask how an administrator obtained privileged access to each of them last week. If the honest answer involves a standing account, a shared password or a documented exception, the platform is not protecting those systems regardless of what the deployment dashboard says.

Shelfware is recoverable, but not by buying more licences. Re-run discovery, choose one high value estate, remove the exemptions there with the affected teams involved, and report the result. Coverage that moves on something that matters restores more credibility than a full re-plan.

How do you rescue a stalled or restarted PAM project?

A restart is harder than a first attempt, and the difficulty is not technical. Operations remembers the lockout, finance remembers the write off, and the teams whose cooperation you need have already formed a view. Scepticism is the inherited liability, and the recovery plan has to pay it down first.

A workable sequence for the first ninety days:

1. Run the post-mortem honestly. Name which of the ten failure modes applied. Most stalled programmes carry three or four. Write them down and share them, because a recovery that pretends the first attempt was fine convinces nobody.
2. Re-establish ownership. Confirm who owns access decisions, who owns the platform and who owns the operational watch. If those three answers are missing, fix them before touching scope.
3. Re-run discovery properly. Treat the old inventory as a hypothesis. Discover across directories, IAM, logs, appliances, cloud platforms and interviews, capturing owner, lifecycle linkage, access patterns and credential reality in one pass.
4. Rank by risk and pick one estate. Choose a crown jewel system where success is visible and the stakeholders are willing. Finish it completely rather than starting everywhere.
5. Land it as a methodology. Pilot with a group that is friendly but not tame, phase the rollout, communicate ahead of every change and rehearse the rollback so the only available fallback is not abandoning the control.
6. Fund the watch on day one. Name who reviews alerts and sessions, at what frequency, with what escalation. An unmonitored control is a future finding.
7. Publish a baseline and report against it. A maturity assessment before you start gives you something to improve from and protects you from the green status trap.

Two rules hold the recovery together. Do not relaunch the scope that failed, because repetition confirms the sceptics. And deliver a completed, provable win inside two quarters, because credibility is rebuilt with evidence rather than plans.

How do you build a PAM programme that survives?

The organisations that finish do not have more budget or better luck than those that stall. They treat each step as a discipline instead of treating the whole thing as a purchase. A durable programme rests on a handful of ordering rules, applied consistently.

• Fix the blame culture first, or every other problem gets hidden from you. People who expect to be punished for reporting a gap will stop reporting gaps.
• Strategy before tooling. Know what you are trying to achieve, who owns access and how decisions get made before a platform enters the conversation.
• Discovery before protection, and collect once so you can audit forever.
• Risk before sequence. Everything equally protected means nothing properly protected.
• Requirements before vendors, with every integration priced against your own IAM, ticketing and operational technology estate.
• Landing before celebration. A control that operations cannot live with will be exempted, and exemptions rarely get reversed.
• Watching before trusting. The distance between a 292 day average detection time and anomaly detection in under an hour is not technology, it is whether somebody is actually watching.
• Horizon before comfort. Machine identities, cloud platforms and delegated AI access grow faster than the programme that ignores them.
• Measurement before confidence. An unmeasured programme does not know it is failing, which is not the same as succeeding.

Then there is coverage. A programme accounts for every door: human administrators, machine and service identities, vendor access, and emergency break-glass credentials that are designed and drilled rather than laminated and left in a drawer. Quarterly rehearsals, some unannounced, turn an assumption into a capability.

Finally, run it as a programme rather than a project. Projects have end dates and the estate does not. Keep discovery recurring, the risk ranking current, evidence in front of people with authority to act, and maturity reassessed on a schedule. Not a tool, not a project, a programme.

Common mistakes to avoid