If your device ships with a password, make it unique per unit, generate it with a mechanism that resists automated attacks, never derive it from a serial number, MAC address or Wi-Fi name, and limit guessing. Better still, make the user set one during setup. Never hard code credentials in firmware.
What the standards say
ETSI EN 303 645 provision 5.1-1 says that where passwords are used, in any state other than the factory default, all consumer IoT device passwords shall be unique per device or defined by the user. Provision 5.1-2 says that pre installed unique passwords shall be generated with a mechanism that reduces the risk of automated attacks against a class or type of device.
The commentary gives the counter examples. Passwords with incremental counters, such as password1 and password2, are easily guessable. A password related in an obvious way to public information sent over the air or within a network, such as a MAC address or Wi-Fi SSID, can allow retrieval by automated means. The UK regime says the same: no incremental counters, public information or identifiers such as serial numbers, unless protected by accepted encryption or keyed hashing.
Design choices
Option A, user defined at setup. The device has no usable password until the owner creates one. This removes the shared default problem. Make sure factory reset returns the device to this state.
Option B, unique pre installed password. Generate each with a cryptographically secure random source, print it on the label or show it in the app, and store only what you need to store. This is convenient, but the label becomes the secret, so think about who sees the box.
Option C, a mix. A unique setup code lets the owner onboard the device, then the owner sets the long term credential.
Add brute force resistance
Provision 5.1-5 says that when the device is not constrained, it shall have a mechanism that makes brute force attacks over network interfaces impracticable. The example is limiting authentication attempts within a time interval and using increasing intervals between attempts.
No hard coded secrets
Provision 5.4-3 says hard coded critical security parameters in device software source code shall not be used. The commentary notes that reverse engineering can easily discover hard coded usernames and passwords, API keys and private keys, and that simple obfuscation can be trivially broken. Provision 5.6-4 adds that physically accessible debug interfaces shall be disabled in software.
Test it
- Take ten units from production and check that no two share a credential.
- Try to derive the password from the label data, serial number and radio identifiers.
- Run an automated guessing attempt and confirm lockout or delay.
- Search firmware images for strings that look like credentials or keys.
- Check that factory reset does not restore a shared default.
Step 4 can be partly automated by scanning firmware and its dependencies. Safeguard offers SBOM and dependency scanning, and a free scan is available at gold.safeguard.sh/scan.
Quick check
Is a unique password printed on the label enough?
It meets the unique per device idea, if it is generated properly. Also consider guessing limits and whether the user should change it at setup.
Sources
Last reviewed: 19 October 2026.
