NIST SP 1800-36, finalized in November 2025, defines network-layer onboarding as provisioning an IoT device with the credentials it needs to join an IP network. NIST describes two risks in an untrusted process: a malicious device may enter an authorized network, or a legitimate device may be induced to join an unauthorized network. Trusted onboarding lets the device and network establish trust before operational credentials are issued.
\r\nNISTIR 8350 describes trusted onboarding as providing each device unique network credentials, giving device and network an opportunity to authenticate each other, using an encrypted channel, keeping people from learning the network credentials, and allowing the process to be repeated so credentials can be replaced. SP 1800-36 demonstrates example architectures using standards, best practices, and commercial technology. It is a practice guide, not a claim that every camera or access device supports every demonstrated method.
\r\nNetwork-layer onboarding answers how a device earns network credentials. Application-layer onboarding answers how it enrolls into a video manager, access platform, cloud service, or mobile app. Asset authorization answers whether that exact model, serial number, owner, location, firmware, and purpose were approved. These controls can reinforce one another, but completing one does not complete the others.
\r\nLikewise, onboarding is not permanent trust. A correctly identified device can later become vulnerable, misconfigured, stolen, reassigned, or unsupported. NIST pairs onboarding with lifecycle capabilities such as posture checks, credential management, device intent enforcement, and secure management.
\r\nInventory the switches, wireless infrastructure, network-access control, identity and certificate services, device-management platforms, DNS, time, logging, and recovery dependencies involved. Decide who can approve a device, which trust anchors are accepted, what evidence is stored, how certificate or credential expiry is monitored, and what happens when a validation service is unavailable.
\r\nAsk manufacturers to demonstrate the exact model and software path. Marketing terms such as secure onboarding, zero touch, certificate-based, or zero trust do not establish mutual authentication, unique credentials, protected delivery, posture evidence, or rotation. Require protocol and certificate details, failure behavior, renewal, reset, transfer, revocation, audit output, supported infrastructure, and licensing in writing.
\r\nUse a lab or isolated production pilot with representative devices. Attempt an unknown device, a device with invalid or expired evidence, a duplicated identity, an unauthorized onboarding service, interrupted provisioning, wrong network policy, failed credential rotation, factory reset, and return after revocation. Confirm that failure is closed or intentionally quarantined, visible to operations, and recoverable without sharing a fleet-wide credential.
\r\nMeasure operational cost as well as technical success: deployment time, exception rate, certificate renewal, replacement workflow, inventory accuracy, help-desk visibility, and recovery during identity-service or network outage. An architecture that only a specialist can repair may create availability risk for doors and video.
\r\nTrusted onboarding can reduce reliance on shared secrets and manual provisioning, but it does not eliminate segmentation, secure configuration, software updates, vulnerability response, application authorization, backups, or monitoring. Where legacy devices cannot participate, document compensating controls and a replacement plan. DSE recommends using SP 1800-36 as a requirements and pilot guide, then validating every capability against the products actually deployed.
\r\n