20 Identity and Access Management Metrics Your Team Should Track in 2026

Your board asks one question. What percentage of your privileged accounts use phishing-resistant MFA? You've spent millions on IAM tools. You run an IdP, a governance platform, a PAM tool, and a wall of dashboards. And you can't answer in under a week.

That's the gap. Not a shortage of tools, a shortage of numbers you can act on. IAM metrics are supposed to tell you whether your access controls reduce risk, clear audits, and keep people working. Most teams track the ones that look good on a slide and quietly ignore the ones that would change what happens by Friday. A 99% MFA coverage number feels great in a QBR. It tells you nothing about the service account that hasn't rotated its key in 400 days.

So the right question isn't "what should I measure?" Plenty of lists answer that. The question is which numbers carry an owner and a trigger, so that a bad reading sends someone to do something instead of sitting in a report nobody reads.

What these numbers actually measure

IAM metrics fall into two camps, and confusing them is why most programs measure the wrong things. One camp tells you how well your access processes run. The other tells you how much risk is piling up while those processes run.

Performance metrics, your KPIs, measure throughput and coverage. How fast you provision a new hire. What share of your workforce has MFA enforced. How many access reviews you finished on time. These answer the question "is the machine doing what we built it to do?" They're the numbers that justify the budget you already spent.

Risk metrics, your KRIs, are early warnings. Orphaned accounts. Segregation-of-duties violations. Standing privilege that never gets revoked. These don't tell you how busy you are. They tell you where the next breach gets in. They're the numbers that justify dropping what you're doing and intervening today.

Here's where it goes wrong. A team can post a flawless performance scorecard while risk climbs in the background. You provisioned 200 people in record time this quarter. Great. How many of them kept access to a tool they used once and never touched again? You completed every access review on schedule. Also great. How much access actually got removed as a result, or did your managers approve all of it in a single afternoon of clicking?

The distinction matters because it changes who acts and when. A KPI moving the wrong way starts a planning conversation. A KRI moving the wrong way should start a pager going off. Treat them as interchangeable and you'll keep reporting strong performance right up until the incident review, where someone pulls the orphaned-account number you'd been carrying for eight months and asks why nobody owned it.

Most of the rest of this piece walks through the metrics that matter in each domain, with the formula and the benchmark for each. But hold on to the split. A number without a clear answer to "is this performance or risk, and who acts when it breaks?" is decoration.

The metrics that prove accounts get created, changed, and killed on time

Provisioning fast is easy to celebrate. Killing access on time is the part that quietly fails, and these are the numbers that expose it. A departed employee with a live login is the cleanest example of a metric that's also a breach waiting to happen.

Orphaned account rate

The count of active accounts with no valid owner or business justification, divided by total active accounts. Your target is zero, with a tolerance of maybe 1% during transitions. Orphaned accounts are doors that bypass the rest of your security entirely, and they breed in the gaps left by incomplete offboarding, contractor churn, and service-account sprawl.

Dormant account rate

The quieter cousin of orphaned accounts, measured as accounts with no sign-in for a set window divided by total accounts. Auto-disable human accounts after 90 days of inactivity. Hold service accounts to a documented exception or a 180-day review. A dormant admin account is a loaded weapon nobody's watching.

Time-to-provision

The median time from an approved request to a working account. Provisioning slow costs you productivity and sets the tone for a new hire's first week.

Time-to-deprovision

The median time from a confirmed termination to fully revoked access. Deprovisioning slow costs you a breach. Hold it to 24 hours or less for standard accounts, 4 hours or less for privileged roles, and same-day for high-risk departures. That 24-hour bar isn't arbitrary. Most mature programs hold to it because NIST's AC-2 expects deprovisioning tied to the termination event, on a timeframe you define, and a terminated user with active access is an insider threat from the moment HR hits submit.

Joiner-mover-leaver SLA adherence

The share of lifecycle events processed inside policy. Joiners ready on day one. Movers transitioned in 24 to 48 hours. Leavers cut same-day. This single number tells you whether your lifecycle runs on automation or on a person remembering to file a ticket.

The trap in this domain is celebrating the joiner half and ignoring the leaver half, because new hires complain loudly and departed employees don't complain at all. The mover case is where it gets ugly. People change roles, pick up new access, and almost never shed the old. Track movers as carefully as you track the other two, or watch entitlement creep turn your tidy lifecycle metrics into fiction.

The metrics that measure whether the front door is locked

Identity is the perimeter now, and these numbers tell you how well it holds. Credentials are the way attackers get in. Verizon's Data Breach Investigations Report has named credential abuse the leading initial-access route for years running, and that isn't reversing. So measure the door, not just the doorbell.

MFA coverage

Users with MFA enforced divided by total active users. Segment it. Workforce coverage should sit at 95% or higher, allowing for genuine exceptions. Privileged and admin accounts get no exceptions, hold them at 100%. A blended number hides the accounts you most need to protect. And coverage on its own has quietly become a vanity metric, because attackers defeat SMS codes and wear down push prompts until a tired employee taps approve.

