Secure commissioning and onboarding
Verify device identity, software, configuration and ownership during commissioning. Record the approved settings and recovery process before putting the device into service.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Research and static guidance only; product and deployment specific behaviour requires controlled environment validation and authoritative product evidence.
On this page
Overview#
Commissioning is the transition from an untrusted or vendor default device to an inventoried component with a verified owner, unique identity, approved software, trusted configuration, and documented recovery path.
Commissioning procedures that touch locks, gates, alarms, elevators, fire interfaces, relays, or emergency communications require qualified personnel and an isolated, unoccupied test context. Software steps don't replace manufacturer or authority requirements.
State machine#
| State | Required properties | Exit evidence |
|---|---|---|
| Received | Model, serial, provenance, seals and expected firmware recorded | Inventory record and acceptance decision |
| Isolated | No production trust or routing; bootstrap exposure bounded | Defined commissioning network and authorised operator |
| Identified | Device identity and claimed model/firmware checked | Exact identifiers and source documentation |
| Owned | Default/shared credentials removed; local ownership established | Unique admin path and recovery custody |
| Trusted | Certificates/keys enrolled and trust anchors installed | Certificate/key identifiers and environment validation result |
| Hardened | Unused services/accounts disabled; time, logging and update policy set | Approved configuration record |
| Integrated | Least privilege flows and application authorisation configured | Flow and permission matrix |
| Accepted | System owner approves functional, failure, and safety validation | Approved environment validation record |
Bootstrap hazards#
- shared factory credentials or keys;
- unauthenticated discovery/configuration protocols;
- temporary HTTP or wireless setup networks left enabled;
- acceptance of self signed certificates without an out of band identity check;
- permanent installation mode keys or downgrade to legacy reader signalling;
- cloud claim codes exposed in labels, logs, screenshots, or email;
- reset workflows that re enable insecure defaults;
- time dependent certificates enrolled before trustworthy time exists.
Developer requirements#
- Make onboarding an explicit, auditable state machine rather than a hidden first request shortcut.
- Bind the claimed device identity to independently obtained inventory or manufacturer evidence.
- Require intentional ownership transfer and prevent silent re claiming.
- Make bootstrap credentials single use or short lived, rate limited, and removable.
- Fail closed on identity mismatch while preserving safe local physical behaviour.
- Provide idempotent enrolment and recovery from partial failure.
- Expose clear status without logging keys, tokens, credential IDs, or private topology.
- Treat factory reset and RMA as security transitions with key destruction and ownership removal.
Acceptance record#
Record exact product, hardware revision, firmware, enabled profiles, certificates/trust anchors, accounts, network flows, time source, update source, configuration export, recovery custodian, validation date, and approval owner. Keep live secret values out of design, acceptance, and inventory records.
Sources#
- NISTIR 8259A, NISTIR 8259A: IoT Device Cybersecurity Capability Core Baseline, device identification, configuration, data protection, interface access, update and security state awareness, accessed 25 August 2026.
- NIST 800 82, NIST SP 800-82 Rev. 3, OT asset, architecture and lifecycle guidance, accessed 25 August 2026.