Secure by Default

A product is secure by default when it arrives in a secure state that does not require configuration changes by the user.

Examples include unique per-device passwords, disabled non-essential network services at first boot, and automatic security updates enabled by default. Firewall rules use closed default settings. Debug interfaces require explicit authentication. Most users do not change default settings or harden devices after purchase.

Annex I Part I(2)(b) of the EU Cyber Resilience Act requires manufacturers to ensure products are placed on the market with a secure default configuration. The default state must satisfy the security baseline. Providing a hardening guide is not enough.

The requirement prohibits shared default passwords. Every device must use unique credentials or prompt the user to set a password before operation.

The configuration must also allow users to reset the product to its original secure state. For custom business products, manufacturers and business users may agree to adapt these default settings. Failure to meet Annex I requirements can lead to enforcement action by market surveillance authorities.

Manufacturers must embed secure defaults early in product development.

Key practices include generating unique credentials at the factory, disabling unnecessary network services, and enabling automatic updates by default. Manufacturers should configure TLS with modern cipher suites and audit configurations before production. Document the secure baseline and justify any enabled services in the technical documentation.

A frequent violation is shipping products with shared factory passwords such as 'admin' or 'admin'. Prompting users to change a shared password does not meet the standard.

Manufacturers also enable services like Telnet, FTP, or UPnP for easy setup and tell users to turn them off later. If a service is not necessary for core function, the manufacturer must disable it by default.