3.2 Secure by default principles

Default hardening focuses on the factory-shipped state of the software, ensuring that the initial configuration is as restrictive as possible. It aims to eliminate low-hanging fruit for attackers by removing unnecessary features and ensuring that all active components are operating at their highest security level without requiring any user input.

• Minimisation of default services. Any feature or service that is not essential for the core functionality of the product should be disabled by default. If a web server includes an optional file-sharing module that most users will not need, that module should be off until the user explicitly opts in, thereby reducing the immediate attack surface.
• Restrictive initial access. Systems should ship with the most restrictive permissions possible. This includes the elimination of universal ‘admin/admin’ credentials and the enforcement of unique passwords and mandatory password changes upon first boot.
• Secure communication by default. All external communications should be encrypted and authenticated from the first connection. Rather than allowing an unencrypted HTTP or Telnet connection for convenience, the system should strictly enforce protocols like TLS 1.3 or SSH, ensuring that data is protected the moment it leaves the device.
• Unique device identity and secrets by default. The product should ship with unique, per-device credentials and cryptographic identity (keys/certificates) rather than shared defaults. Any secrets used for authentication, update verification or encrypted communications must be generated uniquely and protected against extraction. This reduces the risk that compromise of a single device or a leaked credential could be used to attack other customers or the wider installed base.

Guided protection addresses the interaction between the user and the system’s security features. It acknowledges that human error is a primary cause of breaches and uses automated prompts, mandatory set-up steps and clear feedback to ensure that the user cannot easily or accidentally leave the system in an insecure state.

• Mandatory security onboarding. Critical security features should not be hidden in a settings menu; they should be part of the initial set-up wizard. For instance, requiring a user to configure MFA or an encryption key during the first-run experience ensures that the system enters a secure state before it is exposed to the internet.
• Automated maintenance and updates. A secure default posture must be sustainable. By enabling automatic security updates by default, the manufacturer ensures that the product remains protected against newly discovered vulnerabilities without requiring the SME to have a dedicated IT team to manually manage patching cycles.
• Transparent security posture. The system should clearly communicate its security status to the user. If a user chooses to disable a security feature or if a specific configuration increases risk, the system must provide a clear, understandable warning and offer a one-click path to return to the secure baseline.
• Secure recovery and ownership life cycle. The product should provide guided, low-friction recovery and transfer processes (credential reset, account recovery, secure factory reset and ownership transfer) that are simple for users to follow but resistant to account takeover and social engineering.