Secure by Default

A product is secure by default when it arrives in the hands of the user in a security-positive state that does not depend on the user making configuration changes. Practical examples include: unique per-device passwords rather than shared factory defaults; all non-essential network services disabled at first boot; automatic security update installation enabled unless explicitly opted out; closed firewall rules with explicit allow-listing rather than open-by-default policies; and no debug interfaces accessible without explicit authentication. The principle recognises that most users — particularly consumers — will not consult a manual or harden a device after purchase.

Annex I Part I(2)(e) of the EU Cyber Resilience Act explicitly requires manufacturers to ensure that products with digital elements are placed on the market with a secure by default configuration. This requirement means that the default out-of-box state must satisfy the security baseline — it is not sufficient to provide a hardening guide. The requirement also prohibits shared default passwords: every device must use unique credentials or require the user to set a password before the device becomes functional. Non-compliance with Annex I essential requirements constitutes a basis for market surveillance authority enforcement action.

Implementing secure by default requires design decisions embedded early in product development. Key practices include: generating unique, device-specific credentials at the factory or on first boot rather than using shared defaults; disabling all network services not required for the product's primary function; configuring automatic updates to be on by default with a clear opt-out mechanism (not opt-in); pre-configuring TLS with strong cipher suites rather than supporting deprecated protocols for backwards compatibility; and performing a pre-ship configuration audit against the intended secure baseline before each production run. The secure default configuration should be documented in technical documentation with justification for any enabled services.

The most common violation of secure by default is shipping a product with a shared factory password (e.g. 'admin'/'admin') that is documented in a manual or printed on the device. Even if users are prompted to change it, this does not satisfy the CRA's requirement for a secure default. Manufacturers also frequently enable services such as Telnet, FTP, or UPnP for ease of setup and rely on documentation to tell users to disable them. The CRA's requirement is explicit: if it is not necessary for the core function, it must be off by default — user documentation is not an acceptable substitute for proper configuration.