Remove it from the network, revoke its credentials, wipe or reset it according to policy, and update the inventory so the device no longer counts as a trusted access path. Offboarding matters because forgotten devices can keep old trust and network reach long after their purpose has ended.
Why This Matters for Security Teams
IoT offboarding is not just asset hygiene. An unused device can still hold network trust, cached credentials, certificate material, or a management channel that attackers can abuse long after the business no longer needs it. That is why current guidance treats decommissioning as a security event, not a facilities task. It also aligns with broader identity control expectations in the NIST Cybersecurity Framework 2.0 and with the lifecycle emphasis in NHI governance.
NHI Mgmt Group notes in the Ultimate Guide to NHIs that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why forgotten machine access so often persists in production. The same problem shows up in device fleets: when offboarding is incomplete, inventory and reality diverge, and defenders lose track of what can still authenticate, reach subnets, or trigger automation. In practice, many security teams discover the problem only after a supposedly retired device is still present in logs, network scans, or incident response.
How It Works in Practice
The safest offboarding process follows a sequence: confirm the device is no longer required, identify every identity and secret tied to it, remove connectivity, revoke trust, and then erase or reset the hardware according to policy. For IoT, that usually means disabling certificates, API keys, tokens, VPN profiles, local admin accounts, and any embedded management credentials before the device is physically reused, resold, returned, or discarded.
In mature environments, teams map the device to an inventory record, then validate what trust relationships it has with gateways, brokers, cloud services, and operational systems. That inventory step matters because offboarding fails when teams revoke only one credential while leaving another path active. The same lifecycle discipline appears in NHI lifecycle guidance, which frames removal, rotation, and visibility as linked controls rather than isolated tasks.
- Revoke device certificates, tokens, and service credentials at the source of issuance.
- Disable remote administration, broker access, and any persistent VPN or tunnel capability.
- Perform a factory reset or secure wipe where the device supports it, following policy and retention requirements.
- Remove the device from CMDB, asset inventory, MDM, EDR, and access review records.
- Check logs and policy engines for residual use after shutdown to confirm the trust path is gone.
Where device identity is bound to workload access, teams should also verify that downstream systems reject the old identity after revocation. That is consistent with NIST Cybersecurity Framework 2.0 expectations for access control and asset management. These controls tend to break down when IoT devices are shared across multiple business units because ownership is unclear and no single team can fully revoke every linked trust path.
Common Variations and Edge Cases
Tighter offboarding often increases operational overhead, requiring organisations to balance security assurance against device criticality, uptime, and disposal logistics. That tradeoff is especially real in plants, hospitals, and remote sites where a device may be physically inaccessible or where shutdown windows are limited. Guidance suggests prioritising devices with privileged connectivity, cloud reach, or safety impact first.
There is no universal standard for every IoT reset scenario. Some devices support secure wipe commands, others only support credential revocation, and legacy hardware may require network quarantine instead of true erasure. In regulated environments, the right answer may also include retention of logs, proof of destruction, or chain-of-custody records. If the device was exposed in a breach, the Schneider Electric credentials breach is a useful reminder that machine trust can outlive the original deployment if revocation is incomplete.
Best practice is evolving, but the current direction is clear: treat decommissioned IoT devices as former identities, not merely retired assets. Any device that can still authenticate, connect, or be reactivated without review should be considered a lingering access path until proven otherwise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Offboarding requires revoking device credentials and removing stale trust. |
| NIST CSF 2.0 | PR.AC-1 | Device decommissioning is an access control and asset management issue. |
| NIST CSF 2.0 | ID.AM-1 | Accurate asset inventory is essential to confirm a device is truly offboarded. |
Remove retired IoT devices from inventories and disable their access paths immediately.
