Skip to content
Standing Access

Contents  ·  Foundations

The Product Categories

Vaulting, elevation, secrets management and session brokering are separate capabilities sold in overlapping bundles. Which one solves which problem.

Reference

Vendors bundle differently and the underlying capabilities are stable. Knowing them makes evaluation possible.

Credential vaulting and session management

What it does: stores privileged credentials, rotates them, and brokers sessions so the user never sees the password.

Solves: shared credentials, password sprawl, no attribution, no rotation.

Does not solve: standing rights that exist outside the vault, or anything on systems not onboarded.

The classic core of the category and what most people mean by PAM.

Privilege elevation and delegation

What it does: allows a normal account to perform specific administrative actions, on request or by policy, without holding administrative rights.

Solves: standing local administrator, over-broad sudo, the need for a second privileged account.

Does not solve: credential storage, or activity recording unless it includes it.

Where the reduction in standing privilege actually comes from.

Secrets management

What it does: stores and issues credentials for machines — applications, pipelines, containers — usually with short-lived dynamic secrets.

Solves: hardcoded credentials in code and configuration, static service account passwords.

Does not solve: human privileged access.

A separate problem with a separate tool in most organisations, and the one growing fastest.

Session recording and monitoring

What it does: records what happens during a privileged session, as video, as text, or as structured commands.

Solves: the absence of any record of administrative action.

Does not solve: anything preventive, unless coupled with real-time controls.

Frequently bundled with vaulting and occasionally sold separately.

Cloud entitlement management

What it does: discovers and reduces permissions in cloud platforms, where the permission model is enormous and mostly unused.

Solves: cloud role sprawl, which is where standing privilege now concentrates.

Does not solve: on-premises anything.

The newest category and the one most often missing from programmes designed around traditional infrastructure.

Which to start with

If credentials are shared and static: vaulting.

If everyone has permanent administrative rights: elevation.

If secrets are in source control: secrets management, urgently.

If your estate is mostly cloud: entitlement management before traditional vaulting.

If audit is the driver: recording, and read the note on why recording without review produces little.

Most organisations need several, and buying all of them at once produces a two-year programme that delivers nothing for eighteen months.

Evaluating the bundle

Ask which capability each component actually implements from the list above, rather than accepting the product's own framing.

Ask what happens to systems it cannot onboard, because there will be some and they are frequently the oldest and most privileged.

Ask about availability, because a broker that is down means administrators cannot work, which is the objection that sinks deployments.

Ask what the exit looks like: how credentials are recovered if you stop paying, which is a real question for a system holding every administrative password you have.

Reading a vendor's coverage claim

Products describe coverage in terms that flatter the count. Three questions clarify it.

Which systems can be brokered with credential injection, as opposed to merely having credentials stored?

Which can be rotated automatically, as opposed to requiring a manual step?

Which can be recorded, and at what fidelity?

The three answers differ, frequently substantially, and a single connector count conceals it.

Ask for the answers against your actual system list, including the awkward appliances, rather than against the vendor's supported platform matrix.

The awkward systems determine your real coverage, because the easy ones would have been manageable anyway.

Sequencing several purchases

Most organisations need more than one capability and buying them together produces a long project with late delivery.

Buy for the problem you can name today, not for the roadmap.

Deploy it fully at tier zero before adding a second capability.

Check whether the first vendor's adjacent module is adequate before procuring separately, since integration between products is where the effort goes.

Keep the inventory and the ownership model outside any product, so a change of vendor does not lose the laboriously assembled part.

Expect the secrets management piece to be a separate purchase in most cases, with a separate owner, because its consumers are engineering teams rather than administrators.