Phishing-resistant MFA adoption

The share of users on FIDO2, WebAuthn, or certificate-based methods that meet NIST's phishing-resistance bar at AAL3. This is the number that actually tracks the modern threat. Push for 100% on privileged accounts first, then climb the general workforce past 50% inside a year. If your coverage is high but your phishing-resistant adoption is near zero, you're measuring the wrong win.

Legacy authentication rate

The inverse signal, the share of attempts using protocols that can't enforce MFA at all, like Basic Auth or LDAP simple bind. Target zero, with documented exceptions and compensating controls. Every legacy auth path is a way to skip every control you just built.

SSO adoption

The front-door coverage metric, measured two ways. Application coverage is your federated apps divided by total apps, aim past 80%. User coverage is SSO authentications divided by total authentications, aim past 90%. Apps outside SSO are apps outside your conditional access and your audit trail.

Authentication success rate

Successful attempts divided by total attempts. Above 95% for legitimate users, with lockouts under 1%. This one is a usability and a security signal at once. A success rate that drops without a clear cause is your early read on a credential-stuffing run before your SIEM correlates it.

The pattern across this domain is simple. Coverage numbers tell you what you've deployed. Adoption and legacy numbers tell you what's actually protecting people. Report both, and never let the first one stand in for the second.

The metrics that prove access stays right after you grant it

Granting access fast is the easy half. Keeping it correct over months, as people move and projects end, is where governance lives or dies. These numbers tell you whether your access stays honest.

Access review completion rate

The share of certification campaigns finished on schedule. Target 100%. But completion is a trap if you stop there. A team can complete every review on time by clicking approve on everything, and a 100% completion rate built on rubber-stamping is worse than a missed deadline, because it launders bad access through a process that looks rigorous.

Remediation rate and time

What share of access actually got revoked after a review, and how fast. Hold critical findings to under 48 hours. If completion is high and remediation is near zero, your reviews are theater. The reason reviewers rubber-stamp is fatigue. Hand a manager 300 entitlements to certify and they'll approve the lot to clear their inbox. The fix is to stop asking them to re-review everything. This is the problem we built delta access reviews to solve at Lumos, surfacing only the access that changed since the last cycle so a manager sees the handful of new grants instead of the full pile. The result shows up directly in the completion and remediation numbers. Pluralsight went from reviewing 20 apps over two months each quarter to 200 apps in under two weeks, because the reviewers were finally looking at signal instead of noise.

Direct-entitlement exception rate

Users holding access outside their defined role, divided by total users. Keep it under 10% with documented justification. A high number means your role model has rotted and people are getting access through one-off grants nobody governs. It's the cleanest read on whether least-privilege is real or aspirational.

Entitlement creep

The drift of permissions a user accumulates as they move through roles without shedding the old. It's the slow-motion version of the orphaned-account problem, and it's why the mover case from your lifecycle metrics matters as much as the leaver case. Access that only ever grows is access you no longer control.

The metrics for standing privilege and the machine identities nobody's watching

Standing privilege and unmanaged machine identities are the fastest-growing blind spot in most access programs, and they're underrepresented on nearly every dashboard. Human admins get attention. The thousands of service accounts, API keys, and workload identities running quietly in the background rarely do, even though they now outnumber your people.

JIT privileged access coverage

The share of admin access granted just-in-time with approval and an expiry, measured against persistent privileged accounts. Push past 90% for human administrators. The point is blunt. A standing admin account is a standing risk, a permanent target that's live whether or not anyone's using it. Every privilege you convert from always-on to granted-on-request shrinks the blast radius of a compromised credential. The metric to watch is the ratio, and the direction you want it moving is toward zero permanent admins.

PAM session logging coverage

The share of privileged sessions captured with full recording. Target 100%, with defined break-glass procedures. If a privileged action isn't recorded, it didn't happen as far as your auditor is concerned, and it can't be reconstructed after an incident.

Break-glass account usage

A near-zero signal. These emergency accounts should activate only for documented emergencies, so any usage is an event worth a real-time alert, and you should test them quarterly with a 100% pass rate. An emergency account that fails when you reach for it is the worst surprise in this domain.

Non-human identity secret rotation age

The metric the listicles forget. For every API key, service-account password, and certificate, measure the share exceeding your policy maximum, typically 90 days, and the median age of what's live. The target is zero past policy, with automated rotation for cloud workloads. A service account whose key hasn't rotated in a year is a credential an attacker can use indefinitely, and it won't show up in any sign-in anomaly report because the account is behaving exactly as designed.

This is the domain that's changing fastest as agentic AI and automated workloads multiply. Every agent that acts on behalf of a user is another identity that needs an owner, a governance path, and a rotation clock. If your metrics still assume identities are mostly people, you're measuring the population you had three years ago, not the one running in production today.

The accountability layer, where most programs stop too soon

