Most PAM programmes get judged on a vault count and a coverage percentage, and not much else. Neither number tells you whether someone who lands on a laptop tonight can still walk a privileged credential to your domain controller by morning.
Verizon’s 2026 Data Breach Investigations Report has vulnerability exploitation overtaking stolen credentials as the leading way attackers get in this year: credential abuse fell to 13% as an initial access vector, down from 22% the year before. Read that as good news for privileged access and you’ve misread it. The same report breaks down what actually closes an intrusion once an attacker is inside, and privilege management is the single biggest lever: about 65% of the credential-access and escalation techniques Verizon tracked are addressed specifically by privilege management, ahead of configuration changes, password policy, and patching individually. Underground markets price the same priority. A stolen admin credential sells for a median of $1,300, nearly double the $700 a standard user account fetches.
That gap, between a tool being deployed and a tool actually doing its job, is what most PAM measurement misses. iConnect builds and runs PAM deployments for clients across UAE banking, healthcare, and energy, covering everything from credential vaulting to privileged session management, and the question we get asked least is how many accounts are vaulted. The harder question, the one that actually tells you something, is rarely asked at all.
Coverage starts with the accounts nobody put on the spreadsheet
A vault percentage is only as good as the inventory underneath it. Every PAM onboarding we run turns up privileged accounts the client’s own list missed: a service account nobody remembers creating, a shared local admin password sitting on dozens of workstations, a database connection string still hardcoded into a script from three years ago. None of those show up on a spreadsheet handed over at kickoff. All of them are exactly what an attacker goes looking for.
Cloud makes the discovery problem worse, not better. An Entra ID Global Administrator role, an Azure subscription Owner, an AWS root user: these are privileged access in every sense that matters, and they rarely sit inside the same inventory exercise that catches on-premises domain admins. Run discovery against Active Directory, local admin groups, cloud IAM, and the application layer together, not as separate projects months apart.
The number worth tracking is accounts vaulted as a percentage of accounts actually discovered, not accounts vaulted as a percentage of the list someone wrote down in a meeting. If your last discovery scan is older than six months, that number is already wrong.
Standing access is the default failure most dashboards don’t show
Vaulting a credential is not the same as controlling when it gets used. We regularly review environments where domain admin or root access is technically vaulted but practically standing: checked out once, never checked back in, or granted permanently to the same handful of admins regardless of whether they’re touching that server today.
Track the ratio instead. What percentage of privileged sessions last month were time-bound and tied to a ticket, against what percentage were simply available whenever someone wanted them? A proper checkout and check-in workflow exists precisely so access expires when the task does. A platform that can’t answer that ratio question can’t tell you how exposed you are between incidents, no matter how complete the vault looks.
That number is harder to pull than a coverage percentage. It also matters more.
Rotation and bypass: the two numbers that expose a programme that looks fine on paper
Two more numbers get ignored, usually together. The first is rotation compliance: the percentage of vaulted credentials that actually rotated on the schedule the policy claims, rather than sitting on the same hash for eight months because a service depends on it and nobody wants to be the one who breaks it.
The second tells you the truth faster. Out-of-band access means a login to a privileged target that never touched the vault at all. Correlating vault checkout logs against actual authentication events on the target server will surface that gap in minutes instead of waiting for a quarterly audit, but the correlation has to be built, not assumed: a parser for the vault’s audit log, a rule tying it to the target’s authentication events, the same category of integration work as any other custom use case on a platform like FortiSIEM. The signal worth alerting on isn’t just whether a login matches a vault session. It’s checkouts happening outside business hours, the same credential checked out from two sessions at once, or a string of failed checkout attempts right before a successful one. A local admin logon on a critical server with no matching vault session is exactly the pattern that correlation is built to catch, and it shows up more often in real environments than most teams expect. That gap is the real measure of whether PAM is a control or a suggestion.
Recording every privileged session and reviewing none of them belongs in the same category. Track what fraction of recordings actually get watched, by a person or by behavioural analytics, and whether checkout requires step-up authentication or just a password. A vault guarded by a single factor isn’t protecting much.
The number that matters in front of an auditor
Every NESA, SAMA, or ISO 27001 review eventually asks the same question: show who had access to this system on this date, and prove it was approved. Programmes that pull that answer from the platform in minutes get through the conversation without drama. Programmes that need three days and a spreadsheet reconstruction are telling the auditor something true about the rest of their controls too.
Time-to-evidence is not a soft metric. It’s usually the first place a real gap in a PAM programme becomes visible to someone outside the security team.
None of these numbers live on a vendor’s default dashboard, because vendors report whether the tool is installed, not whether it’s working. iConnect builds and reviews PAM deployments across UAE banking, healthcare, and energy clients, and we check our own work against the metrics above before we hand a credential back to anyone. If you want a straight read on where your programme actually stands, talk to our security engineering team.
