PAM6 min read

Who closes the account in the vault?

A vault solves how passwords are stored. It says nothing about who may hold a privileged account, or who removes it again. Here is what that costs, and how the link to IGA closes the gap.

Article: lifecycle management for privileged accounts

Background

The vault solves storage, not ownership

A PAM solution is usually bought to get control of the privileged accounts. Passwords are stored securely, rotated automatically, and handed out through a controlled session. Compared with a spreadsheet or a shared password box, that is a large step forward.

A vault answers how a password is stored. It does not answer who may hold a privileged account, why it was created, or who closes it when the person changes role or leaves. In most installations the vault is filled manually by whoever needs the access, and emptied by nobody.

Without a process

Four things that happen slowly enough that nobody notices

Missing removal never announces itself. It shows up as a slow drift, where the contents of the vault and the reality of the organization come apart.

The vault grows: accounts from finished projects, former employees, and decommissioned servers stay behind, because creating them was easy and removing them is somebody's extra work.
The audit comes back: you bought the vault to document control of privileged access. If you cannot show when an access was removed, you are worse off than before, because the expectation is now higher.
Recertification becomes a signature: when nobody can say why an account was created, it gets approved again. The control exists on paper and fails in practice.
The attack surface moves: a forgotten account in the vault still carries its privileges, and it now sits in one place alongside all the others.

The answer

The request belongs in IGA

A privileged account is an access like any other. It should be requested, approved, given an owner and a purpose, reviewed at fixed intervals, and closed when the basis for it disappears. That is exactly the lifecycle an IGA platform already handles for ordinary access.

So let IGA govern the lifecycle and PAM hold the password. IGA knows who is employed, in which role, and until when. PAM knows how a password is stored, rotated, and handed out. Connect the two, and a privileged account no longer comes into existence without a decision behind it.

In practice

Four patterns that work

The patterns below have been built at several Danish organizations. They are alike in principle and differ in what triggers the creation.

The personal admin account: the employee requests it in IGA, the manager and the system owner approve, and the account is created automatically and placed straight into the vault. The owner uses it through PAM without ever knowing the password.
The service account: the same flow, but with a named owner, a purpose, and an expiry date. When the project ends, the account expires on its own unless somebody actively extends it.
The server lifecycle: when a new server is created, a safe is created automatically with the shared accounts the server needs, together with the accounts other systems need, for example the one your CMDB uses to keep the server record up to date.
The removal: the same flow in reverse. When the employee leaves, the service account expires, or the server is decommissioned, both the IGA assignment and the vault accounts disappear without anyone having to remember.

Prerequisites

What has to be in place first

The link rests on three things. A reliable source of who is employed and in which role, usually the HR system. A role model that covers the privileged roles as well, so a request can be approved against a rule rather than a judgement call each time. And a decision that PAM is treated as a target system like any other that IGA provisions to.

The last one is often the hardest, because the vault is typically owned by the security team while IGA is owned by IT or HR. Agree who owns what before the technical work starts, and write that agreement down.