IoT security still collapses around weak credentials and exposed devices

At a glance

What this is: This is a plain-English overview of IoT and its main security risks, with weak authentication, poor encryption, and patching gaps identified as the core failure points.

Why it matters: It matters because IoT devices behave like credentialed endpoints, so the same identity, access, and lifecycle controls used for NHI and human programmes must extend to connected devices.

By the numbers:

• 2023, ay 2023, Amazon faced a $5.8 million settlement because an Amazon Ring employee was able to view thousands of videos from at least 81 different female users.

👉 Read Keeper Security's blog on what IoT is and how to secure it

Context

IoT security is an identity and access problem as much as it is a device problem. Every connected object creates another endpoint, another software stack, and often another credential path that must be governed. When those devices rely on default passwords, weak authentication, or neglected updates, the security programme is already behind.

The article frames IoT as a convenience layer, but the governance reality is broader: IoT devices collect sensitive data, expand the attack surface, and can expose homes, workplaces, and industrial systems if they are not managed with the same discipline applied to other non-human identities. For IAM and security teams, the lesson is that connected devices cannot be treated as low-risk simply because they are embedded in the environment.

That is a typical failure pattern, not an edge case. The same access, encryption, and lifecycle blind spots that weaken NHI programmes also show up in IoT fleets, especially where onboarding is easy and offboarding or patching is not enforced.

Key questions

Q: How should organisations secure IoT devices before deploying them at scale?

A: Organisations should treat IoT onboarding like identity onboarding. Assign unique credentials, enforce ownership, require encryption, and block devices that are still on default settings. They should also maintain a live inventory of devices, accounts, and network paths so security teams can track changes across the device lifecycle instead of discovering gaps after deployment.

Q: Why do IoT devices increase risk even when each device seems low value?

A: IoT devices increase risk because each one adds a new endpoint, trust path, and often a new credential. The combined effect is a larger attack surface, more opportunities for weak authentication, and more places where data can be exposed. Security teams should judge IoT fleets by their aggregate access footprint, not by the apparent simplicity of each device.

Q: What do security teams get wrong about IoT authentication?

A: They often focus on user-facing controls and ignore the device lifecycle. If a device ships with a default password, has no owner, or can be deployed without enrollment, authentication is already failing. Strong passwords help, but the real control is preventing unmanaged devices from entering production in the first place.

Q: Who is accountable when IoT device data is accessed improperly?

A: Accountability should rest with the team that owns the device lifecycle and the permissions behind it, not with the hardware alone. If access is broad, unreviewed, or poorly monitored, the problem is governance as much as technology. Frameworks such as NIST Cybersecurity Framework support that accountability by tying asset management, access control, and recovery together.

Technical breakdown

Weak authentication on connected devices

IoT devices often begin life with default credentials, simple passwords, or no authentication at all. That makes the device itself a trust boundary, because anyone who can guess or obtain the login can reach the data, controls, or network path behind it. In practice, weak authentication is not just a bad password problem. It is a provisioning and ownership problem, because a device may be deployed faster than it is enrolled into a control framework. Once that happens, the device becomes a credentialed asset without meaningful identity governance.

Practical implication: enforce unique credentials and registration workflows before a device is allowed onto the network.

Why encryption and patching are core IoT controls

IoT systems usually move data from sensors to gateways, then to cloud services or applications. If the data is not encrypted in transit and at rest, any compromised hop can expose it. The same is true for software and firmware. Out-of-date code leaves known flaws open, and because many IoT devices are always connected, a single unpatched device can become a foothold for lateral abuse. In other words, confidentiality and patch hygiene are not separate issues in IoT. They are the minimum conditions for keeping one device from becoming a network-wide problem.

Practical implication: require encryption by default and automate firmware update enforcement across the fleet.

Attack surface growth in multi-device environments

An IoT environment becomes harder to defend as the number of devices rises because each device adds interfaces, permissions, telemetry, and data flows. That creates a larger attack surface even when each individual device looks harmless. The control challenge is not only device count, but also the way devices interact with each other and with cloud platforms. When a smart camera, thermostat, wearable, or industrial sensor shares data, the trust chain extends beyond the object itself. Security teams should treat the fleet as a distributed identity estate, not a collection of isolated gadgets.

Practical implication: inventory every connected device and map its data and access dependencies before expanding deployment.

Threat narrative

Attacker objective: The attacker seeks access to personal or operational data by turning a connected device into a trusted entry point.

1. Entry occurs through weak authentication, default passwords, or devices that do not require meaningful login protection.
2. Escalation follows when an exposed device is used to reach the stored data, connected account, or adjacent systems on the same network.
3. Impact appears as privacy loss, unauthorised surveillance, or wider compromise of the connected environment after one device is abused.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