Here's what the other guides to these numbers leave out. They tell you what to measure and then stop, as if a metric were the finish line. A metric with no owner and no trigger is a number, not a control. It sits in a dashboard, drifts the wrong way for months, and surfaces only in the incident review when someone asks why nobody was watching.

The fix is to attach two things to every metric you keep. Someone who owns it, by name or by role, and a specific action that fires when it crosses a threshold. That turns a reporting habit into an operating model, the part of your IAM strategy that actually runs instead of sitting in a deck. The table below does it for the highest-value metrics in this piece.

‍

Two things change once you run this way. First, the conversation in your QBR shifts from "here are our numbers" to "here's what each number made us do," which is the version executives actually fund. Second, you find out fast which metrics nobody will own. Those are the ones to either assign or retire, because an orphaned metric is as useless as an orphaned account.

You don't need all seven on day one. Pick the three with the worst current reading, give each an owner and a trigger, and expand from there.

The identity metrics that show up on the budget

Here's a connection almost nobody on the security side measures. Every orphaned account and every unused entitlement is frequently a paid license nobody reclaimed. Finance and security are staring at the same waste from opposite ends of the building, and neither one has the full number.

License-reclamation rate

The licenses you've actually pulled back divided by the unused licenses you've identified. A low number means you can see the waste but aren't acting on it, which is the same failure pattern as completing reviews without remediating. The dormant-account metric from your hygiene domain and the unused-license metric from the finance domain are often the same accounts described in two vocabularies. Measuring them together turns an access-hygiene chore into a line item your CFO cares about. We've watched this play out with customers like Nubank, who reclaimed unused licenses and closed offboarding gaps for $2.7 million in recovered software spend, while cleaning up hundreds of incompletely offboarded users in the same pass. The security win and the cost win were the same project.

Redundant-app rate

The share of your stack that duplicates a function you already pay for somewhere else. Uncoordinated buying across teams leaves you paying two and three times for overlapping tools, each one another set of identities to govern and another door to watch. Rationalizing them shrinks both your bill and your attack surface at once.

The reason to put these on the same dashboard as your MFA coverage is leverage in the budget conversation. A CISO who walks in with risk numbers alone is asking for money. A CISO who walks in showing risk reduction and recovered spend in the same motion is making the case fund itself.

Where the data lives and how to stitch it together

Reliable IAM metrics don't come from one place. They come from correlating data you already have scattered across five tools that don't talk to each other by default. Knowing where each number lives is half the work of producing it.

Your identity provider holds the authentication picture, sign-in logs, MFA enrollment and enforcement state, conditional access outcomes, and risk detections. That's where MFA coverage, legacy auth, and authentication success rate come from. Your governance platform holds the lifecycle and entitlement view, access request and approval trails, role assignments, exceptions, and review campaign results, which feed your completion, remediation, and direct-entitlement numbers. Your PAM tooling holds privileged session records and break-glass logs.

For the timers, the source of truth isn't IT at all. It's HRIS, which carries the authoritative joiner, mover, and leaver timestamps. Your time-to-deprovision number is only as honest as the termination time you measure against, and that lives in the people platform. And your cloud provider APIs expose the machine identities, the access keys and their ages, that no human-centric tool will surface.

The hard part is stitching. A metric like time-to-deprovision spans HRIS for the termination event and your IdP and governance tooling for the revocation, joined on a common identifier such as email, employee ID, or UPN. Get that join wrong and every cross-tool metric you report is fiction.

The deeper problem is freshness. Most teams produce these numbers with a quarterly spreadsheet pull, which means the figure is stale the day after you export it and you're governing on a snapshot of a moment that's already gone. Continuous instrumentation, where the numbers update as access changes, is the difference between catching an orphaned account this week and finding it in next quarter's audit.

The numbers only matter when you act on them

Every metric in this piece is useless until someone owns it and something happens when it goes red. That's the whole argument. The teams that win at identity aren't the ones with the most numbers on a dashboard. They're the ones who turned a handful of the right numbers into triggers that fire on their own, so a stale key gets rotated and a privileged leaver gets cut without waiting for a human to notice. The manual, point-in-time version of this work, the quarterly spreadsheet pull and the all-day click-through review, is how good metrics go to die.

The shift worth making is from measuring access to governing it as it changes. Numbers that update the moment access shifts, reviews that show only what's new, lifecycle events that trigger revocation the instant HR files a departure. When your instrumentation runs continuously and each metric carries an owner and an action, your audit stops being a fire drill and your risk numbers start moving in the direction you want without anyone babysitting them.

That's what we built Lumos to do. We discover every app, identity, and entitlement, human and machine, then run the governance work on auto-pilot, delta access reviews that cut review time by 70%, joiner-mover-leaver automation that took Roku's onboarding down by 99%, just-in-time access that drops standing privilege, and license reclamation that turns the same cleanup into recovered spend. Customers deflect 40% of their access tickets and reduce over-privileged access by 80%, and they get there in under three months instead of the multi-year slog legacy tooling demands. If you're tired of producing metrics nobody acts on, see what your own numbers look like when the work runs itself and book a Lumos demo.

‍