PAM Cleanup in Practice: Discovery, Risk Triage and Lifecycle Governance.

I've worked on several PAM cleanup projects. The environments may look different but the core problems largely remain the same. Before any technical work begins, you need clarity on what a governed state looks like. The PAM strategy needs the right authority to own the program. Someone or a team who understands the risk and has the authority to remove organizational blockers. It could be the Security Manager, the CISO, or sometimes the IT Director. Without that, cleanup stalls at the first point of resistance.

Before any cleanup starts, you need to know what you are actually cleaning. Begin by mapping the estate: pulling accounts from AD, Unix/Linux directories, application stacks, any legacy systems still in use, any on‑prem directories feeding into cloud identity platforms, and sometimes local admin accounts on servers and workstations. Once we pull all the raw account data from different sources, we clean it up so we have one consistent, deduplicated inventory to work with. From there correlate with CMDB entries, application owners and entitlement workflows to understand context like who owns what and why it exists. That discovery phase sets the stage for everything that follows.

The risk picture then usually follows a standard pattern defined by risk level. Domain level privileges and over privileged roles come first followed by password rotation or the lack of it. Then password hygiene like shared credentials and clear text passwords in config files and scripts. Then vaulting gaps with accounts that live outside the PAM platform entirely. Finally ownership and documentation where accounts have no attributed owner, application links or clear reason for existing.

Nobody did anything wrong. Onboarding depended on whoever handled the request that day. Some documented thoroughly, others did the minimum. Even with automation built into an ITSM system, some account purposes could be described as "needed for admin work", which is undescriptive if not outright vague. Over the years and multiple staff changes, that inconsistency becomes an estate nobody could fully explain or confidently touch.

So we triaged by risk. Domain privileged accounts came first, then accounts tied to decommissioned applications for removal, and the rest went into a governance queue. For every unowned account, we worked back through logs, infrastructure or applications teams and CMDB records. Where we found an owner, we documented and brought them in. Where we could not attribute ownership in a defined window, we disabled the account, observed for breakage and removed it if nothing surfaced. That wonderful scream test exercise.

For on premises services, the answer for most workloads becomes gMSAs. The credential risk largely disappears because the password is managed by the domain, rotated automatically, never known to any human and cannot be phished or leaked through an infostealer. For cloud workloads, managed identities serve the same purpose, and the identity is bound to the resource that needs it. These implementations do carry their own risks and require layered controls, such as protecting the server binding attribute for gMSAs and defending against SSRF for managed identities. Most importantly, they need the same level of governance applied to the rest of the privileged identities.

Where service accounts are unavoidable, the control is the onboarding process. A mandatory intake capturing owner, application, justification, privilege scope and review date before the account enters the vault. No exceptions. That standard enforces consistency regardless of who is handling the request.

The cleanup was the easier part. The harder part was agreeing that onboarding standards and lifecycle governance are how the program runs from that point forward, regardless of who is sitting in the chair, rather than a one‑off project.