Default Credentials and Why IoT Botnets Keep Winning
Botnets are not built from clever exploits. They are built from devices that shipped with a password everyone knows and a firmware update nobody applied. What onboarding has to do instead.
Every few months a botnet story lands with an eye-catching number attached, and the technical detail underneath is almost always disappointing: the devices were not broken into so much as logged into. Consumer routers, IP cameras and video recorders running old firmware with credentials that were printed in the manual are conscripted at scale because getting in requires no exploit at all.
This is worth sitting with, because it means the defence is not sophisticated either. A device that cannot be reached with a known password is not vulnerable to the technique that builds most botnets, and that property is decided entirely by how onboarding works.
The first rule is that no two units should ship with the same secret. A per-device password printed on the unit is dramatically better than a shared default, because compromising one device teaches an attacker nothing about the next. Better still is a device with no working credential until an owner sets one, so an unconfigured unit on a network is inert rather than open.
The second rule is that the device should refuse to become useful until its initial secret is changed. Many products prompt for a password change and then continue happily when the prompt is dismissed, which converts a security control into a suggestion. Refusing to expose any network service until setup is complete costs a little friction at install time and removes the entire category of abandoned-default devices.
The third rule is that remote administration should be off unless someone deliberately turns it on. A significant share of conscripted devices were never intended to be reachable from the internet; they became reachable because a management interface listened on every interface by default and a router happily forwarded a port. Binding administrative services to the local network unless explicitly reconfigured means a misconfiguration elsewhere does not expose the device.
None of this helps if the device cannot be updated. A product whose firmware can be fixed is a product whose vulnerabilities have a finite life; one that cannot is a permanent liability, and it stays online long after the vendor has moved on. That is precisely the gap regulation is now closing, and it is worth designing for on the assumption that the update path will eventually be audited rather than merely promised.
The uncomfortable summary is that the industry knows all of this and ships otherwise, because each individual shortcut saves a little cost or a little support burden. The devices that end up in botnets are rarely the ones built by teams who did not know better. They are the ones where security lost a series of small arguments to schedule.