Who is accountable when an IoT device with stale credentials is used in an attack?

Why This Matters for Security Teams

Stale credentials on an IoT device are not just an asset hygiene issue, they are a trust-management failure. Once a device can still authenticate after it should have been rotated, disabled, or re-enrolled, the organisation has a live control gap that can be turned into lateral movement, data exposure, or botnet activity. That is why accountability usually follows the party that owns onboarding, credential lifecycle, and revocation, not the manufacturer alone.

This is consistent with the control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, which expects access and system integrity controls to be assigned, enforced, and evidenced. For IoT specifically, the failure often sits at the boundary between IT, OT, and procurement, where ownership becomes ambiguous after deployment. If no team owns certificate rotation, secret storage, or decommissioning, the device can remain trusted long after it should have been retired.

In practice, many security teams encounter this only after the device has already been used as an initial foothold or command-and-control node, rather than through intentional credential governance.

How It Works in Practice

Accountability turns on which organisation controls the active trust relationship at the time of use. If the device still presents valid credentials, then whoever is responsible for issuing, rotating, storing, or revoking those secrets is usually expected to explain why the device remained trusted. That includes the operational owner, the platform team, and sometimes the integrator if they manage device enrollment at scale. Hardware vendors may share design responsibility, but they rarely own the live risk once the device is deployed.

Practically, teams should be able to show four things: who enrolled the device, what credential type it uses, how renewal or rotation is enforced, and how revocation is triggered when a device is lost, retired, or compromised. This is where identity governance intersects with IoT and, increasingly, with OWASP Non-Human Identity Top 10 guidance, because many IoT devices behave like non-human identities with long-lived secrets and weak lifecycle controls.

• Inventory the device and associate it to a named business owner.
• Use unique credentials per device, not shared defaults or fleet-wide passwords.
• Prefer certificate-based authentication with defined expiration and revocation.
• Log enrollment, rotation, failure, and decommission events for audit evidence.
• Revoke access automatically when a device is retired or fails attestation.

For incident response, map suspicious device activity to known techniques such as those in the MITRE ATT&CK Enterprise Matrix and confirm whether the device was acting as a pivot, a persistence mechanism, or a beacon. These controls tend to break down when IoT fleets are unmanaged across subsidiaries or integrators because the trust owner, credential issuer, and asset owner are not the same party.

Common Variations and Edge Cases

Tighter credential controls often increase operational overhead, requiring organisations to balance device uptime against revocation speed and maintenance complexity. That tradeoff becomes visible in brownfield environments, where older devices cannot support modern rotation or certificate-based identity without firmware changes.

There is no universal standard for every IoT deployment, but current guidance suggests that accountability shifts with operational control, not product branding. If a managed service provider runs the device estate, they may share accountability for lifecycle controls; if a customer changes credentials and policy, the customer owns the live trust decision. In regulated environments, auditors will often ask for the assignment of control ownership, not just vendor documentation.

Edge cases also matter. Shared credentials across a fleet blur responsibility and make it harder to prove which device was abused. Devices that cannot support revocation should be isolated, segmented, or replaced. Where IoT devices support remote management or AI-driven automation, the same logic applies to the controlling identity and any agentic tooling that can issue commands. For broader threat context, organisations should watch CISA cyber threat advisories and align response playbooks to observed attacker behaviour rather than assuming the manufacturer will remediate a deployed compromise.

Related resources from NHI Mgmt Group

• Who is accountable when exposed credentials are used in an attack?
• Who is accountable when anonymous credentials are used in production?
• Who is accountable when stale NHI credentials survive a breach response?
• Who is accountable when compromised credentials are used to trigger ransomware?