Onboard connected security devices without lending trust first

Source fact: onboarding is a security decision

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.

NISTIR 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.

Understand the boundary

Network-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.

Likewise, 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.

DSE recommendation: design six explicit states

1. Expected: Procurement records the supported identity, trust anchor, onboarding protocol, credential type, attestation or posture evidence, reset behavior, ownership transfer, and end-of-support commitments for the exact product and firmware.
2. Untrusted: A new or reset device reaches only the tightly limited services needed to identify and onboard it. It does not inherit ordinary camera, controller, server, or internet access from the jack.
3. Validated: The onboarding service validates device evidence and the device validates the authorized network according to the selected mechanism. Failed or ambiguous validation creates an actionable record.
4. Provisioned: Unique credentials are delivered through the protected onboarding exchange. The asset record binds the credential to device, owner, site, policy, and issuance event without exposing secret material.
5. Authorized: Network policy grants only the production flows required for the approved role. Application enrollment, hardening, updates, logging, and acceptance tests still occur separately.
6. Removed: Loss, replacement, compromise, factory reset, reassignment, or retirement revokes credentials and policy, removes application trust, and prevents silent return.

Build prerequisites before buying an onboarding product

Inventory 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.

Ask 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.

Pilot the failure paths

Use 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.

Measure 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.

Adopt the pattern, not an assumption

Trusted 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.

Official sources

• NIST SP 1800-36, complete practice guide
• NISTIR 8350, Foundational Concepts in Trusted IoT Device Network-Layer Onboarding
• NIST CSWP 42, Towards Automating IoT Security
• NCCoE project page and component volumes