Provisioning gets all the attention in device management, and retirement gets almost none. Then a year later someone finds a decommissioned gateway on an auction site still carrying valid credentials, or a finance review discovers cellular plans being paid for devices that went to the scrap bin long ago. Retirement is a security task, a cost task and a data task at once.

Why It Goes Wrong

Devices leave service in messy ways. Some are replaced in a planned upgrade, some fail and are swapped by a technician who is more worried about restoring service than updating a registry, and some are simply abandoned when a customer leaves. The cloud-side record usually survives all of these, which is the problem: the registry says the device exists, the credentials still work, and nobody is looking.

In practice, the fix is to make decommissioning a defined state in your device lifecycle with an owner, not a cleanup chore someone gets to eventually.

Decide What “Retired” Means

Agree on lifecycle states before you need them. A simple set might be: active, suspended, decommissioned, and archived. Suspended is the useful one. It means the device is blocked from the platform but nothing is deleted, so you can reverse a mistaken retirement quickly.

Moving straight from active to deleted is risky. Deleted records remove the trail you need when someone asks, months later, which device sent a particular reading or why a unit disappeared.

What to Revoke

The most important step is making sure the device can no longer act as itself.

Credentials. Revoke or disable the device certificate or key on the platform. Removing the registry entry alone may not be enough on every platform, so check how your provider handles a device whose credentials are still cryptographically valid.

Permissions. Remove it from any groups, policies and routing rules that referenced it individually.

Application access. If the device had accounts or tokens with third-party services, such as a mapping or messaging service, revoke those separately.

What to Do With the Data

Two kinds of data matter: what is on the device and what is in your cloud.

On the device, assume anything stored may be recoverable unless you have wiped it properly. Wi-Fi credentials, API keys, customer identifiers and logs are common leftovers. If the hardware supports a secure erase or factory reset, use it, and prefer devices that keep secrets in protected storage. If the device is physically destroyed, record that.

In the cloud, decide retention up front. Historical telemetry may need to be kept for analysis, contracts or regulation, and may need to be deleted for privacy reasons, especially where readings relate to identifiable people or premises. Requirements vary by jurisdiction and contract, so involve whoever handles legal and compliance questions.

Cost Leakage

Connectivity is the quiet cost. Cellular lines, SIMs and data plans often continue billing until someone cancels or suspends them, and the person who retires hardware is rarely the person who owns the carrier account.

Tie the two together: your decommission process should include an explicit step to suspend or cancel the connectivity subscription and confirm it. The same applies to per-device licences, certificates from paid authorities, and monitoring seats.

A Retirement Checklist

Step	Why it matters	Done when
Move device to suspended state	Blocks traffic, keeps the record	Platform shows it as blocked
Revoke credentials	Prevents impersonation	Certificate or key marked invalid
Remove from groups and rules	Avoids stale automation	No policies reference it
Wipe or destroy storage	Prevents data recovery	Wipe or destruction recorded
Suspend connectivity plan	Stops ongoing charges	Carrier confirms status
Apply data retention decision	Meets contract and privacy needs	Data archived or deleted as agreed
Close the asset record	Keeps inventory accurate	Final state and date logged

A Hypothetical Example

A facilities operator replaces a batch of building sensors during a hardware refresh. The installers swap units and drop the old ones into a box. Months later, an audit compares the platform registry against the asset list and finds a number of old units still listed as active, some still holding valid certificates, and still on paid data plans.

Nothing malicious had happened, but the cleanup took longer than it should have. The operator then added a rule: an installation job cannot be closed until the old device’s serial number is marked decommissioned in the platform and the connectivity subscription has a suspension reference. A task that depended on memory became a gated step.

Handling Failures and Disappearances

Some devices cannot be retired cleanly because they are gone: stolen, lost, or in a customer site you cannot access. For these, revoke credentials remotely at once, mark the device as lost, and monitor for any attempts to connect. A revoked credential that keeps trying to connect is a useful signal that the device is still out there.

If a device is returned for refurbishment, treat it as a new provisioning event with fresh credentials, not as a reactivation of the old identity.

Frequently Asked Questions

Should I delete a decommissioned device from the registry? Not immediately. Keep it in a retired state for the period your audit and support needs require, then archive or delete according to your retention policy.

Is a factory reset enough to protect data on a device? It depends on the hardware and how the device stores secrets. For anything holding sensitive material, check the manufacturer’s documentation and consider physical destruction for high-risk units.

Who should own decommissioning? A named team, usually whoever owns the device lifecycle, with clear hand-offs to finance and security. Shared responsibility tends to mean nobody does it.

What about devices that fail in the field? Treat a swap as a decommission of the old unit and a provisioning of the new one. Do not let the replacement inherit the old identity.

How do I find devices that should have been retired? Compare the platform registry, the asset list and the connectivity billing records. Mismatches between the three are your candidates.

Next Step

Pull your three lists: platform registry, asset inventory and carrier billing. Reconcile them this week, and write down who owns each discrepancy. Then add the checklist above to your installation and replacement workflow.