No. New IoT devices should be treated as untrusted until they pass identity assignment, integrity verification and network placement controls. Pre-infected supply chains and first-boot payload delivery mean sealed hardware can still be compromised. Trust should be earned through evidence, not assumed from packaging, purchase channel or vendor reputation alone.
Why new IoT devices should stay untrusted until verification finishes
New IoT hardware is not trustworthy just because it is sealed, branded or freshly purchased. The security question is whether the device can prove what it is, what firmware it is running, and where it is allowed to communicate before it touches production networks. That is why identity assignment, integrity checks and placement controls come first.
A practical trust model starts with device identity, because a device that cannot be uniquely identified cannot be governed or revoked cleanly. It then checks firmware and boot integrity, because compromise can exist before first power-on or during the first update path. Only after those checks should the device be admitted to a network zone that matches its expected role.
This is also where onboarding policy matters. A device should not receive broad access during discovery, pairing or registration. If the device can only operate after it has been attested, mapped to an owner, and limited to a low-trust segment, the organisation reduces the chance that a counterfeit, tampered or misconfigured device can reach sensitive systems.
What makes IoT trust different from ordinary endpoint trust?
IoT trust is harder because the device lifecycle often begins outside your direct control. Hardware may be assembled across multiple suppliers, flashed before delivery, or configured with hidden defaults that survive the first boot. The trust decision therefore has to cover the supply chain, not just the device once it reaches your site.
Unlike a managed laptop, many IoT devices have limited visibility, weak user interfaces and irregular update paths. That means security teams cannot rely on the same user-centric onboarding controls. They need device-specific evidence, such as signed identity material, attestation status, firmware provenance and a clear record of which services the device is allowed to reach.
Device and IoT Identity Guide is useful here because it frames the trust problem around device identity, certificates, attestation and secure onboarding rather than around packaging or vendor claims.
What verification must happen before a device earns trust?
Verification should answer three questions: is the device genuine, is its software state expected, and is its network exposure bounded. In practice that means identity proofing or assignment, secure boot or firmware validation, and a default-deny placement that prevents the device from speaking broadly while it is still being evaluated.
Integrity checks are especially important because first-boot compromise can happen even when the box arrives intact. A device may ship with a vulnerable image, a poisoned update channel, or preloaded credentials that are already known outside the organisation. The verification stage is the point at which those issues should be detected or at least contained.
Placement controls are the final guardrail. If the device is treated as low trust until it proves otherwise, it can be isolated to a quarantine segment, a provisioning VLAN, or a tightly scoped policy set. That buys time to verify behaviour without allowing a compromised device to reach business systems.
IoT Security Guide helps practitioners connect device identity, segmentation, firmware updates and supply-chain risk into a single verification workflow.
Risk and Threat Considerations
The main risk is that organisations confuse purchase assurance with security assurance. A device can be genuine and still be unsafe, because compromise may be introduced in manufacturing, distribution, configuration or the first update path. Once an unverified device is allowed onto the network, it can expose credentials, relay traffic, or become a foothold for lateral movement.
Failure mechanism: The device is trusted before it has been attested, segmented or restricted, so any preinstalled payload, default secret, or malicious update mechanism can operate inside the trusted environment.
Impact: The organisation may inherit a hidden persistence point, an unmanaged data path, or a device that can be abused as an internal pivot into higher-value systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Device trust depends on revocation and lifecycle control when an IoT device is no longer approved. |
| NHI-02 — Secret Leakage | Unverified IoT devices may ship with exposed or default secrets that undermine trust. | |
| NHI-06 — Insecure Cloud Deployment Configurations | IoT trust fails when cloud and network controls admit devices before posture and identity checks. | |
| Recommendation — Revoke and retire device identities promptly when a device leaves service or fails verification. Rotate or replace device secrets before allowing the device into production networks. Enforce secure provisioning settings so only verified devices receive access and configuration. | ||
| NIST SP 800-53 Rev 5 | IA-3 — Device Identification and Authentication | IoT trust starts with proving the device is uniquely identified before granting access. |
| IA-5 — Authenticator Management | Verified IoT trust depends on controlling device credentials, certificates and rotation. | |
| SI-7 — Software, Firmware, and Information Integrity | Firmware integrity checks are central to deciding whether a device is safe to trust. | |
| Recommendation — Require device identification and authentication before network admission. Manage device authenticators through issuance, rotation and revocation controls. Validate firmware and software integrity before placing a device into service. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | IoT trust depends on identity assignment, access scoping and device onboarding controls. |
| Recommendation — Apply IAM controls to provision, authenticate and govern device access. | ||
Practitioner Guidance
What to prioritise: Treat identity assignment and network placement as gating controls, not administrative afterthoughts. If a device cannot be uniquely identified and isolated during onboarding, it should not be allowed to interact with sensitive services.
What to verify: Confirm that the device presents a verifiable identity, that its boot and firmware state match what was expected, and that its allowed destinations are narrowly scoped. If any of those checks fail, keep the device in a quarantine posture rather than escalating access.
Practitioner takeaway: The safe default is not to trust new IoT devices less than other assets, but to require evidence before they join the trust boundary at all.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org