How These Programmes Fail
The same handful of failures recur. Each is visible early and each has a specific correction.
Analysis
PAM deployments fail in recognisable ways. Knowing the patterns is worth more than any implementation guide.
Vaulting without reducing
The symptom: credentials are vaulted, standing accounts are unchanged, exposure is where it was.
Why it happens: vaulting is a project with a completion date; reducing privilege is a negotiation with every team.
The correction: report standing privileged accounts as the headline metric from day one, so the programme is measured on exposure rather than on onboarding.
Recording without review
The symptom: a large storage bill and no findings, ever.
Why it happens: recording is bought to satisfy an audit question, and the question was about recording rather than about review.
The correction: build the alerting and sampling process before expanding coverage, and report findings — including none — so the absence is visible.
The path not enforced
The symptom: brokered sessions are a fraction of actual privileged sessions.
Why it happens: enforcement requires network and host changes owned by other teams.
The correction: measure brokered against target-side authentication logs and treat the difference as the coverage figure.
Scope creep at the start
The symptom: eighteen months in, nothing is in production.
Why it happens: the programme tries to cover every tier, every system class and every capability simultaneously.
The correction: tier zero first, complete, in production, before anything else starts.
No break-glass design
The symptom: the first outage produces an undocumented exception that becomes permanent.
The correction: design and test break-glass before removing standing access, not afterwards.
Administrators routed around it
The symptom: standing accounts still being used after just-in-time is available.
Why it happens: the sanctioned path is slower, or it does not cover a real workflow.
The correction: treat it as design feedback, fix the gap, then enforce. Enforcing first produces concealment rather than compliance.
Service accounts deferred
The symptom: the human side is complete and the larger population is untouched.
Why it happens: dependency mapping is slow, unglamorous and blocks rotation.
The correction: start the mapping in parallel from the beginning, and reduce rights before attempting rotation, which delivers value without the dependency risk.
Cloud left out
The symptom: a mature on-premises deployment and unmanaged standing roles in the cloud tenant, where the actual exposure now sits.
The correction: include cloud entitlements in the inventory from the start, even if the tooling is separate.
No owner
The symptom: the programme was a project, the project ended, and the inventory is now a year out of date.
The correction: a named owner with allocated time, and a monthly reporting cycle that makes decay visible before it is total.
The common thread
Each failure is a case of measuring the deployment rather than the exposure.
Onboarding percentages, credentials vaulted and sessions recorded all move while standing privilege, privilege paths and unbrokered sessions stay where they were. Reporting the second set from the first week is the single most effective preventive measure available.
Diagnosing a stalled programme
Most stalls have one of a small number of causes, and the diagnosis determines the fix.
No owner with authority over infrastructure teams. Re-establish sponsorship.
Measured on activity, so nobody noticed exposure was flat. Change the reporting.
Scope too broad, so nothing reached production. Cut to tier zero and finish it.
Administrators bypassing, so coverage is nominal. Fix the friction before enforcing.
Service accounts deferred, so the larger population is untouched. Start dependency mapping in parallel.
Diagnose before proposing more tooling, since a product purchased to restart a stalled programme usually stalls with it.
The recovery move
For a programme that has deployed a vault and changed nothing else.
Publish the exposure baseline: standing accounts by tier, paths to tier zero, brokered proportion.
Pick tier zero and finish it completely — vault, broker, enforce the path, remove standing rights, break-glass tested.
Report the before and after on those measures.
Run a rotation drill and report the time.
This is a quarter of work and it converts a deployment into a control, which is a far better position than extending the same partial deployment to more systems.