Who should own IoT device identity governance in an enterprise?

IoT device identity governance should be shared across identity, security architecture, operations, and procurement, with clear ownership for issuing, approving, rotating, and revoking device credentials. If no team owns the lifecycle, devices become persistent trust exceptions. The right model is policy-led governance with operational responsibility assigned before devices reach production.

Why This Matters for Security Teams

IoT device identity governance is not just an inventory problem. Every sensor, camera, gateway, controller, and embedded workload can become a long-lived trust anchor if its credential lifecycle is not owned. That creates audit gaps, weak revocation paths, and hidden privilege that security teams often inherit only after an incident. NHI Management Group’s research on lifecycle failures in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs shows why issuance, rotation, and decommissioning must be treated as governed controls, not informal ops tasks.

The ownership question matters because devices outlive projects, vendors change firmware and certificates, and procurement decisions often happen before security architecture has defined approval paths. That is where policy-led governance becomes essential: identity teams define standards, security architecture sets trust requirements, operations executes lifecycle actions, and procurement ensures vendor commitments are enforceable. Current guidance aligns with the control intent in the NIST Cybersecurity Framework 2.0, especially around asset governance, access control, and recovery planning. In practice, many security teams encounter device identity failures only after a certificate expires, a vendor account is still active, or a field device cannot be revoked without breaking production.

How It Works in Practice

The most effective enterprise model is a shared governance structure with one accountable owner for policy and multiple operational owners for execution. Identity and security architecture should define the approved identity pattern for each device class, such as certificate-based identity, hardware-backed keys, or signed bootstrap credentials. Operations then manages enrollment, renewal, and revocation workflows. Procurement ensures identity requirements appear in RFPs, contracts, and support clauses. This is the practical way to prevent devices from becoming permanent exceptions.

For most environments, the control baseline should include unique device identity, no shared default credentials, scoped credential issuance, and mandatory rotation tied to lifecycle events. A device should never remain trusted simply because it is hard to touch physically. The enterprise should also define who approves exceptions, how emergency access works, and what happens when a device is retired, transferred, or replaced. NHI Management Group’s Top 10 NHI Issues highlights why rotation failures and over-privileged access recur when these steps are not explicitly assigned.

• Identity team: sets identity standards, certificate policy, and trust architecture.
• Security architecture: defines acceptable auth methods, segmentation, and revocation rules.
• Operations or OT/IT operations: runs enrollment, renewal, monitoring, and retirement.
• Procurement and vendor management: enforces security clauses and support obligations.
• Business owner: accepts risk for exceptions and device-specific operational dependencies.

For governance to work, the enterprise needs a device register, certificate owner, renewal SLA, emergency revocation process, and periodic access review. That also means integrating device identity into change management, CMDB processes, and incident response so the identity lifecycle is visible before failure occurs. These controls tend to break down when device ownership crosses IT and OT boundaries because neither side can fully execute revocation without disrupting uptime.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, so organisations must balance revocation speed against uptime, vendor constraints, and field maintenance realities. That tradeoff is especially visible in OT, healthcare, manufacturing, and public infrastructure, where devices may be hard to patch or physically unreachable for months. In those cases, current guidance suggests compensating controls such as segmented networks, shorter-lived credentials where feasible, and stronger monitoring rather than leaving devices on indefinite trust.

There is also no universal standard for who owns device identity in every enterprise. Mature organisations often assign policy ownership to IAM or security architecture, while platform, OT, or infrastructure teams own execution. What matters is that ownership is explicit before production, not negotiated after deployment. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because auditors usually care less about team titles than whether lifecycle controls are documented and enforced.

Where the model breaks down most often is vendor-managed fleets and shared-service environments, because the enterprise may control the network but not the device firmware, credential store, or revocation channel. In those cases, the contract must define identity responsibilities clearly, or the device becomes a trust exception with no practical owner.

Related resources from NHI Mgmt Group

• Who should own identity governance when it spans cloud and enterprise systems?
• Who should own machine identity governance in an enterprise?
• Who should own policy-based access governance in an enterprise?
• Who should own identity governance for ERP, HCM, and integration users?