Accountability should sit with the organisation that owns the device identity lifecycle, even when manufacturers, carriers, and support partners all touch the environment. Clear ownership is needed for approvals, exceptions, and revocation, otherwise no one can reliably answer who changed what and why.
Why This Matters for Security Teams
device identity changes in telecom and IoT are not simple admin updates. They affect which device can authenticate, what network or service it can reach, and whether revocation is actually enforceable. When ownership is unclear, manufacturers, carriers, MSPs, and internal platform teams can all touch the same identity without a clean approval path. That creates audit gaps, weak exception handling, and delayed offboarding. NHI Mgmt Group has shown how often identity controls fail in practice, including cases where only a small share of organisations have full visibility into service accounts in the Ultimate Guide to NHIs.
The core issue is accountability, not just administration. For telecom fleets, SIM, eSIM, modem, and device certificates can all change across the lifecycle. For IoT, firmware updates, certificate renewal, and device re-enrolment can each alter identity state. NIST control guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls makes it clear that access and identity changes need defined responsibility, but the hard part is assigning that responsibility across organisations and vendors. In practice, many security teams only discover ownership ambiguity after a compromised device keeps working because no one had authority to revoke it.
How It Works in Practice
The cleanest model is to assign accountability to the organisation that owns the device identity lifecycle, even if other parties execute parts of the workflow. That means one named business owner, one technical control owner, and one documented path for approval, rollback, and revocation. Carriers, OEMs, and support partners may initiate change requests, but they should not be the final authority unless contractually delegated. Current guidance suggests treating this like a controlled NHI process: every identity-changing action should be tied to a ticket, approver, timestamp, and device-specific evidence.
Operationally, teams should separate three layers:
Policy owner: defines who can approve device identity changes and under what conditions.
System owner: manages the identity platform, certificate authority, SIM lifecycle, or enrolment service.
Execution actor: performs the change, whether internal staff, carrier tooling, or a managed service partner.
This division supports traceability without weakening accountability. It also aligns with the broader NHI lifecycle issues documented in Top 10 NHI Issues, where weak offboarding and poor rotation are recurring failure modes. For telecom and IoT, that means logging who requested the change, which device identity was altered, what trust anchor changed, and when revocation takes effect. Zero Trust thinking helps here, but only when identity state is continuously verified rather than assumed stable after enrolment. These controls tend to break down when devices operate in offline, roaming, or intermittently managed environments because revocation and attestation can lag behind the real device state.
Common Variations and Edge Cases
Tighter identity governance often increases operational friction, requiring organisations to balance revocation speed against field reliability. That tradeoff is especially visible in telecom roaming, industrial IoT, and carrier-managed fleets where emergency support may need temporary override access. Best practice is evolving, and there is no universal standard for every device class yet, so the key is to predefine exception handling before incidents occur.
One common edge case is outsourced device management. If a carrier or systems integrator controls certificate issuance or SIM provisioning, accountability still should not disappear into the vendor chain. The organisation consuming the service remains accountable for risk decisions, while the vendor is accountable for execution within the agreed boundary. Another edge case is shared ownership across subsidiaries or tenants, where identity changes may be technically feasible from multiple consoles. That is where a single source of truth and a change ledger become essential.
For teams formalising these controls, the lesson from the broader breach landscape is consistent: weak ownership becomes a security problem fast, as reflected in 52 NHI Breaches Analysis and the patterns in Schneider Electric credentials breach. The practical test is simple: if a device identity can change but no one can immediately name the approver, executor, and revoker, accountability is not yet mature.
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, NIST Zero Trust (SP 800-207), NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity ownership and lifecycle control are central to accountable device identity changes. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege and access governance apply directly to device identity change authority. |
| NIST Zero Trust (SP 800-207) | PR.AC | Zero Trust requires explicit, continuous trust decisions for device identity state. |
| NIST SP 800-63 | AAL | Strong identity proofing and authentication support trustworthy administrative changes. |
| NIST AI RMF | GOVERN | Governance accountability is essential when multiple parties can alter device identity. |
Assign one owner for each device identity and require approved, logged changes before any credential update.
Related resources from NHI Mgmt Group
- Who is accountable when contractor handling of identity data goes wrong?
- Who is accountable when identity failures trigger fines and investor action?
- Who should be accountable when a device security mandate affects user data?
- How should teams govern IoT device identities across distributors and integrators?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