IoT devices fail governance first, then security. The core problem is not that connected devices are inherently dangerous, but that they are often deployed faster than identity, patch, and data controls are assigned. That creates a standing access problem at the edge, where devices collect data before their trust model is fully defined. Practitioners should treat every connected device as an identity-bearing asset that needs lifecycle governance from day one.

Device convenience creates identity sprawl in the same way NHI sprawl does. Each camera, thermostat, wearable, and industrial sensor adds another account, credential, or administrative path that has to be managed somewhere. The result is not just more endpoints, but more places where ownership and accountability can break down. Teams that already struggle with service-account inventory will recognise the same pattern in IoT fleets, only distributed across physical devices instead of server workloads. Practitioners should expect the same governance failure mode under a different surface.

Weak authentication is really a lifecycle failure disguised as a login problem. Default passwords, shared credentials, and unauthenticated devices persist because nobody owns the full joiner-mover-leaver flow for the device. That gap is especially visible when devices are installed once and then forgotten, even though their software, users, and data flows continue to change. The implication is that IoT security cannot be reduced to user education. Practitioners should align device onboarding and offboarding with explicit ownership.

IoT privacy risk exposes the limits of informal access control. The Amazon Ring example in the article shows that even when devices are consumer-facing, insider access can still become a governance failure if permissions are too broad or oversight is too weak. That is the same control lesson identity teams see in enterprise environments: access that is technically available is not the same as access that is properly governed. Practitioners should treat privacy protection as an access governance issue, not just a product setting.

Connected-device governance belongs in the same control conversation as NHI and IAM. IoT and workload identity share a common structure: a non-human actor, a credential or trust path, and a data surface that grows faster than manual review can keep up. The relevant framework lens is NIST Cybersecurity Framework for asset, access, and recovery discipline, plus zero trust principles for continuous verification. Practitioners should stop separating device security from identity security when building governance models.

From our research:

• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
• In the same survey, 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts.
• For a broader governance lens, read Top 10 NHI Issues for the control gaps that recur across machine identity programmes.

What this signals

The operational signal is straightforward: IoT fleets should be managed as identity estates, not device inventories. When ownership, credentialing, and firmware enforcement are weak, the programme will drift into the same unmanaged state that plagues many NHI deployments. The practical shift is to bring device onboarding and offboarding under the same governance cadence used for other non-human identities.

Edge identity sprawl: As connected devices multiply, the challenge is no longer simply securing endpoints. It is maintaining visibility into who or what can talk to the device, what data it emits, and whether its trust path still matches the business use case. That is where identity, asset, and access governance meet.

Practitioners should also watch for crossover between consumer IoT controls and enterprise identity standards. Zero trust principles from NIST SP 800-207 Zero Trust Architecture remain relevant when every device is a potential access path, and the security model must continuously verify rather than assume trust.

For practitioners

• Eliminate default and shared credentials Require unique credentials or passkeys for every IoT device and associated account before network access is granted, and block deployment when a device still uses vendor defaults.
• Apply enrollment and ownership controls at setup Tie each device to a named business owner, an inventory record, and an approved use case so every device has an accountable lifecycle from onboarding through retirement.
• Turn on encryption and automate firmware updates Verify that data in transit and at rest is encrypted, then enable automatic firmware updates so known vulnerabilities do not remain available on connected devices.
• Reduce unnecessary device features and services Disable functions, services, and remote interfaces that are not required for the device’s purpose so the attack surface stays as small as possible.

Key takeaways

• IoT security breaks down where device identity, access control, and lifecycle ownership are left informal.
• The article’s examples show that weak authentication and unmanaged exposure create privacy and network risk well before a device is obviously compromised.
• Security teams should govern IoT as part of the broader identity estate, with unique credentials, encryption, update discipline, and clear accountability.

Key terms

• Internet of Things: A network of physical devices that collect, exchange, and act on data over the internet or a connected platform. In security terms, each device behaves like a non-human endpoint with its own identity, software, permissions, and lifecycle that must be governed like any other connected asset.
• Attack Surface: The full set of places where a system can be reached, influenced, or compromised. For IoT, that includes device interfaces, connected accounts, cloud services, wireless links, and data flows, all of which expand as devices are added and often outpace manual oversight.
• Device Lifecycle: The end-to-end governance path for a device from procurement and onboarding through operation, update, and retirement. In IoT programmes, lifecycle control determines whether the device remains owned, patched, authenticated, and removable when the business no longer needs it.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Keeper Security: What Is the Internet of Things (IoT)? Read the original.