Connected devices expand the attack surface faster than many teams can secure it, while attacker activity and device counts both keep rising. The result is a mismatch between perceived protection and real exposure. Because many organisations lack the awareness and expertise to defend IoT well, risk accumulates through weak governance, inconsistent standards, and uneven lifecycle control.
Why connected devices stay risky even after “good” security is in place
Connected devices rarely fail because one control is missing. The problem is that the environment keeps changing, with new hardware, firmware, suppliers, identities, and connections arriving faster than governance can absorb them. Security teams can have sensible controls and still end up with unmanaged variance, which creates persistent exposure.
For device trust, onboarding, and lifecycle assumptions, the Device and IoT Identity Guide is a direct fit because it treats device identity, certificates, attestation, and default-password removal as part of the security baseline.
That is why “well protected” often means “protected at the point of deployment,” not protected across the full life of the device. Once devices are distributed, organisations inherit patch lag, inventory drift, firmware inconsistency, and trust decisions that are hard to reverse at scale.
What makes the attack surface keep growing
Connected devices increase exposure in several ways at once. Each device adds a potential entry point, a software and firmware maintenance obligation, and often a dependency on cloud services, mobile apps, APIs, or third-party platforms. Even when the core network is hardened, the device layer can stay uneven because different product families age at different speeds.
Device trust has to be established and maintained, not assumed. Device certificates, attestation, secure onboarding, and the removal of default credentials are the difference between a device that can be governed and one that merely exists on the network.
Connected systems also tend to blur ownership. Operations may manage uptime, security may define policy, engineering may approve exceptions, and procurement may select the vendor, but no one function owns the full lifecycle. That fragmentation is a security issue because the device is only as strong as its weakest operating assumption.
The challenge is not only the device itself. It is the ecosystem around it: provisioning, update channels, logging, third-party maintenance, replacement planning, and decommissioning. If any one of those steps is weak, the device remains exposed long after initial hardening.
Why perception and reality diverge over time
Perceived protection often comes from visible controls, such as network segmentation, passwords, and endpoint monitoring. Real exposure depends on whether those controls stay true after devices are shipped, updated, relocated, or reused. Connected devices create long-lived risk because the control state drifts while the device remains operational.
IoT Cybersecurity Program guidance and similar baselines emphasise secure-by-design expectations because device security has to cover the full lifecycle, including patchability, configuration integrity, and vulnerability handling.
That divergence is especially pronounced when organisations scale faster than their standards. One team may require strong onboarding, while another accepts factory defaults; one business unit may track firmware, while another cannot prove which models are still deployed. The result is not a single failure, but a compound risk profile built from small exceptions.
Risk also accumulates because attackers need only one weak edge. A device with stale firmware, exposed remote management, or weak third-party integration can become an access path that bypasses otherwise strong perimeter controls. In connected environments, the longest-tail asset often defines the real security ceiling.
Risk and Threat Considerations
Connected devices are attractive because they combine scale, heterogeneity, and long service lives. That makes them a persistent source of exposure even when core infrastructure is well defended, since a single weak model, forgotten asset, or poorly maintained integration can remain reachable for years.
Failure mechanism: Attackers look for unmanaged devices, default or reused credentials, weak update mechanisms, exposed management interfaces, and third-party dependencies. Once one device is compromised, it can provide pivoting, persistence, or a foothold into adjacent systems.
Impact: The practical impact is not just device compromise. It can include lateral movement, service disruption, data exposure, and a widening gap between policy and actual control, especially where inventory and ownership are incomplete.
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, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Connected devices stay risky when retired devices still retain access paths. |
| NHI-02 — Secret Leakage | Default or exposed device credentials are a common driver of ongoing exposure. | |
| NHI-07 — Long-Lived Secrets | Device credentials and certificates often outlive the controls intended to protect them. | |
| Recommendation — Revoke device access and credentials immediately when a device is decommissioned. Eliminate exposed device secrets and rotate any credentials that may be shared. Shorten secret lifetimes and enforce rotation for device authentication material. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Device credentials, tokens, and certificates need lifecycle control. |
| CM-8 — System Component Inventory | Ongoing risk grows when organisations lose track of connected devices. | |
| SI-2 — Flaw Remediation | Patch lag and firmware drift are core reasons device risk persists. | |
| Recommendation — Manage device authenticators across issuance, rotation, storage, and revocation. Maintain an accurate inventory of connected devices and their ownership. Apply timely remediation to device firmware and software flaws. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical Devices and Systems Inventoried | Device risk persists when inventory and ownership are incomplete. |
| PR.AA-05 — Access Permissions Managed | Connected devices need controlled access and bounded privileges. | |
| Recommendation — Inventory connected devices and keep the record current. Limit device access to the minimum permissions needed for operation. | ||
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | Untracked connected devices expand exposure and hinder response. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Baseline drift and insecure defaults keep device exposure alive. | |
| Recommendation — Track every connected device and remove unauthorized assets. Harden device configurations and continuously check them against baseline. | ||
Practitioner Guidance
What to prioritise: Treat device inventory, ownership, and firmware currency as the primary control set, not an administrative afterthought. If you cannot answer what is deployed, who owns it, and how it is updated, you do not yet have a trustworthy device programme.
What to verify: Confirm that each device class has a defined onboarding method, update path, and retirement process. Verify that default credentials are eliminated, remote access is deliberate, and exceptions are time-bound rather than permanent.
Practitioner takeaway: Connected-device security is won by lifecycle control and trust assurance, not by hoping perimeter controls will compensate for unmanaged hardware variation.
Related resources from NHI Mgmt Group
- Why do networked access control devices create security risk when they are not properly protected?
- Why do missing KB details create security risk even when devices seem up to date?
- Why do connected medical devices create identity security risk for hospitals?
- Why do GenAI systems create more security risk once they are connected to business data?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
