Executive summary

One click can hand someone a credential they never owned.

Most Privileged Access Management programs pass their technical audits — vaulting works, rotation works, session recording works. The gap that doesn't show up on a vault health check is whether the person who can rotate a credential is the person who's actually accountable for it. That gap is a governance defect, not a tooling defect, and it scales with the size of the estate.

The problem, plainly

Where the control actually breaks down.

A PAM platform enforces whatever permission structure it's given — nothing more. When any user who can onboard a Windows, Unix, database, or LDAP account into a safe they control is also automatically granted the right to trigger a password change on it, the platform can't distinguish "I administer this account" from "I found this account and put it in my safe." Both look identical to the vault. The only place that distinction can live is in a system of record that tracks who actually owns what — which is exactly the role a CMDB already plays for every other IT asset, just not yet for privileged accounts.

In one sentence: safe membership is being treated as a proxy for ownership, and the two are only correlated by accident, not by design.

Magnitude of the risk

Why this isn't a theoretical edge case in any estate of meaningful size.

scalegrows fast
Exposure scales with applications × instances × platform types — a mid-size estate easily carries thousands of safes, most managed by rotating staff over years.
detectabilitylow
A rotation performed by the wrong person looks identical in the vault's logs to a legitimate one — there's no technical signal, only a governance record that may not exist.
blast radiusasymmetric
Privileged accounts by definition carry outsized reach — a single mis-owned production credential can affect an entire application, not one user's access.
audit exposurerecurring
Regulated financial services firms face this exact question every audit cycle: "who is authorized to rotate this credential, and can you prove it?" Without a CMDB-backed answer, the honest response is "whoever happened to onboard it."

Why this must be solved now

  • 01 It's a design gap, not a monitoring gap. Detective controls (SIEM alerts, PTA rules) can flag misuse after it happens, but they don't stop the initial onboarding — and the whole point of least-privilege design is to make the wrong action unavailable, not merely loud.
  • 02 The fix is process, not a platform migration. Nothing here requires replacing the vault or the ITSM tool — it requires the two to check the same source of truth before granting a right, which is a workflow and schema change, not a re-platforming effort.
  • 03 Every quarter this stays open is another audit cycle without a clean answer. Ownership questions don't go away when deferred — they resurface at the next control review, usually with more accounts and less institutional memory of who onboarded what.
  • 04 Insider risk doesn't require malice to matter. Most mis-owned rotations are more likely to be well-intentioned overreach than sabotage — but the control has to hold regardless of intent, because the impact on the target system is the same either way.
Bottom line: the cost of closing this gap is a CMDB-driven request workflow. The cost of leaving it open is an unanswerable audit question that gets harder to answer as the estate grows. See the overview for how the model closes it, or jump straight to the data model.
AB

Abhimukta (Abhi) Banerjee

Director / Global Head, IAM & PKI Platform Operations — Nomura

25+ years in enterprise IT across regulated financial services, with 12+ years at Nomura spanning web technology and cryptography, AWS and hybrid cloud governance, and — most recently — IAM and PAM platform operations. This model reflects that practitioner lens: governance designed to be enforced by a schema, not a policy document.

Abhi Banerjee on LinkedIn