TL;DR: Most connected device security flaws trace back to one root problem, makers cannot see what software is inside the device, so default passwords, vulnerable open-source code, and insecure interfaces keep producing breaches and now trigger mandatory SBOM and reporting duties under the EU Cyber Resilience Act, according to Finite State research. Visibility, not perimeter tooling, is the control that determines whether device risk can actually be governed.
At a glance
What this is: This analysis says connected device security fails most often because manufacturers cannot see the software, firmware, and third-party components inside shipped products.
Why it matters: It matters to IAM, NHI, and security teams because hidden software inventories, default credentials, and opaque supply chains create governance gaps that no downstream control can reliably fix.
Context
Connected device security is the problem of governing products that are physically exposed, remotely connected, and often deployed for years with limited patching options. The core failure is visibility: if a manufacturer cannot inventory the software inside the device, it cannot know which flaws are present, reachable, or already exploited.
That gap matters across identity and access programmes because connected devices frequently rely on embedded credentials, unauthenticated services, exposed interfaces, and third-party components that behave like unmanaged machine identities. In this domain, security is less about perimeter defence and more about proving what was shipped, what can be reached, and what can still be updated.
Key questions
Q: What breaks when connected devices ship without a trustworthy software inventory?
A: Without a trustworthy inventory, teams cannot tell which flaws are present, which components are reachable, or which products are affected by new disclosures. That makes patching, incident response, and regulatory evidence all depend on guesswork. In practice, the device may remain exploitable long after the vulnerability is known because no one can prove where it exists.
Q: Why do default passwords on smart devices create such a big risk?
A: Default passwords are predictable, widely known, and often reused across devices, which makes them easy to guess or automate against. Once one credential is exposed, the same login may unlock several devices or apps. That turns a single weak setup choice into a larger identity and network exposure.
Q: What signs show that a device programme is still relying on undocumented third-party code?
A: Repeated high-severity findings in embedded libraries, missing component provenance, inability to explain update paths, and dependence on vendor assurances rather than extracted firmware evidence are all warning signs. If the team cannot trace what was shipped, it is already operating with incomplete control over the product attack surface.
Q: How should manufacturers respond when connected device compliance and security goals overlap?
A: Treat compliance artefacts as operational security inputs rather than paperwork. If the EU Cyber Resilience Act requires SBOMs, vulnerability handling, and reporting, those duties should feed firmware inventory, exposure prioritisation, and patch governance. The strongest programmes use the same evidence to support release decisions, incident response, and audit readiness.
Technical breakdown
Why firmware visibility is the control point
Firmware is the device's operating reality. It contains the code, libraries, secrets, and configuration that determine how the product behaves after shipment. Traditional testing often sees only the app layer or network surface, while the embedded image may hide hardcoded credentials, unsigned update paths, or old libraries with known vulnerabilities. Because devices are constrained and long-lived, those weaknesses persist far longer than in conventional IT systems. Ground-truth analysis of the firmware is therefore the only dependable way to know what is actually present, what is reachable, and what must be remediated.
Practical implication: treat firmware extraction and binary analysis as the starting point for any connected device risk review.
How default credentials and exposed interfaces become entry points
Default passwords, open debug ports, and unauthenticated network services turn ordinary devices into easy entry points. Attackers do not need deep exploitation when the product ships with a known credential, a public interface, or a management service that assumes trust. In consumer and industrial settings alike, the device often becomes the first foothold, then a pivot into adjacent systems or a botnet node. This is not only a device hardening issue, it is an identity issue, because the credential or interface is acting as the machine identity boundary and often has no lifecycle governance after manufacture.
Practical implication: eliminate shipped credentials and unauthenticated management services before release, not after deployment.
Why SBOMs and reachability analysis matter together
A software bill of materials lists the components inside a product, but inventory alone does not tell you whether a flaw is actually exploitable on a specific device. Reachability analysis adds the missing layer by testing whether a vulnerable component is exposed through the product's code paths, configuration, or interfaces. That combination is what turns compliance evidence into operational control. It also aligns with the reality of embedded supply chains, where many vulnerabilities exist in inherited third-party code rather than first-party development. Without both inventory and reachability, teams either miss real exposure or spend effort chasing irrelevant findings.
Practical implication: pair SBOM generation with reachability checks so remediation is driven by exploitability, not just component presence.
Threat narrative
Attacker objective: The attacker aims to turn a connected device into a controllable asset for persistence, surveillance, lateral movement, or large-scale disruption.
- Entry begins when an attacker targets a device that ships with default credentials, exposed services, or an unauthenticated interface that can be reached over the network.
- Credential access or code execution follows when the attacker logs in with the factory password, pulls firmware through a debug path, or exploits a vulnerable embedded component.
- Escalation and persistence occur when unsigned updates or unvetted third-party code let the attacker maintain control, pivot into adjacent systems, or enroll the device in a botnet.
- Impact is device hijacking, data exposure, service disruption, or use of the product as a foothold into the wider environment.
Breaches seen in the wild
- McHire default password flaw 2025: A forgotten test admin account with the password 123456 and an API flaw exposed McDonald's McHire applicant records to researchers.
- SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Firmware visibility is the governance boundary for connected devices: if the manufacturer cannot see the shipped software image, it cannot credibly claim to control device risk. That makes firmware analysis a governance control, not just a reverse-engineering task. In connected-device programmes, visibility precedes every other control decision, from vulnerability handling to secure-by-default configuration.
Default credentials are machine identity debt, not a minor configuration flaw: shipped passwords and open services create an unmanaged identity surface that persists into production. Once the product leaves the factory, those credentials often outlive the teams that created them. The result is a standing access path that attackers can automate at scale, which makes OWASP-NHI concepts around long-lived secrets and insecure authentication highly relevant here.
Device supply chain opacity: the real risk is not simply third-party code, but third-party code that nobody can inventory or prove reachable. Connected products increasingly depend on inherited libraries, and the governance failure is assuming component lists are complete when they are not. Practitioners should treat unseen dependencies as a control gap that invalidates downstream assurance claims.
Regulation is now forcing software provenance into product security governance: the EU Cyber Resilience Act makes visibility, SBOMs, and vulnerability handling part of market access rather than optional hygiene. That shifts connected-device security from reactive patching to evidence-backed lifecycle control. Teams that cannot prove what is inside the device will struggle to prove compliance, safety, or exposure management.
What this signals
Connected device security is shifting from perimeter assumptions to provenance control: teams now need evidence about what was actually shipped, not just what was intended in design. That makes firmware inventory, dependency tracking, and reachability analysis central to risk governance, especially where devices cannot be patched quickly.
Device identity is increasingly bound to embedded credentials and interfaces: when a product ships with a default password or unmanaged management path, it behaves like a machine identity with no lifecycle discipline. That is the same governance problem identity teams face with other non-human credentials, only here the exposure is embedded in product design.
Provenance pressure will keep rising: regulations such as the EU Cyber Resilience Act are turning software visibility into a market requirement, which means manufacturers must be able to prove component composition and vulnerability handling across the support life. Programme owners should prepare for evidence-based security reviews rather than one-time assessments.
For practitioners
- Build a firmware-derived SBOM Extract the shipped image and inventory the actual components present in firmware, not the ones listed in design documentation or build manifests.
- Eliminate default credentials before release Remove universal passwords, disable unnecessary management interfaces, and verify that each device ships with unique or provisioned access controls.
- Use reachability to rank vulnerabilities Prioritise flaws only when the vulnerable component is present in the product and reachable through real execution paths or exposed services.
- Track third-party libraries through the full support life Maintain component ownership, patchability, and end-of-life records for every embedded dependency so updates and disclosures can be handled quickly.
- Align product evidence to CRA obligations Map SBOM, vulnerability handling, and incident reporting workflows to the EU Cyber Resilience Act requirements before the compliance deadlines arrive.
Key takeaways
- Connected device flaws persist when manufacturers cannot see the software and firmware they ship.
- Default passwords, exposed interfaces, and opaque third-party components are the recurring patterns behind compromise.
- The practical fix is ground-truth inventory, reachability-based prioritisation, and product evidence that can support compliance.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 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-02 — Secret Leakage | Default credentials and hardcoded secrets in firmware are a central failure mode in this article. |
| NHI-04 — Insecure Authentication | Shipped passwords and weak device login flows are a primary entry path for attackers. | |
| NHI-06 — Insecure Cloud Deployment Configurations | Exposed interfaces and misconfigured connected services create the device-to-cloud attack surface discussed here. | |
| Recommendation — Scan shipped firmware for embedded secrets and revoke or replace any exposed credentials before release. Eliminate insecure device authentication flows and verify each product enforces unique, non-default access. Review device-facing services and cloud endpoints for exposed management paths and unsafe defaults. | ||
| MITRE ATT&CK | TA0001;TA0006;TA0040 — Initial Access; Credential Access; Impact | The article describes network entry, credential abuse, and downstream device disruption or botnet use. |
| Recommendation — Map device compromise paths to TA0001, TA0006, and TA0040 to prioritise detections around exposure and abuse. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Default passwords and unmanaged device access paths are authorization failures in connected products. |
| Recommendation — Apply PR.AA-05 to remove standing device access paths and enforce least-privilege product authentication. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Connected devices depend on embedded access controls and credential governance across their lifecycle. |
| Recommendation — Use IAM controls to govern device credentials, access paths, and lifecycle revocation across deployed products. | ||
Key terms
- Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
- Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
- Firmware: Firmware is the embedded software that runs a device at a low level and controls how it behaves. In IoT environments, outdated firmware is a major risk because vulnerabilities can persist for long periods, giving attackers an easy path to compromise devices that are rarely patched like standard endpoints.
- Secure by default: Secure by default means the safest configuration and workflow is the one the system encourages by design. For identity products, that usually means least privilege, auditability, and revocation paths are built into the normal user journey instead of being added as manual exceptions later.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build the governance discipline needed for systems where credentials and access paths outlive deployment cycles.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org