All articles

Lifecycle · IT

Decommissioning without guesswork

Why "last seen more than 90 days ago" is a poor test for a retired asset, and how per-source evidence makes decommissioning safe and auditable.

LELumen Edge TeamAugust 11, 2026 · 4 min read

Every inventory accumulates ghosts: computer objects for laptops that were recycled two years ago, EDR entries for servers rebuilt under new names, cloud VMs long since deleted. They inflate asset counts, consume licenses, widen audit scope and generate noise in every report.

The usual fix is a clean-up script with a simple rule: if an asset has not been seen for more than 90 days, delete it. It is quick, it is easy to explain, and it is wrong more often than people expect.

Why "last seen > 90 days" fails

The rule assumes that "not seen" means "gone". That is only true if something was actually looking.

Sources that did not run

If the network scan responsible for a subnet was paused for a quarter, every host on that subnet will look stale. Nothing has been decommissioned; the evidence simply was not collected.

Assets that are legitimately quiet

Laptops sit in drawers during parental leave and long sabbaticals. Disaster-recovery servers are powered on twice a year. Seasonal equipment comes back every winter. A purely time-based rule deletes all of them.

Sources that never saw the asset

A "last seen" timestamp usually comes from one tool. If that tool never covered the asset (an EDR that was never installed on a server, say), its silence says nothing about whether the server still exists.

Lost history

Deletion removes the record and its history together. When the asset reappears, it comes back as a stranger, and when an auditor asks what happened to it, there is nothing to show.

A better model: per-source verdicts

Instead of one timestamp, consider each source that has ever reported the asset and ask a more careful question of each: has this source looked recently enough, often enough, and failed to see it?

For every asset and every relevant source, the answer falls into one of a few verdicts:

Verdict Meaning
Seen The source has run and still sees the asset.
Not seen The source has run enough times recently and no longer sees it.
Not run recently The source has not run within the evaluation window, so its silence is not evidence.
Insufficient runs The source has run, but not often enough to be confident.
No evidence The source never reported this asset, so it has no opinion.

Only Not seen counts as evidence of absence. Everything else means "we do not know yet".

Require every applicable source to agree

The rule then becomes: an asset is decommissioned only when every source that applies to it reports Not seen. If any source still sees it, it is active. If some sources have not run, or have not run often enough, it is awaiting evidence rather than retired.

This has three useful properties.

  1. It is conservative. A single paused integration cannot cause a mass deletion.
  2. It is explainable. For any decision you can show the verdict of each source.
  3. It degrades gracefully. Assets with no usable evidence are reported as insufficient data or not evaluable instead of being silently kept or removed.

Tuning the evaluation

A few settings make the model fit real estates:

  • Evaluation window: how far back to look for runs.
  • Minimum runs: how many times a source must have looked before its silence counts.
  • Per-integration exclusions: sources that should not vote, such as one that only covers a subset of assets.

Mark, restore, delete, with a trail

Reaching a verdict is half the job. The other half is acting on it in a way you can defend later.

  • Mark the asset as decommissioned, keeping the record and its history.
  • Restore it if it turns out to be alive; the trail shows why it was marked in the first place.
  • Hard delete only once you are satisfied, and only deliberately.

Every action is recorded in an audit log: who, when, which assets and on what evidence. That log is exactly what an auditor asking "what happened to this server?" wants to see, and it is the difference between a register that shrinks mysteriously and one that is managed.

What changes in practice

Teams that move from time-based clean-ups to evidence-based decommissioning tend to notice three things:

  • Fewer accidental deletions of live but quiet assets.
  • Faster clean-ups, because the confident cases can be processed in bulk while the uncertain ones are clearly separated.
  • Better audit conversations, because retirement becomes a documented decision rather than an absence.

It also tightens other processes. License pools stop paying for ghosts, coverage figures stop counting machines that no longer exist, and asset counts become something you can quote without caveats.

Getting started

You do not need to change everything at once. Start with one asset type (Windows workstations, for example) where directory, EDR and MDM data overlap well. Review the Decommissioned and Awaiting evidence lists for a few cycles before acting, and tune the evaluation window to match how often your sources run.

Lumen Edge includes this evaluation as its Decommissioning module, with per-source verdicts, exclusions and a full action log. If your inventory is carrying more ghosts than you would like, book a demo and we will show you what the evidence says about yours.

See your real asset inventory in 30 minutes.

Bring one question you cannot answer today: how many servers have no EDR, who owns a subnet, which licenses are idle. We will answer it on a live platform.

Book a demo

SaaS or on-prem · no endpoint agents · every module included