An ITAM program without metrics is a filing exercise, and an ITAM program with only hardware metrics is worse: it looks green while the software and identity layer leaks unmeasured. The KPIs below are split by layer, each with its formula and its honest caveat, because half the value of a metric is knowing how it can lie to you.
Most ITAM KPI lists have a composition problem: fifteen metrics, twelve of them about hardware, and the estate's fastest-moving layer measured by nothing.
That composition made sense when software was a minor line item. It doesn't now, when the recoverable money sits in idle SaaS seats and the sharpest risk sits in accounts nobody deprovisioned.
So this list is organized the way the estate is organized: hardware-layer KPIs (mature, mostly solved), software-and-license KPIs (where the money is), and identity KPIs (where the risk is, and where most programs compute nothing at all). For each: what it measures, how to calculate it, and how it gets gamed, because a KPI whose failure modes you don't know is a number, not a measurement.
Two rules before the list. First, pick a handful per layer and baseline them before setting targets; a metric with no baseline invites invented benchmarks. Second, report the layers separately. An aggregate "asset health score" is how a leaking SaaS layer hides behind a well-run laptop fleet. (The practices these metrics verify are covered in our IT asset management best practices.)
Hardware-Layer KPIs
1. Inventory accuracy rate Formula: verified assets matching the register ÷ assets sampled × 100 The foundational hardware metric, measured by physical spot-checks against the register. Mature programs run 95%+ here. Caveat:accuracy of what's in the register says nothing about what never entered it. Pair with a discovery-based completeness check or this number flatters the record while missing the estate.
2. Asset utilization rate Formula: assets in active use ÷ total assets owned × 100 Surfaces the drawer laptops and idle spares. Low utilization on a growing hardware budget is a purchasing process problem wearing an inventory costume.Caveat: "in active use" needs a definition (assigned? powered on in 30 days?) or teams will pick whichever reading looks best.
3. Mean time to provision Formula: total time from request to working asset ÷ number of provisions The employee-experience metric: how long a new joiner waits for a working machine. Also the metric that quietly drives over-purchasing, since buffer stock is the easy fix for slow provisioning.
4. Refresh and warranty compliance Formula: assets within refresh policy or active warranty ÷ total assets × 100Aging fleets shift cost from planned refresh to unplanned failure and shift risk toward unpatched, unsupported hardware.
5. Total cost of ownership per asset class Formula: (acquisition + support + maintenance + disposal) ÷ assets in classThe budgeting metric, most useful in trend: TCO drifting up in one class usually means a support burden that a refresh or standardization decision would fix.
Software and License KPIs
6. Inventory completeness (the unmanaged estate) Formula: applications known to procurement ÷ applications discovered via all signals × 100 The single most revealing software metric, and the first one to compute. Run discovery from SSO, finance transactions, and directory data, then divide what procurement knows by what discovery found. First-time results below 50% are common; the remainder is the estate none of your other KPIs can see. Caveat: this KPI is only as honest as the discovery breadth behind it. Procurement-list-divided-by-SSO-list misses everything that touches neither.
7. Assignment gap Formula: (seats purchased − seats assigned) ÷ seats purchased × 100, per contract Pure shelfware: seats sitting on nobody. The contractual fix is buying fewer at renewal, which makes this the metric to compute at T-90 of every major renewal.
8. Usage gap Formula: (seats assigned − seats active in window) ÷ seats assigned × 100, per contract The harder, more expensive gap: seats attached to real people who never open the tool. Requires per-user activity data, which is exactly why most organizations have never computed it. Caveat: define "active" per app tier. A daily login to view a dashboard and daily premium-feature work look identical in a login count and completely different in value terms.
9. License utilization rate Formula: actively used licenses ÷ purchased licenses × 100 The rolled-up inverse of the two gaps, useful for executive reporting precisely because it's one number. Keep the per-contract gaps underneath it or the average hides the worst offenders.
10. Renewal coverage Formula: renewals reviewed ≥30 days before the date ÷ total renewals × 100 Measures whether renewals are decisions or events. Anything below 100% is a count of contracts that renewed on the vendor's terms by default.
11. Realized vs. potential savings Formula: value of licenses actually reclaimed (annualized) vs. value of licenses currently flagged Two numbers, deliberately never merged. Potential savings is a to-do list; realized savings is a result. Programs that report potential as achieved lose finance's trust exactly when they need it, and the gap between the two numbers is itself a KPI: it measures whether flagging leads to action.
Identity-Layer KPIs
This is the layer most ITAM programs don't measure at all, and it's where asset management and security stop being separate conversations: every software asset is held by accounts, and unowned or undead accounts are simultaneously spent and exposed.
12. Orphaned account rate Formula: active accounts belonging to departed or unknown users ÷ total accounts × 100The metric behind the audit findings. Compute it across all applications, not just SSO-federated ones; accounts created directly in apps are precisely the ones that survive offboarding.
13. Time to full deprovision Formula: hours from departure event to last license reclaimed and last account closed Note the definition: full deprovision, every app, every license, every account, not the SSO cutoff. Organizations measuring only SSO revocation typically show minutes; measured properly, the honest number is often weeks, and the difference between those two numbers is the size of the offboarding gap.
14. Non-human identity ownership rate Formula: service accounts, tokens, and integrations with a named owner ÷ total non-human identities × 100 The forward-looking one. Machine identities now outnumber human ones in most environments, and an unowned service account is an asset with no lifecycle: never reviewed, never rotated, never retired.
15. Unfederated application rate Formula: applications in use outside SSO ÷ total applications in use × 100 Every app on the wrong side of this ratio is one where offboarding, access review, and license reclamation all require manual work per departure. It's the leading indicator for KPIs 12 and 13.
Reporting Them Without Fooling Yourself
Three habits keep the dashboard honest. Report per layer, never as one blended health score. Trend against your own baseline rather than invented industry benchmarks, because definitions vary too much across organizations for cross-company numbers to mean anything. And for any KPI tied to an incentive, write down its gaming path (redefine "active," narrow the denominator, reclassify instead of fix) and audit for that path specifically. A KPI that has never surprised anyone is usually being gamed or being ignored.
Where Zluri Fits
The hardware KPIs come from your device-management stack. The software and identity KPIs are what we built Zluri to compute continuously rather than as a quarterly project: discovery across eight methods produces the completeness denominator (KPI 6), per-contract purchased-assigned-used reconciliation produces the gap metrics (7 through 9), the renewal calendar produces coverage (10), potential, wasted, and realized savings are tracked as deliberately separate figures (11), and the identity graph produces the orphaned-account, deprovisioning-time, and non-human ownership numbers (12 through 14) that most programs currently guess at. The mechanics behind the license numbers specifically are documented in how Zluri handles software license management.
Frequently Asked Questions
Which ITAM KPIs should we start with if we're measuring nothing today?
Three, one per layer: inventory accuracy for hardware (a sampled spot-check), inventory completeness for software (procurement list divided by discovered list), and orphaned account rate for identity. Each is computable in days, each produces a number leadership immediately understands, and together they reveal which layer needs the program's attention first.
What are good benchmark values for these KPIs?
Treat published benchmarks with suspicion, because the definitions underneath them vary too much to compare. The workable approach is baseline-and-trend: compute your own current values, set improvement targets against them, and reserve external comparison for metrics with unambiguous definitions, like renewal coverage, where 100% is simply the target.
Why measure time to full deprovision instead of SSO revocation time?
Because SSO revocation only covers federated applications. Accounts created directly inside apps, with an email and password, survive the SSO cutoff, keep their licenses billing, and keep their access live. Measuring only the SSO number reports the process you have; measuring full deprovision reports the outcome you need, and the gap between them is the offboarding exposure.
How often should ITAM KPIs be reported?
Match the layer's tempo. Hardware metrics move slowly and suit quarterly reporting. Software and identity metrics move with every hire, departure, and renewal, so monthly reporting is the workable floor, with the event-driven ones (deprovisioning time, renewal coverage) reviewed as the events occur rather than batched.
.svg)
