Most ITAM best-practice lists assume the estate is one uniform thing that needs tagging, auditing, and reviewing. It isn't. It has two sides running at two speeds: hardware assets that change in years and can be physically verified, and software, SaaS, and account assets that change in days and can't. The practices below manage both sides, and, more importantly, the processes that cross between them (offboarding, refreshes, access requests), because those crossing points are where ITAM programs actually break.
Here's a test for any ITAM program: a laptop comes back during an offboarding. The device gets checked in, wiped, and re-inventoried, textbook asset management. Now, did anything reclaim the eleven SaaS licenses the departing employee held? Did the accounts they created outside SSO get closed? In most organizations, the honest answer is that nobody knows, because the device process and the software process don't share an event, an owner, or a record.
That's the pattern this article is about. ITAM failures rarely happen inside one side of the estate; hardware tracking is usually well-run, and the software side at least has tooling somewhere. The failures happen in the gaps between the two, in processes like offboarding that need both sides to act, and in the mismatch of reviewing fast-changing software assets on a slow hardware schedule. So these six practices cover three things: running each side on its own terms, connecting the processes that cross between them, and measuring them separately enough that success on one side can't hide the other's leak. (The definitional ground, what IT asset management covers and why software assets break classic tracking instruments, is in our complete guide; this article assumes it and moves to practice.)
1. Run Two Inventories, Keep One Register
The two sides of the estate are visible to entirely different instruments. Devices and network infrastructure are found by scans, agents, and physical verification. SaaS applications, subscriptions, and the accounts holding them are found by SSO sign-ins, finance transactions, integrations, and directory data, signals no scanner reads.
The practice has two halves, and organizations reliably do only the first:
- Use the right instrument per side. A device-management tool for hardware custody; an identity-and-finance-signal platform for software and SaaS. One tool claiming both is usually strong at one and marketing the other.
- But maintain one register. The two inventories must reconcile into a single asset register with common fields: owner, cost, status, lifecycle stage. Two inventories that never meet just relocate the fragmentation problem, and audit evidence, budgeting, and offboarding all need the joined view.
MDM data is the natural bridge: device-reported installations feeding the software inventory connect "this machine" to "these applications" without either side pretending to be the other.
2. Review Hardware on a Schedule, Software at Events
A laptop's inventory record is valid for years; quarterly or even annual physical verification is a defensible cadence for hardware. A SaaS record decays in weeks: seats change with every hire and departure, tools arrive on corporate cards, contracts auto-renew.
Applying the hardware review schedule to software assets is the single most common ITAM process error, and it has a precise cost: every month between a software asset going stale (idle seat, departed employee's account, converted free tier) and the next review is a month of spend or exposure nobody chose. So:
- Hardware assets: periodic verification, scheduled refresh planning, annual physical audit as genuine practice.
- Software, SaaS, and account assets: continuous, event-driven updating, with periodic audits demoted to verifying the continuous machinery works.
If one sentence of this article makes it into your program charter, it should be this one: audit cadence for hardware, event cadence for software.
3. Connect the Processes That Cross From Hardware to Software
Some processes need both sides of the estate to act: offboarding, hardware refreshes, access requests. These are where well-run ITAM programs quietly fail, because each side's step completes successfully while the joint outcome fails. The offboarding example from the introduction is the canonical one, and it has siblings:
- Device return without license reclamation. Hardware process succeeds, eleven subscriptions keep billing.
- The closed ticket that ends the process, not the work. An offboarding ticket marked resolved is an ITSM success; the unreclaimed licenses behind it are an ITAM failure. The two disciplines meet exactly here, a boundary we map fully in ITAM vs ITSM.
- MDM-detected software that never enters the software inventory. The device tool sees the installation; nobody governs the application.
- A hardware refresh that orphans licenses. Machines get replaced; the software assigned to the old fleet never gets reviewed.
The practice: define these cross-team processes explicitly, as single chains with single completion conditions. Offboarding = device return and full license reclamation and account closure, one chain, complete only when all three are. Refresh = device swap and software reassignment review. If your ticketing system can close the event while half the chain is open, the chain isn't defined yet.
4. Assign Ownership Per Asset, Split By Dimension
Unowned assets are where problems age: nobody questions the renewal, reviews the risk, or notices the zero usage. And "IT owns everything" is diffusion, not ownership.
The workable model names an owner per asset and splits the role by dimension, because a single asset genuinely has different stakeholders: an administrative owner (stewardship and classification), a financial owner (spend and the renewal decision), and a security owner (risk and access review). This applies across both sides of the estate; the difference is volume. A hardware fleet has hundreds of assets to own; a SaaS estate has hundreds of applications times the accounts inside each, which is why ownership assignment for software has to be automated at discovery, not assigned retroactively in an annual cleanup.
The software-side specifics of this practice (and the record structure underneath it) are covered in our software asset management best practices; the license-level equivalents live in the software license management best practices.
5. Keep the Register Permanently Audit-Ready
Compliance frameworks (SOX ITGC, ISO 27001, and their relatives) expect a defensible, current record of IT assets, their owners, and the controls governing access to them. Most organizations treat that as a deliverable to assemble when asked, which produces the audit scramble: weeks of reconstruction from systems that don't reconcile.
The practice inverts it: the register is the export. If practices 1 through 4 are running (one register, current on both sides, owned, with lifecycle status attached), then audit evidence is a filtered export with ownership, status, spend, and access data already on every record. The test is simple and worth actually running: ask for the full IT asset register today, unannounced. If producing it takes more than an hour, it's a project, not a register.
6. Measure Hardware and Software Separately
An ITAM program measured in aggregate can post excellent numbers while one side leaks, and it's always the same side. Hardware metrics (inventory accuracy, utilization, refresh compliance) are mature and usually green. The software and account metrics are the ones most programs don't compute at all:
- The purchased-assigned-used gaps per major contract
- Time-to-reclaim at offboarding (licenses and accounts, not just devices and SSO)
- Orphaned account rate, human and non-human
- Discovered-but-unmanaged application count
- Realized versus potential savings from reclamation, kept honestly separate
Measuring the two sides separately is what makes the stale-software problem and the broken cross-team processes visible instead of averaged away. The full metric set, with formulas and the honest caveats about which ones are gameable, is in our guide to ITAM KPIs.
Where Tooling Fits
Hardware tooling is a solved problem, and the comparison across both kinds lives in our guide to IT asset management software. What we built Zluri for is the software side and the cross-team processes these practices keep pointing at: software and account discovery across eight methods feeding one register (practice 1), continuous event-driven updates rather than periodic review (practice 2), offboarding chains that reclaim every license and close every account, not just the SSO session (practice 3), three owner roles assigned per application (practice 4), the full register exportable on demand for audit evidence (practice 5), and the software-side metrics, gaps, reclamation times, orphaned accounts, computed continuously (practice 6). Device data joins through MDM integrations as context in the same records, which is the bridge, not a competing hardware register.
Frequently Asked Questions
How are ITAM best practices different from SAM best practices?
Scope. SAM best practices govern software assets specifically: inventory completeness, unified app records, classification, software lifecycle. ITAM best practices cover the full estate, hardware included, and their distinctive content is exactly what SAM can't see: the hardware discipline itself, and the cross-team processes (device returns, refreshes, offboarding chains) where both sides have to act as one program.
What's the most common ITAM mistake in practice?
Reviewing everything on one schedule. Hardware tolerates periodic review; software doesn't, because software assets change at every hire, departure, and card swipe, and stale software records bill monthly. The second most common mistake is its cousin: buying one tool and expecting it to see both sides of the estate.
Who should own cross-team processes like offboarding?
The chain needs a single completion owner, even though its steps span teams. In practice that means defining offboarding (or refresh) as one event with an explicit checklist spanning device, licenses, and accounts, and refusing to let the ticket close while any item is open. Which team hosts the chain matters less than the rule that no single team can declare it done.
How do we start if we currently only manage hardware?
Stand up the software inventory first (SSO, finance transactions, and directory data will produce a working picture in days), then diff it against what procurement knows: that gap is your unmanaged estate and your business case. Then wire the two highest-value cross-team processes, offboarding and renewals, before attempting anything comprehensive. Measurement (practice 6) comes early, not last, because the gap numbers are what keep the program funded.
.svg)
