ServiceNow Hardware Asset Management Best Practices

Hardware asset management is the practice of keeping an accurate register of physical devices, who holds each one and what it cost. This guide ranks the practices that keep that register trustworthy, from automated discovery and receiving controls through to lifecycle rules, financial reconciliation and reporting. It helps an asset owner decide which practice to protect first.

Implement Automated Discovery to Minimize Manual Entry

Hardware inventory in ServiceNow requires continuous accuracy, and manual tracking alone falls behind quickly in organizations with hundreds or thousands of devices. Implement automated discovery through ServiceNow’s discovery probes or third-party tools that scan your network and report hardware details: operating system, serial number, memory, disk capacity, and last seen date. Configure discovery to run on a regular schedule, updating existing device records with new information and creating records for newly detected assets. This approach eliminates the lag that occurs when IT teams rely on end-user reports to learn about new hardware or hardware that has been retired.

Establish Clear Asset Lifecycle Stages and Retirement Rules

Hardware assets move through distinct phases: procurement, deployment, operation, maintenance, and retirement. Define clear criteria for each phase in your asset management policies. An asset in operation should have a responsible owner assigned; an asset approaching end of life should trigger an evaluation for replacement; a retired asset should have its data cleared and the physical device removed from inventory. Without these definitions, your inventory becomes cluttered with devices no longer in use, and your reports on active assets become unreliable. Some organizations use age thresholds based on typical hardware lifecycle while others track by model or operating system versions no longer supported.

Reconcile Discovered Assets Against Financial Records Regularly

Asset management serves two critical functions: operational tracking and financial accounting. Your discovered asset list should match your financial system’s records of purchased devices, accounting for timing differences. Each quarter or semi-annually, export your ServiceNow asset inventory and compare it against purchase orders and capital asset registers. Discrepancies often reveal assets that were purchased but never deployed, assets deployed without IT recording them, or assets marked as active that were actually retired years ago. Use these reconciliation cycles to clean up stale records and ensure both your IT and finance teams trust the data. If significant discrepancies appear, investigate whether your discovery configuration is missing certain device types or network segments.

Track Costs Through Installed Base and Software Licensing

Hardware costs extend beyond purchase price. Each device running carries licensing costs for operating systems, security software, and productivity tools. Build relationships between your hardware assets and software licenses so you can answer questions like: how many Windows Server licenses do we need for our active database servers, or how many user seats should we budget for given our headcount? ServiceNow’s asset relationships allow you to link purchased software to hardware and to users. When you retire a device, those licenses should be available for redeployment or return to the vendor. Organizations that neglect this tracking often over-purchase licenses because they do not know what is installed where, or under-provision licenses because they cannot see which devices need coverage.

Define Ownership and Accountability for Asset Locations

A hardware asset is most valuable when someone is responsible for it: watching for maintenance needs, planning replacement, and ensuring it is not abandoned in a storage closet or lost. Assign each asset to a cost center, a team, or an individual user depending on your organizational model. When an asset changes hands, update the owner. When an asset moves locations (especially if your organization has multiple offices), track the location in ServiceNow so you can locate it if needed and so you can answer questions about hardware distribution. This ownership structure also enables you to flag assets that have been inactive or untracked for long periods, prompting investigation into whether they are still in use or have been lost.

Use Reports to Drive Hardware Planning and Compliance

Hardware inventory reports answer critical planning questions: which assets are nearing end of life and should be replaced in the next fiscal year, what is the total replacement cost for devices older than your refresh threshold, how are we distributed across operating system versions, and which devices are missing required security updates? Build regular reports that show age distribution of devices, support status, and projected retirement dates. Share these reports with your finance team for budget planning and with your operations team so they can proactively plan refreshes instead of scrambling when devices fail. Use compliance reports to identify devices that fall outside your approved configurations so you can address them before they become security or support issues.

What a new hardware asset owner should protect in the first months

Many of the practices that circulate for hardware asset management are sound in isolation. They tend to fail when they are adopted as a set on day one, because each one assumes that the others already exist. A tagging policy presumes a receiving desk that can read tags. A refresh forecast presumes lifecycle dates that someone has actually entered. A custody report presumes that leavers are linked to their devices. The owner’s first job is therefore to rank practices by what they depend on, and to protect the ones that everything else leans on.

In many estates the foundation is the link between a physical device, a person or service that holds it, and a financial record of what it cost. Practices that strengthen that link come first. Practices that produce attractive dashboards come later, because a dashboard built on an unlinked register will look finished and mislead the people who rely on it.

