Default Passwords and CRA: What Annex I Requires

The Default Password Problem

Default credentials — the same username and password shared across thousands or millions of devices — have been one of the most exploited attack vectors in consumer IoT for over a decade. Mirai (2016) and its successors demonstrate the scale of the problem: botnets built from hundreds of thousands of consumer routers and cameras, all compromised by credential scanning against known default credentials.

The CRA addresses this directly. Annex I Requirement 3 requires manufacturers to protect against unauthorised access using "appropriate access control mechanisms." Subsequent guidance and recitals make clear that this includes eliminating shared default credentials.

What Annex I Actually Requires

Annex I does not use the phrase "no default passwords" explicitly, but the combination of Requirement 3 (access control) and Requirement 2 (secure by default) creates the same obligation:

• Products must ship in a secure default configuration
• Unauthorised access must be protected against using appropriate mechanisms
• Access to administrative interfaces must be controlled

A device with a shared default password fails all three. The access control is trivially bypassed by anyone who looks up the product model online.

Compliant Approaches

There are three compliant approaches to the default credential problem:

1. Unique Credentials Per Unit

Each device ships with a unique password — typically a random string printed on a label on the device or in the packaging. This is the most common approach for consumer devices.

Implementation: The unique password is either burned into the device during manufacturing (derived from a device-specific identifier using a keyed hash) or generated randomly during a provisioning step. The password must be stored securely (hashed with bcrypt or Argon2) internally, not in plaintext.

2. Mandatory First-Use Password Change

The device has no working default credential — it forces the user to set a password during first setup before any administrative access is granted.

Implementation: The administrative interface blocks access until a user-chosen password meeting minimum complexity requirements is set. A default credential that must be changed is not equivalent — users frequently skip "optional" changes.

3. Certificate-Based Authentication

For industrial devices and enterprise equipment, certificate-based mutual TLS authentication eliminates shared credentials entirely. Each device has a unique cryptographic identity provisioned during manufacture.

Common Mistakes

• Labels that ship with every unit containing the same "unique" password: if the password is the same on every unit, it is not unique. Verify your manufacturing process actually generates distinct credentials per unit.
• Admin interfaces accessible on public network interfaces: even with unique credentials, administrative interfaces should not be reachable from the internet by default.
• Credentials stored in plaintext in firmware: extract and analyse your firmware image — plaintext credentials in embedded Linux rootfs are common and easily found by market surveillance authorities.
• Recovery modes with hardcoded credentials: factory reset modes that accept a hardcoded engineering password are a common vulnerability class.