Default credentials and weak onboarding create a reusable foothold that attackers can automate at scale. Once a device is enrolled into hostile infrastructure, it can be repurposed for DDoS, proxy abuse or internal reconnaissance. The core failure is not just compromised hardware, but the absence of durable identity controls that bind each device to a known owner, state and access boundary.
Why default credentials break device trust at the first login
Default credentials make the device effectively share a public secret with every other unit of the same model, which destroys any meaningful device-level trust boundary. Once an attacker can predict or reuse the initial login, the device no longer proves who owns it, whether it is genuine, or whether its control plane is isolated from other deployments.
That is why the failure is bigger than a bad password. It means the device never had a secure identity-bearing enrollment step, so access, ownership and state are all inferred from the default setting instead of being established by a verified onboarding process. A reusable credential also makes fleet-wide compromise far easier than a one-off intrusion.
How weak onboarding turns a single exposed device into a fleet problem
Weak onboarding usually fails in the same places: no unique device identity, no strong proof at enrollment, no owner binding and no enforced credential change after first use. In that condition, the first compromise becomes a template for the rest of the fleet, especially when devices are shipped, staged or provisioned with identical secrets and permissive management interfaces.
Once adversaries gain a foothold, they can often reuse it to pivot between devices, harvest internal telemetry, or press the device into another role entirely. That is why onboarding must be treated as an access-control problem, not just a setup convenience, especially when device credentials behave like shared secrets rather than per-device authenticator material. Ultimate Guide to NHIs — What are Non-Human Identities
At scale, weak onboarding also creates operational blind spots. Teams lose confidence in inventory, ownership and revocation because they cannot tell which device is legitimate, which one has been repurposed and which one still carries factory defaults. NHI Lifecycle Management Guide
Why attackers turn compromised IoT devices into infrastructure
Compromised IoT devices are attractive because they are always on, widely distributed and often trusted by network operators. That makes them useful for DDoS, proxying traffic, internal reconnaissance and other abuse that benefits from persistence and geographic spread. When the device is enrolled into hostile infrastructure, the attacker is no longer just exploiting a product, but inheriting a foothold inside an enterprise or consumer environment.
The practical consequence is that compromise can outlive the original login weakness. If the device keeps working after abuse is detected, it may still serve as a relay, sensor or scanning node until credentials are rotated, management access is rekeyed and the device is re-enrolled under a clean trust chain. OWASP Non-Human Identity Top 10
Risk and Threat Considerations
Default credentials and weak onboarding create a high-volume attack surface because the weakness is repeatable across many devices, not just one. The main risks are unauthorised enrollment, device impersonation, fleet-wide compromise and abuse of the device as disposable infrastructure for traffic, scanning or pivoting.
Failure mechanism: The attacker authenticates with factory credentials or bypasses a weak enrollment flow, then retains access because the device was never bound to a unique owner, state or rotated secret.
Impact: The device can be repurposed at scale, its trust relationship can be abused for proxying or reconnaissance, and revocation becomes difficult because no durable identity boundary was established at onboarding.
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, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Weak onboarding creates devices that never leave default trust states. |
| NHI-02 — Secret Leakage | Default credentials are reusable secrets that enable broad device compromise. | |
| NHI-05 — Overprivileged NHI | Weak onboarding often grants devices more access than their role requires. | |
| Recommendation — Enforce device deprovisioning and enrollment controls so stale or default access cannot persist. Replace shared defaults with unique secrets and rotate any exposed device credentials immediately. Scope each device to the minimum access needed and remove excess privileges at enrollment. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Device onboarding depends on issuing, changing and revoking authenticators safely. |
| IA-9 — Service Identification and Authentication | IoT devices must authenticate as distinct non-human systems during onboarding. | |
| AC-6 — Least Privilege | Compromised devices should not retain broad internal access after onboarding. | |
| Recommendation — Manage device authenticators through issuance, rotation, and revocation controls. Require unique machine authentication for each device instead of shared defaults. Restrict each device to the minimum permissions needed for its function. | ||
| CIS Controls v8 | CIS-5 — Account Management | Device accounts and onboarding credentials need controlled lifecycle management. |
| Recommendation — Inventory and govern device accounts so default or dormant access is removed promptly. | ||
| NIST CSF 2.0 | PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited for authorized users, services, and devices | The issue is the absence of durable identity controls for devices. |
| PR.AA-05 — Least privilege is established and enforced | Compromised IoT devices should not have unnecessary internal reach. | |
| PR.AA-06 — Physical and logical access to assets is managed and enforced | Weak onboarding often means device access is not properly bounded or enforced. | |
| Recommendation — Issue, verify, and revoke unique device identities throughout the device lifecycle. Enforce least privilege for device access paths and management functions. Bind device access to enforced logical controls that can be reviewed and revoked. | ||
Practitioner Guidance
What to verify: Confirm that every device receives a unique identity at enrollment, that the default secret is removed before production use, and that ownership is tied to an accountable system or person. If you cannot prove those three conditions, treat the fleet as vulnerable by design.
Decision rule: If a device can authenticate with a vendor default, force credential replacement and re-enrollment before it is allowed onto any trusted network segment. If re-enrollment cannot be enforced, isolate the device class and assume it has no reliable trust anchor.
What good looks like: New devices arrive with per-device secrets or certificates, onboarding is time-bounded and auditable, and revocation can disable one unit without breaking the rest of the fleet.
Practitioner takeaway: The key question is not whether the device works after setup, but whether onboarding establishes a durable trust boundary that can survive compromise, rotation and revocation.
Related resources from NHI Mgmt Group
- What breaks when IoT devices rely on shared credentials or plain-text secrets?
- What breaks when connected products rely on default credentials or weak authentication under the CRA?
- What breaks when IoT devices rely on VLANs for security?
- What breaks when fintech firms rely on static credentials and weak access controls for cloud and AI systems?