Skip to content
Standing Access

Contents  ·  Operations

Onboarding Systems to the Programme

The order determines whether the programme delivers early or stalls. What to onboard first, and what to do about the systems that cannot be.

Procedure

Every PAM deployment onboards some systems and not others. Which ones, in what order, decides whether the programme produces value in months or in years.

The order

Tier zero first. Directory, certificate authorities, cloud tenant administration, the vault's own dependencies. Smallest population, largest consequence.

Then the systems with the most administrators, where attribution is worst and the improvement is largest.

Then the systems holding regulated data, which is where the compliance driver sits.

Then by ease, which is a legitimate criterion once the first three are done.

Not by ease first, which is the default and which produces a deployment covering the systems that mattered least.

What onboarding involves

Discovery of the accounts on that system.

Deciding which are vaulted, which are removed, and which become just-in-time.

Configuring rotation, including dependency mapping for service accounts.

Establishing the brokered path and testing it.

Enforcing the path at the network and host level, which is the step most often skipped.

Configuring recording at the fidelity the tier justifies.

Documenting the break-glass route.

Telling the administrators and training them on the new path.

Per-system decisions

Can sessions be brokered, or only credentials vaulted?

Can the credential be rotated automatically, and what depends on it?

Does it support individual accounts, or is a shared account unavoidable?

Can the path be enforced technically?

What is the break-glass route when the broker is unavailable?

Record the answers, because the pattern repeats across similar systems and the second one is much faster.

The systems that cannot be onboarded

There will be some, and they need handling rather than ignoring.

Appliances with fixed accounts.

Legacy applications with no API.

Systems where the vendor prohibits it.

Systems too fragile to touch.

For each: record it, state why, apply what compensating controls exist — network restriction, target-side logging shipped centrally, physical access control, a documented review — and put it on a list that someone reviews annually.

This list is the residual risk, and a programme that does not maintain it is claiming more coverage than it has.

Measuring coverage honestly

Systems onboarded against systems in the inventory, by tier.

Privileged accounts vaulted against privileged accounts discovered.

Sessions brokered against sessions occurring, which requires target-side logs and is the number most often not measured.

Report all three. A programme reporting only the first is reporting on its own activity rather than on the estate.

Keeping up with new systems

Onboarding as part of the build process, not as a later project.

A gate before production: privileged accounts registered, credentials vaulted, path enforced, recording configured.

Automated where the platform allows.

Without this, the programme falls behind permanently, because new systems arrive faster than a retrofitting project can absorb them.

The pattern library

The second system of a class should take a fraction of the time the first did.

Record per class: discovery method, which accounts are vaulted and which removed, rotation approach, dependency risks, brokering configuration, path enforcement method, recording fidelity, break-glass route.

Include what went wrong the first time.

Include the time it took.

Hand it to whoever onboards the next one.

Review after every few systems, because the pattern improves with repetition and an out-of-date pattern is worse than none.

The build-time gate

Without it, the programme falls permanently behind the estate.

A check before production: privileged accounts registered, credentials vaulted, path enforced, recording configured, break-glass documented.

Automated where the platform allows, as part of the deployment pipeline.

Owned by whoever approves production readiness, not by the PAM team, or it becomes advisory.

With an exception route that records the reason and a remediation date.

Track exceptions, because a growing list means the gate is decorative.