Who is accountable when a forgotten device becomes criminal infrastructure?

Why This Matters for Security Teams

A forgotten device does not stay forgotten once it remains reachable, trusted, or able to authenticate. When that asset becomes criminal infrastructure, the problem is no longer only asset inventory; it becomes a control failure across ownership, credential lifecycle, and network containment. NIST frames these duties through the security outcomes in NIST Cybersecurity Framework 2.0 and the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, where accountability is traceable to specific responsibilities rather than assumed by the organisation as a whole.

The common mistake is treating the device as a simple loss or retirement issue. In practice, the risk persists when credentials remain valid, remote management is still enabled, logging is thin, or the device can pivot into a flatter network segment. That is why accountability often spans operations, network security, and identity governance at the same time. If ownership was never assigned, or decommissioning was never formally completed, the gap is itself evidence of weak control design. In practice, many security teams encounter this only after abuse telemetry, outbound scanning, or law enforcement notice reveals that the device was still active long after it should have been removed.

How It Works in Practice

Accountability should follow the control points that allowed the device to remain usable. Operations usually owns the physical asset, network security owns reachability and segmentation, and identity governance owns the credentials, certificates, and administrative entitlements that let the device operate. The right question is not only “who lost it?” but “who still allowed it to function?”

A practical response usually starts with three checks:

• Confirm whether the device was formally assigned, tracked, and retired through an asset lifecycle process.
• Review whether any active credentials, API keys, certificates, VPN profiles, or remote administration paths were left in place.
• Determine whether segmentation, EDR, or access policy would have limited lateral movement if the device was misused.

Where the device had privileged access, accountability also touches PAM and identity governance, because standing privilege can turn a forgotten endpoint into a durable foothold. Where certificates or machine identities were used, the question becomes whether revocation, rotation, and kill-switch procedures were defined before disposal. Guidance from NIST SP 800-53 makes this measurable through access control, audit, configuration management, and media sanitization expectations, and CISA guidance on asset visibility reinforces that security cannot protect what it cannot account for. The operational reality is that a device is only “gone” when its identity, network trust, and management channels are all removed, not when the hardware leaves the building.

These controls tend to break down in hybrid and third-party managed environments because no single team owns the full decommissioning chain, making gaps in revocation and segmentation easy to miss.

Common Variations and Edge Cases

Tighter device control often increases operational overhead, requiring organisations to balance speed of retirement against the need for provable closure. That tradeoff matters because not every forgotten device is equally dangerous, but best practice is evolving toward treating any still-authenticating asset as high risk until proven otherwise.

Edge cases usually involve shared responsibility. If a managed service provider administered the device, accountability may be split across the internal owner, the supplier, and the identity platform team. If the device held a certificate rather than a human login, the issue may look like infrastructure hygiene until the certificate is abused as a machine identity. If the asset was an IoT or embedded system, patching and decommissioning may be constrained by vendor support, but that does not remove the need for containment and revocation. Where criminal use is suspected, organisations should preserve logs, identify the last known owner, and document which control failed first rather than trying to assign blame before the evidence is complete.

There is no universal standard for how to allocate legal liability in every jurisdiction, but from an operational security perspective, accountability should map to the team that owned the asset, the team that governed access, and the team that failed to enforce retirement. That distinction becomes especially important when audit evidence is needed to show whether the device was merely misplaced or was still under active trust at the time of abuse.

Related resources from NHI Mgmt Group

• Who is accountable when a connected device becomes an entry point for attackers?
• Who is accountable when a shared clinical device exposes patient data?
• Who is accountable when an accepted vulnerability exception later becomes exploitable through AI?
• Who is accountable when a management portal allows relay into certificate infrastructure?