How should teams govern IoT device identities across distributors and integrators?

Why This Matters for Security Teams

IoT devices rarely stay inside one trust boundary for long. A manufacturer may ship the device, a distributor may stage it, an integrator may configure it, and the customer may operate it. Each handoff changes who should be able to provision, support, rotate, or revoke the device identity. That makes identity governance a supply chain problem, not just an endpoint problem. NHI Mgmt Group notes that 92% of organisations expose NHIs to third parties, which is exactly where IoT identity risk starts to compound Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.

The practical mistake is treating a device certificate or API token as if it can follow the same ownership model across every partner. It cannot. Distributors often need temporary enrollment rights, integrators may need limited commissioning access, and customer teams need ongoing administration without inheriting partner privileges. Security teams that ignore this separation usually discover it after a support escalation, a failed revocation, or a partner account that still has standing access long after the project ended. The control goal is to make every handoff explicit and auditable, not informal and reversible only by guesswork. In practice, many security teams encounter stale partner access only after a device fleet has already been reconfigured or a credential has already been reused.

How It Works in Practice

Governance should start with a lifecycle map that names the owner for each identity state: manufacture, distribution, staging, commissioning, active operation, maintenance, and decommissioning. For each state, define who can issue credentials, who can request changes, and who can revoke access. That mapping should be enforced through policy rather than tribal knowledge, using the same audit discipline reflected in Ultimate Guide to NHIs — Regulatory and Audit Perspectives and aligned with the control intent in NIST Cybersecurity Framework 2.0.

• Assign one accountable owner for the device identity record, even when multiple partners touch the device.
• Use separate roles for provisioning, support, and customer administration so no single partner can both issue and approve changes.
• Require partner access to be time-bound and task-bound, especially for commissioning and field support.
• Log every credential change, enrollment event, and revocation with partner attribution and business justification.
• Prefer short-lived enrollment tokens or certificates over long-lived shared secrets where device architecture allows it.

Operationally, this means the distributor can stage identity material, the integrator can activate the device within a narrow window, and the customer can manage ongoing policy without inheriting the full partner toolchain. Revocation must also be lifecycle-aware: when a reseller contract ends or an integrator is removed, the device identity and all delegated support paths need to be re-evaluated immediately. Where possible, map these controls to least-privilege principles in NIST SP 800-53 Rev 5 Security and Privacy Controls. These controls tend to break down when distributors and integrators share a common admin tenant because attribution and revocation authority become indistinguishable.

Common Variations and Edge Cases

Tighter partner controls often increase onboarding friction, requiring organisations to balance faster deployment against stronger attribution and revocation. That tradeoff becomes sharper in high-volume IoT programs, where devices are shipped in bulk and individual identity handoff is easy to skip. Best practice is evolving here, but current guidance suggests that exceptions should be explicit, time-limited, and approved by the entity that owns the device outcome, not by whichever partner is technically closest to the work.

Some environments also blur the line between distributor support and integrator commissioning. In those cases, separate identities are still preferable even if a single vendor performs both roles, because the audit question is not who can do the work today, but who can prove they were authorised for that specific lifecycle step. Another edge case is offline or intermittently connected devices, where immediate revocation is not always possible. In that situation, governance should shift to short certificate lifetimes, delayed trust restoration, and post-reconnect verification. NHI Mgmt Group’s lifecycle guidance remains the practical anchor for this approach Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. Where partner ecosystems are highly federated, this guidance breaks down when no single party controls the device registry, because revocation and attestation cannot be enforced end to end.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?
• How should security teams govern non-human identities that have persistent access?