This post walks through every tool Hardware Asset Management (HAM) gives you to fill in missing hardware lifecycle dates: the end-of-sale, end-of-support, and end-of-life dates that flag when an asset is becoming a risk. Manufacturers do not always publish them, so HAM layers a few mechanisms: automatic ones (approximated dates from ServiceNow’s content library, and calculated templates you build per asset class: servers, laptops, network gear), and a precision override (custom dates entered straight on the Hardware Model for negotiated contracts or internal policy).
Hardware has an end date whether or not anyone has written it down: end of sale, end of support, end of life. Those dates are what tell you which assets are secretly turning into risk. Here is the full set of mechanisms, in the order you would typically apply them.
A note up front: HAM has fewer moving parts than its software cousin, Software Asset Management (SAM). There is no add-on mechanism and no relationship table to manage, and that is product reality, not a gap. On the hardware side, inheritance is simply built in: lifecycle dates live on the Hardware Model, and every asset tied to that model picks them up automatically. More on that at the end.
Start with the automatic layers
Two layers do most of the work without per-model configuration.
Approximated Lifecycle is content ServiceNow’s Content Team maintains for you. When a manufacturer has not published dates (or has published only some of the phases), the team supplies a derived date paired with a code that explains it. The important thing: approximation is already on by default for many models. The work is not to build it. It is to read it. Pull the lifecycle code columns into your Hardware Model Lifecycles report, count coded records as covered, and aim your backlog at the models that have neither a date nor a code.
Calculated Lifecycle Templates fill what is left. Where the Content Library has no actionable date, a template lets you supply one with a formula. And here HAM deliberately parts ways with SAM. Software averages key off the publisher; hardware does not. A hardware estate is shaped by model class and refresh strategy: servers, laptops, network gear, and printers all live for different lengths of time, and refresh policy is usually set per asset class, not per manufacturer. So HAM uses named templates instead: an admin builds “Enterprise Server” or “Knowledge Worker Laptop,” defines how many months each phase runs from the GA date, and assigns the template to specific models. The phases populate automatically, tagged “Calculated” so they never pass for manufacturer values, and they only fill phases that do not already have authoritative data. The template is a fallback, not an override.
Quick tip: the best templates are not built by the HAM team alone. The teams who own each asset class (platform for servers, end-user computing for laptops, networking for switches) know how long their kit actually stays in production and how much risk the organization will carry past the manufacturer’s support window. A short working session with each produces templates that hold up, and earns alignment from the people who will have to act on the dates.
Then the precision override: Custom Lifecycle
When the automatic layers do not give the right answer, Custom Lifecycle takes over. It is for dates that are simply true for you: a negotiated support contract, an internal policy decision (“we are retiring this switch generation by end of FY regardless of the manufacturer”), or a research source you stand behind. You create the record right on the Hardware Model, under the Hardware Model Lifecycle tab: pick a phase, set the date, save. It is tagged “Internal” and takes precedence over anything from the content library or a template. Because hardware stores one record per phase, a single model can happily carry a manufacturer GA date, a calculated EOL from its template, and a custom End of Support from a negotiated extension, each coexisting, each labeled with where it came from.
This is also where hardware extended support lands. There is no standardized add-on product with its own published dates the way software has; per-contract extensions go in as Custom records on the relevant model.
How it all stacks
Manufacturer dates apply first, approximation fills the gaps, calculated templates fill what is still left, and custom records override the lot when contract or policy says so. And then the part that needs no configuration at all: because lifecycle lives on the Hardware Model, every asset associated with that model inherits the dates by structure. No relationship table, no per-asset work. Define lifecycle once, on the right model, and it reaches everything underneath it. Layer the mechanisms in that order and the estate ends up with something rare: complete coverage, and a clear answer for every date about where it came from.
Where to go next
Essential references
KB2726382 — Hardware Lifecycle Codes reference
© 2026 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks of ServiceNow, Inc.