Practices ranked by what they depend on, with the way each one goes wrong

The table gives a working order. The middle column is the evidence that tells you a practice is genuinely operating, rather than documented and ignored. The right-hand column is where the practice tends to backfire when it is introduced without its prerequisites.

The sequence that makes the practices stick

A practice that is written but not operated is worse than none, because it creates a false sense of control. The sequence below is designed so that each practice gets a working owner and a measure before the next one begins.

1. Name an owner for each practice in the table, using a person’s role rather than a shared group. A configuration ownership model can be adapted to hardware if you need a pattern.
2. Define the evidence column for each practice in writing, so that operating and not operating are distinguishable.
3. Switch on the practices that the others depend on: receiving, custodian and leaver linkage, and the finance tie-out. For the stages behind those links, see the asset lifecycle article.
4. Review the evidence after a set working cycle. If it is weak, fix the prerequisite rather than adding a new practice.
5. Add the reporting and the lifecycle forecasts once the underlying records are trusted by the people who use them.

When a practice should be dropped rather than improved

Some practices are worth dropping. A mandatory weekly physical count across a large estate often produces a spreadsheet nobody reconciles, while a risk-based sample of high-value or high-exposure devices gives the same assurance for less effort. Likewise, a requirement to record every peripheral can bury the register in low-value items. The test is whether a practice changes a decision someone makes. If it does not, it is overhead, and the owner should say so and remove it.

Reading the register as an operating system, not a report

The clearest sign that the practices are working is that people use the register to make decisions without asking the owner first. A service desk agent finds the custodian of a device during a call. A finance analyst checks the cost before approving a repair. A security team lists devices past their support date before a patch cycle. For the device classes behind those lookups, the CI class explainer is the reference. When those routine questions still come to one person, the practices exist on paper but have not reached the people who needed them, and the next step is usually to make the register easier to query rather than to add another policy.

Is a single shared mailbox acceptable as a custodian?

For shared lab or meeting room equipment, a team owner is reasonable, provided a named person within that team is accountable for it. A mailbox on its own answers the question of who owns the device without answering who is responsible for it on a given day, and that gap is what reviewers tend to press on.

How much of the lifecycle should be modeled for every asset class?

Only the stages that trigger a decision. For most estates that means purchase, deployment, end of warranty, end of support and retirement. Stages that nobody acts on, such as minor intermediate states, add entries without adding control.

Should hardware practices follow the same rules as software?

The principles carry across, but the evidence differs. Software is often evidenced by entitlements and usage, while hardware is evidenced by physical custody and disposal. Use the same owner and evidence structure for both, and let the evidence itself differ.

What is the first practice to fix when the register is badly wrong?

Receiving. Every error that enters at receiving spreads into assignment, reporting and disposal, and fixing those downstream steps first only moves the errors around.

Hardware asset discovery and the hardware asset record hold different facts

Discovery finds devices that respond on the network and records them as configuration items. The hardware asset record, held in the alm_hardware table, carries ownership, cost and lifecycle state. The two are typically joined by serial number. Discover what is connected, register what is owned, and reconcile the difference.

Each side has a blind spot, and the practices only work when the team knows both. Discovery cannot see a device that is powered off, in a store cupboard, in transit or never connected, which covers new stock, spares, docks and monitors. The register cannot say where a device is running or whether it is still alive. Only comparing the two shows the gap.

A routine that keeps the two honest runs in four steps:

• Match discovered devices to asset records on serial number, and list every device that fails to match.
• List every registered device that discovery has not seen within an agreed period.
• Give each exception to a named owner with a working deadline, rather than leaving a shared queue.
• Review both lists on a fixed cycle, and treat a growing list as a sign that a prerequisite practice has stopped.

The discovery overview explains what the scans can reach, and the plain-language hardware asset guide covers the register side.

What is the difference between a configuration item and a hardware asset?

A configuration item describes a thing the platform needs to understand technically, such as a server and its relationships. A hardware asset describes the same device as something owned, with a cost, a custodian and a lifecycle. One physical device often has both records, and linking them is the point of reconciliation.

Can discovery replace a physical audit?

No. Discovery only reports what answers on the network. A risk-based physical check of high-value or high-exposure devices still finds the stored, lost and unconnected ones. The asset lifecycle service describes how the two fit together.

Which field should match a discovered device to its asset record?

Serial number is the usual choice, because it is unique to the device and survives a change of owner or location. Asset tag works where tags are applied and scanned consistently. Matching on name or address tends to break as devices are renamed or reassigned.