What Privileged Access Management Is

Privileged access management is usually bought as a single thing and turns out to be three, with different owners and different failure modes.

The three problems

Where credentials live. Administrative passwords, SSH keys, API tokens and service account secrets, currently distributed across spreadsheets, config files, password managers and people's memories.

How access is granted. Who gets administrative rights, for how long, with what approval, and whether that grant is permanent.

What happened during the session. A record of what an administrator actually did, sufficient to answer a question weeks later.

They share an inventory and almost nothing else. A product that vaults credentials does not by itself reduce standing privilege, and neither one tells you what was typed.

Why it exists as a category

Administrative accounts are the target. An attacker who obtains one does not need to find further vulnerabilities.

They are shared, historically, which destroys attribution.

They are permanent, so a credential compromised today remains useful indefinitely.

They are numerous and mostly unknown. Every organisation that inventories properly finds far more than expected.

They are unmonitored. Ordinary user activity is logged in a dozen systems; what an administrator does on a server frequently is not.

The core idea

Privilege should be temporary, brokered and observed.

Temporary: granted for a task and revoked afterwards, rather than held permanently.

Brokered: obtained through a system that authenticates, authorises and records, rather than by holding a credential.

Observed: the session produces a record independent of the person using it.

Every product in the category is an implementation of some part of that.

What it is not

Not a password manager. Consumer and team password managers store secrets and do not broker sessions, rotate at scale or record activity.

Not identity management. Identity systems handle who exists and what they can access ordinarily. PAM handles the elevated case.

Not a substitute for reducing privilege. Vaulting a credential that a hundred people can check out has improved attribution and little else.

Not a compliance checkbox, although it is frequently bought as one, which shapes the deployments badly.

What the programme actually involves

Discovery, which is harder than it sounds and has its own section.

An inventory of privileged accounts with owners.

Vaulting and rotation.

Session brokering through a controlled path.

Recording, retention and a review process that someone actually performs.

Reducing standing privilege, which is the part with the largest effect and the most resistance.

A break-glass path for when the system itself is unavailable.

Software helps with all of it and creates none of it, which is the same thing this material says about every tooling question.

Where deployments go wrong

Vaulting without reducing standing access, so the old paths remain.

Recording without review, producing storage costs and no capability.

Deploying to the easy systems and leaving the ones that matter.

Administrators routing around it, which they will if the controlled path is slower than the uncontrolled one.

No break-glass design, so the first outage produces an exception that becomes permanent.

The first week

Five things that establish where an organisation stands, before any purchase.

Resolve administrative group membership transitively. Ten minutes, and the number is usually several times the estimate.

Count local administrator rights across workstations from endpoint management.

List cloud role assignments with administrative scope.

Pull the age of every privileged credential you can see. This column is the most alarming and the easiest to produce.

Ask one question of each system owner: who can administer this, and how would you know if someone else did.

None of this requires a product, and it produces the argument for everything after.

Who owns it

The programme stalls where ownership is ambiguous, and the three plausible owners each distort it.

Security treats it as a control to be deployed and under-weights the operational cost to administrators.

Infrastructure treats it as a tool and under-weights the exposure reduction, which is what it is for.

Identity treats it as an extension of access management and frequently misses the machine credential population entirely.

The workable arrangement is one owner with authority over infrastructure teams, a steering group that includes the administrators being constrained, and reporting into whoever decides infrastructure priorities.

What fails is a shared responsibility with no named person, which is how most first attempts are structured.