MNOs should pair remote unsubscribe actions with a permanent cleanup step that stops disconnected devices from repeatedly retrying network access. If devices remain powered, they can continue sending connection requests for long periods and consume bandwidth, battery, and operational capacity. The practical control is to use over-the-air management for end-of-life actions, while putting approval safeguards around irreversible changes.
Why disconnected IoT devices can keep generating load after service ends
An unsubscribed device is not automatically a dead device. If it is still powered and still knows how to reach the network, it may continue retrying attachment, authentication, or telemetry submission long after the subscription or service contract has ended. That retry behaviour creates avoidable load, especially when many devices are involved, and it can keep consuming radio, backend, and operational capacity.
What matters operationally is the difference between revoking service and removing the device’s ability to keep asking for service. A clean unsubscribe workflow must include a state change on the device or its management path, not just a billing or provisioning update.
What the cleanup step has to do, not just what the unsubscribe request means
The practical control is permanent cleanup. For many fleets, that means an over-the-air management action that disables the device’s ability to reconnect, removes or invalidates the relevant credentials or tokens, and records the device as end-of-life so it does not re-enter normal retry logic. The goal is to stop repetitive signalling, not merely to mark the account inactive.
This is especially important for constrained devices that behave badly when they lose service context. Some will keep attempting network access in predictable intervals, while others may fall back to noisy retry loops that are invisible until scale makes them expensive. A termination process should therefore be designed as an operational shutdown, not only a commercial offboarding event.
Device and IoT Identity Guide is useful here because device identity, attestation, and lifecycle control are what make a final state change durable instead of temporary. Where devices are still trusted by the network after the contract ends, they can continue to behave like valid endpoints even when they should no longer exist in service.
How to make end-of-life actions safe enough for operations
Because the cleanup is irreversible or difficult to reverse, it should not be triggered by a casual request or a loosely verified support action. The right pattern is approval-gated execution with clear ownership, so the operator can distinguish a routine disconnect from a true decommissioning event. That matters when the same fleet supports staged service suspension, replacement, recycling, or resale.
Over-the-air control is the right channel because it scales across remote and distributed devices, but it should be paired with evidence that the device actually stopped trying to reconnect. If the device remains active after the unsubscribe event, the workflow has failed regardless of whether the billing system says the service is closed.
HPE Aruba Hard-Coded Secrets is a reminder that embedded access material can outlive the intended service relationship and keep enabling device behaviour when it should have been neutralised. In practice, end-of-life control has to address both the device state and the secret material that lets it keep negotiating access.
Where MNOs should watch for hidden cost and control failures
The main failure mode is partial unsubscribe. If the commercial record is updated but the device is not cleaned up, the network can still see repeated access attempts, which creates unnecessary signalling and operational noise. At small scale that looks like nuisance traffic; at larger scale it becomes a capacity and support problem because the same devices keep returning to the network path.
CIS Controls v8 supports the broader operational idea here: maintain asset visibility, remove access promptly when it is no longer needed, and harden the lifecycle of managed endpoints so stale devices do not remain able to consume services. For MNOs, the relevant question is whether the decommissioned device still has any live path back into 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 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Cleanup must revoke or invalidate device auth material after unsubscribe. |
| IA-9 — Service Identification and Authentication | Devices and services must stop authenticating once service ends. | |
| Recommendation — Invalidate credentials or tokens so disconnected devices cannot keep reauthenticating. Require service-to-service auth controls that can be cleanly terminated at end of life. | ||
| CIS Controls v8 | CIS-5 — Account Management | Unsubscribed devices need prompt removal of access paths and stale accounts. |
| Recommendation — Remove inactive device access promptly and verify deprovisioning completes. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | End-of-service cleanup depends on timely removal of rights and access paths. |
| Recommendation — Revoke device access rights when the service relationship ends. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The core issue is failing to fully offboard an identity-bearing device. |
| Recommendation — Fully offboard devices so they cannot keep using network access after service ends. | ||
Practitioner Guidance
What to prioritise: Treat unsubscribe as a lifecycle termination workflow, not a customer-service action. The first priority is to stop repeat network access, then confirm the device cannot re-establish service through a leftover credential, profile, or management channel.
What to verify: Confirm that the post-unsubscribe device state is observable in your management system and in network telemetry. If the device still appears in signalling, attach attempts, or backend retries after the end-of-life action, the cleanup is incomplete.
Decision rule: If the device can still authenticate or request service after unsubscribe, prioritise disabling that path over waiting to see whether the device eventually goes quiet on its own. The network should not depend on passive decay to enforce a finished service relationship.
Practitioner takeaway: The durable fix is to couple reversible business offboarding with irreversible technical cleanup, because only the technical step stops a powered device from continuing to consume network resources.
Related resources from NHI Mgmt Group
- Why do AI agents and service accounts in Claude increase enterprise risk when they keep operating after their creator has left?
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- Why do exposed secrets keep creating risk after they are detected?
- What breaks when organisations keep using Java after OpenJDK support ends?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
