Security teams should require a formal retirement process that disables access, wipes data, removes credentials, and confirms the device is no longer trusted by the network. IoT devices often persist longer than expected because they sit inside business processes, so end of life has to be treated as an access event as well as an asset event.
Why This Matters for Security Teams
When IoT devices reach end of life, the security problem is not just disposal. It is the moment a live identity, network trust relationship, and often a bundle of embedded credentials must be terminated cleanly. Treating the device as a retired asset while leaving certificates, tokens, or admin access in place creates a lingering entry point that can be reused, abused, or rediscovered later.
This is why end of life must be handled as an access event. A device that is no longer supported by the manufacturer may also no longer receive security patches, attestation updates, or trustworthy firmware validation. That means it can become a durable weak link inside segmented networks, OT environments, and remote deployments where replacement cycles are slow.
Current guidance aligns this problem with broader identity hygiene, not just asset management. The NIST Cybersecurity Framework 2.0 emphasizes asset governance, protection, and recovery as linked outcomes, while NHIMG research on the lifecycle of non-human identities shows how often credentials remain valid long after a system should have been decommissioned. In practice, many security teams discover the retirement gap only after a forgotten device is still trusted by the network.
How It Works in Practice
Effective IoT end-of-life handling starts with a retirement workflow that is triggered before the device is physically removed. The workflow should identify every identity and trust artifact bound to the device, then revoke them in a controlled order. That usually includes certificates, API keys, mutual TLS trust anchors, cached tokens, service account links, and any remote support channels that still allow command execution.
Security teams should require four actions at minimum:
- Disable network access at the policy layer, not only at the switch or firewall.
- Revoke or expire all device credentials and certificates.
- Wipe local data and configuration, including any stored secrets.
- Confirm the device is removed from inventories, monitoring, CMDB records, and trust stores.
Where possible, the retirement process should be automated through lifecycle controls so that decommissioning cannot be skipped during rushed replacements. That is especially important for devices embedded in business processes, where operations teams may want to leave them powered on as a fallback. The problem is that fallback trust becomes permanent if no one proves the device is no longer accepted by authentication systems. NHIMG’s Schneider Electric credentials breach illustrates how exposed credentials and persistent access paths can outlive the intended use of the system they protect.
For mature environments, the better model is to retire the device’s identity first, then handle the physical asset. That includes verifying that downstream integrations, dashboards, remote maintenance services, and vendor support accounts no longer reference the device. These controls tend to break down in distributed industrial and field environments because ownership is split across operations, facilities, and security, and no single team can prove when trust has fully ended.
Common Variations and Edge Cases
Tighter retirement controls often increase operational overhead, requiring organisations to balance stronger revocation with downtime risk and replacement cost. That tradeoff becomes visible when IoT devices support safety systems, production lines, medical environments, or remote sites where a simple shutdown can disrupt essential services.
Best practice is evolving for devices that cannot be wiped, fully patched, or cleanly decommissioned because the vendor has exited support. In those cases, security teams should treat the device as permanently untrusted, isolate it to a narrow segment, and remove any ability to authenticate beyond the minimum operational need. There is no universal standard for this yet, but current guidance suggests that an unsupported device should not retain standing trust simply because it is still powered on.
A second edge case is shared infrastructure, where one appliance supports multiple functions or teams. Retirement then becomes a dependency problem, not a single-asset task. Teams should validate that no other workload depends on the device before revoking access, but that validation should never delay credential removal once the retirement decision is final. The practical rule is simple: if the device cannot be proven trustworthy, it should not remain an active identity in the environment.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | End-of-life devices must lose access before disposal. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers credential rotation and revocation for non-human identities. |
| NIST AI RMF | Lifecycle governance applies to systems with persistent machine identity. |
Remove device access at the policy layer before physical retirement is complete.
Related resources from NHI Mgmt Group
- How should security teams prevent unwanted persistence in Active Directory and Entra ID?
- How do security teams know if lifecycle automation is actually working?
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- How should security teams handle legacy network devices in NHI governance?
